Re: User functions for building SCRAM secrets

> On 14 Apr 2023, at 05:50, Michael Paquier <michael(at)paquier(dot)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