On 03/14/2017 09:02 PM, Jeff Janes wrote:
It is somewhat disconcerting that the client will send a plain-text password to a mis-configured (or mal-configured) server, but I don't think there is anything this patch series can reasonably do about that.
Yeah. That's one pretty glaring hole with libpq: there's no option to disallow insecure authentication mechanisms. That's not new, but now that we have SCRAM that's otherwise more secure, it looks worse in comparison.
SCRAM also has a nice feature that it provides proof to the client, that the server knew the password (or rather, had a verifier for that password). In other words, the client knows that it connected to the correct server, not a fake one. But currently nothing prevents a fake server from simply not doing SCRAM authentication.
We clearly need something similar to sslmode=require in libpq, to tighten that up.
The message returned to the client for the wrong password differs between pg_hba-set scram and pg_hba-set md5/password methods. Is that OK? psql: error received from server in SASL exchange: invalid-proof psql: FATAL: password authentication failed for user "test"
Ah yeah, I was on the fence on that one. Currently, the server returns the invalid-proof error to the client, as defined in RFC5802. That results in that error message from libpq. Alternatively, the server could elog(FATAL), like the other authentication mechanisms do, with the same message. The RFC allows that behavior too but returning the invalid-proof error code is potentially more friendly to 3rd party SCRAM implementations.
One option would be to recognize the "invalid-proof" message in libpq, and construct a more informative error message in libpq. Could use the same wording, "password authentication failed", but it would behave differently wrt. translation, at least.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
