Re: Raising the SCRAM iteration count
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
Andres Freund <andres@anarazel.de>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-14T11:25:19Z
Lists: pgsql-hackers
Attachments
- v2-0001-Make-SCRAM-iteration-count-configurable.patch (application/octet-stream) patch v2-0001
> On 14 Dec 2022, at 02:00, Michael Paquier <michael@paquier.xyz> wrote: > > On Tue, Dec 13, 2022 at 12:17:58PM +0100, Daniel Gustafsson wrote: >> It does raise an interesting point though, if we in the future add suppprt for >> SCRAM-SHA-512 (which seems reasonable to do) it's not good enough to have a >> single GUC for SCRAM iterations; we'd need to be able to set the iteration >> count per algorithm. I'll account for that when updating the patch downthread. > > So, you mean that the GUC should be named like password_iterations, > taking a grammar with a list like 'scram-sha-256=4096,algo2=5000'? I was thinking about it but opted for the simpler approach of a GUC name with the algorithm baked into it: scram_sha256_iterations. It doesn't seem all that likely that we'll have more than two versions of SCRAM (sha256/sha512) so the additional complexity doesn't seem worth it. The attached v2 has the GUC rename and a change to GUC_REPORT such that the frontend can use the real value rather than the default. I kept it for super users so far, do you think it should be a user setting being somewhat sensitive? The default in this version is rolled back to 4096 as there was pushback against raising it, and the lower limit is one in order to potentially assist situations like the one Andres mentioned where md5 is used. -- Daniel Gustafsson https://vmware.com/
Commits
-
Test SCRAM iteration changes with psql \password
- bf5a894c5571 16.0 landed
-
Make SCRAM iteration count configurable
- b577743000cd 16.0 landed