Re: User functions for building SCRAM secrets

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: User functions for building SCRAM secrets
Date: 2023-04-14 08:12:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-04-14 08:29:53 Re: Set arbitrary GUC options during initdb
Previous Message Daniel Gustafsson 2023-04-14 08:04:27 Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert