Re: User functions for building SCRAM secrets

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
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 03:50:29
Message-ID: ZDjNhaCi01h8J9DX@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-04-14 04:13:09 Re: Various typo fixes
Previous Message Laurenz Albe 2023-04-14 03:06:46 Re: Should we remove vacuum_defer_cleanup_age?