Re: BUG #16079: Question Regarding the BUG #16064
От | Tom Lane |
---|---|
Тема | Re: BUG #16079: Question Regarding the BUG #16064 |
Дата | |
Msg-id | 544464.1608576242@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16079: Question Regarding the BUG #16064 (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: BUG #16079: Question Regarding the BUG #16064
Re: BUG #16079: Question Regarding the BUG #16064 Re: BUG #16079: Question Regarding the BUG #16064 |
Список | pgsql-hackers |
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.) 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. regards, tom lane
В списке pgsql-hackers по дате отправления: