public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Raising the SCRAM iteration count
Date: Sat, 10 Dec 2022 08:21:51 +0900
Message-ID: <Y5PDD+fNfeBpbqd/@paquier.xyz> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
On Fri, Dec 09, 2022 at 05:50:00PM +0200, Heikki Linnakangas wrote:
>> The attached introduces a scram_iteration_count GUC with a default of 15000
>> (still conservative, from RFC7677) and a minimum of 4096. Since the iterations
>> are stored per secret it can be altered with backwards compatibility.
>
> We just had a discussion with a colleague about using a *smaller* iteration
> count. Why? To make the connection startup faster. We're experimenting with
> a client that runs in a Cloudflare worker, which is a wasm runtime with very
> small limits on how much CPU time you're allowed to use (without paying
> extra). And we know that the password is randomly generated and long enough.
> If I understand correctly, the point of iterations is to slow down
> brute-force or dictionary attacks, but if the password is strong enough to
> begin with, those attacks are not possible regardless of iteration count. So
> I would actually like to set the minimum iteration count all the way down to
> 1.
This is the kind of thing that should be easily measurable with
pgbench -C and an empty script. How much difference are you seeing
with 1, 4096 and more than that?
All that comes down to provide more capability for the existing
routines in my opinion. So what if we finally extended with a new
flavor PQencryptPasswordConn() able to get a list of options, say
PQencryptPasswordConn() extended that has a string with all the
options? psql could use for \password a grammar consistent with \g,
as of: \password (iteration=4096, salt_length=123) PASS_STR
Note that scram_build_secret() is already able to handle any iteration
count, even at 1, so IMO it is not a good idea to lower the default to
be so. I'd agree with Daniel to make it higher by default and follow
the RFCs, though like you I have wanted also in core much more control
over that.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../Y5PDD+fNfeBpbqd%[email protected]/2-signature.asc)
download
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Raising the SCRAM iteration count
In-Reply-To: <Y5PDD+fNfeBpbqd/@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox