Re: BUG #16079: Question Regarding the BUG #16064 - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: BUG #16079: Question Regarding the BUG #16064
Date
Msg-id CAMkU=1w4c6NXiKHx-awVw0EeTqqn-Coy_hJGwYkq9WvbEQ1PAw@mail.gmail.com
Whole thread Raw
Responses Re: BUG #16079: Question Regarding the BUG #16064
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: bad dependency in pg_dump output related to support function breaks binary upgrade
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Logical decoding of TRUNCATE