Re: User functions for building SCRAM secrets

> On 14 Apr 2023, at 05:50, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Apr 14, 2023 at 01:27:46AM +0200, Daniel Gustafsson wrote:
>> What would be the intended usecase? I don’t have the RFC handy, does
>> it say anything about salt length?
>
> Hmm.  I thought it did, but RFC 5802 has only these two paragraphs:
>
>   If the authentication information is stolen from the authentication
>   database, then an offline dictionary or brute-force attack can be
>   used to recover the user's password.  The use of salt mitigates this
>   attack somewhat by requiring a separate attack on each password.
>   Authentication mechanisms that protect against this attack are
>   available (e.g., the EKE class of mechanisms).  RFC 2945 [RFC2945] is
>   an example of such technology.  The WG elected not to use EKE like
>   mechanisms as a basis for SCRAM.
>
>   If an attacker obtains the authentication information from the
>   authentication repository and either eavesdrops on one authentication
>   exchange or impersonates a server, the attacker gains the ability to
>   impersonate that user to all servers providing SCRAM access using the
>   same hash function, password, iteration count, and salt.  For this
>   reason, it is important to use randomly generated salt values.

The salt needs to be unique, unpredictable and shall not repeat across password
generation.  The current 16 byte salted with pg_strong_random should provide
that and I'm not sure I see a usecase for allowing users to configure that.
The iteration count has a direct effect with the security/speed tradeoff but
changing the salt can basically only lead to lowering the security while not
gaining efficiency, or am I missing something?

--
Daniel Gustafsson