On 03/16/2017 06:52 AM, Heikki Linnakangas wrote:
> On 03/14/2017 11:14 PM, Tom Lane wrote:
>> In short, I don't think that argument refutes my position that "md5"
>> in pg_hba.conf should be understood as allowing SCRAM passwords too.
>
> Yeah, let's do that. Here's a patch.
>
> I had some terminology trouble with the docs. What do you call a user
> that has "md5XXXXX" in pgauthid.rolpassword? What about someone with a
> SCRAM verifier? I used the terms "those users that have an MD5 hash set
> in the system catalog", and "users that have set their password as a
> SCRAM verifier", but it feels awkward.
maybe something like:
"those users with an MD5 hashed password"
"those users with a SCRAM verifier hash"
> The behavior when a user doesn't exist, or doesn't have a valid
> password, is a bit subtle. Previously, with 'md5' authentication, we
> would send the client an MD5 challenge, and fail with "invalid password"
> error after receiving the response. And with 'scram' authentication, we
> would perform a dummy authentication exchange, with a made-up salt. This
> is to avoid revealing to an unauthenticated client whether or not the
> user existed.
>
> With this patch, the dummy authentication logic for 'md5' is a bit more
> complicated. I made it look at the password_encryption GUC, and send the
> client a dummy MD5 or SCRAM challenge based on that. The idea is that
> most users presumably have a password of that type, so we use that
> method for the dummy authentication, to make it look as "normal" as
> possible. It's not perfect, if password_encryption is set to 'scram',
> and you probe for a user that has an MD5 password set, you can tell that
> it's a valid user from the fact that the server sends an MD5 challenge.
Presumably if you are unauthenticated you don't have any way to know
what password_encryption is set to, so this seems pretty reasonable.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
