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
signature.asc
Description: PGP signature
