Feedback-ID: i0fe9450f:Fastmail
Date: Sat, 10 Dec 2022 08:21:51 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Daniel Gustafsson <daniel@yesql.se>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Raising the SCRAM iteration count
Message-ID: <Y5PDD+fNfeBpbqd/@paquier.xyz>
References: <F72E7BC7-189F-4B17-BF47-9735EB72C364@yesql.se>
 <1d669d97-86b3-a5dc-9f02-c368bca911f6@iki.fi>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="BmOQhyeTT1lr344O"
Content-Disposition: inline
In-Reply-To: <1d669d97-86b3-a5dc-9f02-c368bca911f6@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/Y5PDD%2BfNfeBpbqd/%40paquier.xyz>
Precedence: bulk


--BmOQhyeTT1lr344O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 15=
000
>> (still conservative, from RFC7677) and a minimum of 4096.  Since the ite=
rations
>> are stored per secret it can be altered with backwards compatibility.
>=20
> We just had a discussion with a colleague about using a *smaller* iterati=
on
> count. Why? To make the connection startup faster. We're experimenting wi=
th
> a client that runs in a Cloudflare worker, which is a wasm runtime with v=
ery
> 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 enou=
gh.
> 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=3D4096, salt_length=3D123) 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

--BmOQhyeTT1lr344O
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmOTww8ACgkQnvQgOdby
QH2ZJhAApeTQd1YFtQSNcJFom716c6rgmx9ZOQGCv4TIvrBj9wUFYWlh5vgdHAjb
tkafFEPyFiWvg3363Jb3aQlSKbrCT1YzmwOpN6UU/Ofp1pcfiSPWD/ylfKPh501p
KMbbF8ZHyVR8TCYbs2y8M2PnEyo145DorrfojY+a5CirYV5ng3+Cwgbz1i97x/Y4
OCedfOnd8mEQf+mmuLuwn/tx3l94kBaVO/hhJmafr15Py8oRdLDlKzDdtyjs7lZi
OuqSEDNCH4g6zMnHo/mgR9xQxJuOvgZU/fhkxpDKsLlY+gZTf6+EOUd9UkbyzvoZ
dzPey4PKUrn3zqDjiZcU0UAthjgEYKQRy+PFO9dtH5MeUDcXoqGx8pTwcTY6mIj2
S4vlEv+DTi8+HNOLskbfQxf18/aC+rQhU4py/5s2GuW5goTn1CHbdK2K6bEd8Brz
dXEDUB4SjOJOcq2iUGNrQ1fSG8V3yqzFUvDeMGDoydh5UBY9jd82kBI5euuqnshI
dAzwaf6g2Ch0TRcroy+J3KpYrz3szjJfPuP2mytUr7gTkkkPWT4Gr9wY/cExdsFe
qVyVcCCKTjfD7d1F9FR5lwbWtBhtaBLAzjBHpk9rMNK7jnbfchFSCT6DQfpmaIaq
GJKB2Yo20AjeCeBdv5pmlVrAFUBkyzNiF99Liu4xZo0jpYPLRFU=
=H11q
-----END PGP SIGNATURE-----

--BmOQhyeTT1lr344O--