Re: [HACKERS] Authentication tests, and plain 'password'authentication with a SCRAM verifier

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