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.
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.
In practice, I'm not sure how good this dummy authentication thing
really is anyway. Even on older versions, I'd wager a guess that if you
tried hard enough, you could tell if a user exists or not based on
timing, for example. So I think this is good enough. But it's worth
noting and discussing.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers