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
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() |
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 |