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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, k(dot)yudhveer(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BUG #16079: Question Regarding the BUG #16064
Date: 2020-12-21 17:26:17
Message-ID: CAMkU=1w4c6NXiKHx-awVw0EeTqqn-Coy_hJGwYkq9WvbEQ1PAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

>
> * Magnus Hagander (magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-12-21 18:27:25 Re: Large objects and out-of-memory
Previous Message PG Bug reporting form 2020-12-21 17:00:01 BUG #16784: Server crash in ExecReScanAgg()

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-12-21 17:42:47 Re: [PATCH] Logical decoding of TRUNCATE
Previous Message Tom Lane 2020-12-21 16:23:07 Re: bad dependency in pg_dump output related to support function breaks binary upgrade