On 2/25/22 12:39 PM, Tom Lane wrote:
Jeff Davis <pg...@j-davis.com> writes:On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:... and, since we can't readily enforce that the client only sends those cleartext passwords over suitably-encrypted connections, this could easily be a net negative for security. Not sure that I think it's a good idea.I don't understand your point. Can't you just use "hostssl" rather than "host"?My point is that sending cleartext passwords over the wire is an insecure-by-definition protocol that we shouldn't be encouraging more use of.
This is my general feeling as well. We just spent a bunch of effort adding, refining, and making SCRAM the default method. I think doing anything that would drive more use of sending plaintext passwords, even over TLS, is counter to that.
I do understand arguments for (e.g. systems that require checking password complexity), but I wonder if it's better for us to delegate that to an external auth system. Regardless, I can get behind Andres' point to "check Port->ssl_in_use before sendAuthRequest(AUTH_REQ_PASSWORD)".
I'm generally in favor of being able to support additional authentication methods, the first one coming to mind is supporting OIDC. Having a pluggable auth infrastructure could possibly make such efforts easier. I'm definitely intrigued.
Jonathan
OpenPGP_signature
Description: OpenPGP digital signature
