On Mon, Dec 21, 2020 at 7:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Jeff Janes <jeff.janes@gmail.com> writes:
> >>> I would suggest going further. I would make the change on the client side,
> >>> and have libpq refuse to send unhashed passwords without having an
> >>> environment variable set which allows it.
>
> >> As noted, that would break LDAP and RADIUS auth methods; likely also PAM.
>
> > Which would be an altogether good thing as all of those end up exposing
> > sensitive information should the server be compromised and a user uses
> > one of them to log in.
>
> Hm. I'm less concerned about that scenario than about somebody snooping
> the on-the-wire traffic. If we're going to invent a connection setting
> for this, I'd say that in addition to "ok to send cleartext password"
> and "never ok to send cleartext password", there should be a setting for
> "send cleartext password only if connection is encrypted". Possibly
> that should even be the default.
>
> (I guess Unix-socket connections would be an exception, since we never
> encrypt those.)
"send cleartext password only if connection is secure", and define
secure as being tls encrypted, gss encrypted, or unix socket.
> BTW, do we have a client-side setting to insist that passwords not be
> sent in MD5 hashing either? A person who is paranoid about this would
> likely want to disable that code path as well.
I don't think we do, and we possibly should. You can require channel
binding which will require scram which solves the problem, but it does
so only for scram.
IIRC we've discussed having a parameter that says "allowed
authentication methods" on the client as well, but I don't believe it
has been built. But it wouldn't be bad to be able to for example force
the client to only attempt gssapi auth, regardless of what the server
asks for, and just fail if it's not there.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/