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
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? |