|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||"Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Raising the SCRAM iteration count|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> On 14 Dec 2022, at 02:00, Michael Paquier <michael(at)paquier(dot)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/
|Next Message||Bharath Rupireddy||2022-12-14 11:28:48||Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL|
|Previous Message||Bharath Rupireddy||2022-12-14 11:24:53||Re: Inconsistency in reporting checkpointer stats|