Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Jeff Janes <jeff.ja...@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
signature.asc
Description: PGP signature
