On 2/25/22 12:39 PM, Tom Lane wrote:
> Jeff Davis <pgsql@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
