Greetings,
* 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'd still strongly advocate for "never ok to send cleartext password" to
be the default, otherwise we put this out and then everyone ends up
having to include "set this on all your clients to never allow it" in
their hardening guidelines. That's really not ideal.
That said, having such an option would certainly be better than not
having any reasonable way on the client side to make sure that the
user's password isn't being sent to the server.
> (I guess Unix-socket connections would be an exception, since we never
> encrypt those.)
For the middle-ground "I don't care if the server sees my password, but
don't want someone on the network seeing it" it would seem unix sockets
would be alright.
> 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.
No, but it would surely be good if we did... or we could just rip out
the md5 support entirely.
(Yes, I appreciate that the position I'm taking here isn't likely to be
popular and I'm not going to completely say no to compromises, but every
kind of compromise like these invites users to end up doing the insecure
thing; the more difficult we make it to do the insecure thing the better
overall for security.)
Thanks,
Stephen