Re: Raising the SCRAM iteration count - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Raising the SCRAM iteration count
Date
Msg-id FDBA5DA0-1015-4162-A8F5-E7BC1F620837@yesql.se
Whole thread Raw
In response to Re: Raising the SCRAM iteration count  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Raising the SCRAM iteration count  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-hackers
> 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/


Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Inconsistency in reporting checkpointer stats
Next
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL