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
