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
