> On 14 Apr 2023, at 05:50, Michael Paquier <mich...@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
