Re: User functions for building SCRAM secrets - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: User functions for building SCRAM secrets
Date
Msg-id 6E8F9D0D-2CFC-4DCF-B391-36BB3D9E9D40@yesql.se
Whole thread Raw
In response to Re: User functions for building SCRAM secrets  (Michael Paquier <michael@paquier.xyz>)
Responses Re: User functions for building SCRAM secrets  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
> On 14 Apr 2023, at 01:14, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Apr 11, 2023 at 11:27:17AM +0200, Magnus Hagander wrote:
>> Having the function always generate a random salt seems more
>> reasonable though, and would perhaps be something that helps in some
>> of the cases? It won't help with the password policy one, as it's too
>> secure for that, but it would help with the postgres-is-the-client
>> one?
>
> While this is still hot..  Would it make sense to have a
> scram_salt_length GUC to control the length of the salt used when
> generating the SCRAM secret?

What would be the intended usecase? I don’t have the RFC handy, does it say anything about salt length?

./daniel


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Next
From: Laurenz Albe
Date:
Subject: Re: Should we remove vacuum_defer_cleanup_age?