On 2019-08-12 19:26, Tom Lane wrote:
> What problem do we actually need to solve here?
>
> If the known use-case is just "don't send my password in the clear",
> maybe we should just change libpq to refuse to do that, ie reject
> plain-password auth methods unless SSL is on (except maybe over
> unix sockets?). Or invent a bool connection option that enables
> exactly that.
There are several overlapping problems:
1) A downgrade attack by a malicious server. The server can collect
passwords from unsuspecting clients by just requesting some weak
authentication like plain-text or md5. This can currently be worked
around by using SSL with server verification, except when considering
the kind of attack that channel binding is supposed to address.
2) A downgrade attack to evade channel binding. This cannot currently
be worked around.
3) A user not wanting to expose a weakly hashed password to the
(otherwise trusted) server. This cannot currently be done.
4) A user not wanting to send a password in plain text over the wire.
This can currently be done by requiring SSL.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services