Re: BUG #16079: Question Regarding the BUG #16064

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: BUG #16079: Question Regarding the BUG #16064
Дата
Msg-id CAMkU=1w4c6NXiKHx-awVw0EeTqqn-Coy_hJGwYkq9WvbEQ1PAw@mail.gmail.com
обсуждение исходный текст
Ответы Re: BUG #16079: Question Regarding the BUG #16064  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost <sfrost@snowman.net> wrote:

* Magnus Hagander (magnus@hagander.net) wrote:


Changed from bugs to hackers.
 
> For the old plaintext "password" method, we log a warning when we parse the
> configuration file.

Like Stephen, I don't see such a warning getting logged.
 
>
> Maybe we should do the same for LDAP (and RADIUS)? This seems like a better
> place to put it than to log it at every time it's received?

A dollar short and a year late, but ... +1.

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.  (Also, change the client behavior so it defaults to verify-full when PGSSLMODE is not set.)

What is the value of logging on the server side?  I can change the setting from password to md5 or from ldap to gss, when I notice the log message. But once compromised or during a MITM attack, the bad guy will just set it back to the unsafe form and the client will silently go along with it.

Cheers,

Jeff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: bad dependency in pg_dump output related to support function breaks binary upgrade
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Logical decoding of TRUNCATE