Greetings, * Jonathan S. Katz (jk...@postgresql.org) wrote: > 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.
Agreed. > 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)". Password complexity is only needed to be checked at the time of password change though, which is not on every login, and should be after a confirmed mutual authentication between the client and the server. That's a very different situation. > 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. I'm not thrilled with the idea, for my part. Thanks, Stephen
signature.asc
Description: PGP signature