Thread: Re: BUG #16079: Question Regarding the BUG #16064
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
Jeff Janes <jeff.janes@gmail.com> writes: > On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost <sfrost@snowman.net> wrote: >> * Magnus Hagander (magnus@hagander.net) wrote: >>> 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. As noted, that would break LDAP and RADIUS auth methods; likely also PAM. > What is the value of logging on the server side? I do agree with this point, but mostly on the grounds of "nobody reads the server log". regards, tom lane
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Jeff Janes <jeff.janes@gmail.com> writes: > > On Sun, Dec 20, 2020 at 7:58 PM Stephen Frost <sfrost@snowman.net> wrote: > >> * Magnus Hagander (magnus@hagander.net) wrote: > >>> 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. > > 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. The point would be to make it clear to the user, while having an escape hatch if necessary, that they're sending their password (or pin in the RADIUS case) to the server. > > What is the value of logging on the server side? > > I do agree with this point, but mostly on the grounds of "nobody reads > the server log". I agree that doing this server side really isn't all that helpful. Thanks, Stephen
Attachment
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
On Mon, Dec 21, 2020 at 7:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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.) "send cleartext password only if connection is secure", and define secure as being tls encrypted, gss encrypted, or unix socket. > 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. I don't think we do, and we possibly should. You can require channel binding which will require scram which solves the problem, but it does so only for scram. IIRC we've discussed having a parameter that says "allowed authentication methods" on the client as well, but I don't believe it has been built. But it wouldn't be bad to be able to for example force the client to only attempt gssapi auth, regardless of what the server asks for, and just fail if it's not there. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > 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'd still strongly advocate for "never ok to send cleartext password" to be the default, otherwise we put this out and then everyone ends up having to include "set this on all your clients to never allow it" in their hardening guidelines. That's really not ideal. That said, having such an option would certainly be better than not having any reasonable way on the client side to make sure that the user's password isn't being sent to the server. > (I guess Unix-socket connections would be an exception, since we never > encrypt those.) For the middle-ground "I don't care if the server sees my password, but don't want someone on the network seeing it" it would seem unix sockets would be alright. > 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. No, but it would surely be good if we did... or we could just rip out the md5 support entirely. (Yes, I appreciate that the position I'm taking here isn't likely to be popular and I'm not going to completely say no to compromises, but every kind of compromise like these invites users to end up doing the insecure thing; the more difficult we make it to do the insecure thing the better overall for security.) Thanks, Stephen
Attachment
Greetings, * Magnus Hagander (magnus@hagander.net) wrote: > On Mon, Dec 21, 2020 at 7:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. > > I don't think we do, and we possibly should. You can require channel > binding which will require scram which solves the problem, but it does > so only for scram. > > IIRC we've discussed having a parameter that says "allowed > authentication methods" on the client as well, but I don't believe it > has been built. But it wouldn't be bad to be able to for example force > the client to only attempt gssapi auth, regardless of what the server > asks for, and just fail if it's not there. The client is able to require a GSS encrypted connection, and a savy user will realize that they should 'kinit' (or equivilant) locally and never provide their password explicitly to the psql (or equivilant) command, but that's certainly less than ideal. Having a way to explicitly tell libpq what auth methods are acceptable was discussed previously and does generally seem like a good idea, as otherwise there's a lot of risk of what are essentially downgrade attacks. Thanks, Stephen
Attachment
On Mon, Dec 21, 2020 at 8:06 PM Stephen Frost <sfrost@snowman.net> wrote: > > Greetings, > > * Magnus Hagander (magnus@hagander.net) wrote: > > On Mon, Dec 21, 2020 at 7:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > 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. > > > > I don't think we do, and we possibly should. You can require channel > > binding which will require scram which solves the problem, but it does > > so only for scram. > > > > IIRC we've discussed having a parameter that says "allowed > > authentication methods" on the client as well, but I don't believe it > > has been built. But it wouldn't be bad to be able to for example force > > the client to only attempt gssapi auth, regardless of what the server > > asks for, and just fail if it's not there. > > The client is able to require a GSS encrypted connection, and a savy > user will realize that they should 'kinit' (or equivilant) locally and > never provide their password explicitly to the psql (or equivilant) > command, but that's certainly less than ideal. Sure, but even if you do, then if you connect to a server that has gss support but is configured for password auth, it will perform password auth. > Having a way to explicitly tell libpq what auth methods are acceptable > was discussed previously and does generally seem like a good idea, as > otherwise there's a lot of risk of what are essentially downgrade > attacks. That was my point exactly.. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
Greetings, * Magnus Hagander (magnus@hagander.net) wrote: > On Mon, Dec 21, 2020 at 8:06 PM Stephen Frost <sfrost@snowman.net> wrote: > > * Magnus Hagander (magnus@hagander.net) wrote: > > > On Mon, Dec 21, 2020 at 7:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > 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. > > > > > > I don't think we do, and we possibly should. You can require channel > > > binding which will require scram which solves the problem, but it does > > > so only for scram. > > > > > > IIRC we've discussed having a parameter that says "allowed > > > authentication methods" on the client as well, but I don't believe it > > > has been built. But it wouldn't be bad to be able to for example force > > > the client to only attempt gssapi auth, regardless of what the server > > > asks for, and just fail if it's not there. > > > > The client is able to require a GSS encrypted connection, and a savy > > user will realize that they should 'kinit' (or equivilant) locally and > > never provide their password explicitly to the psql (or equivilant) > > command, but that's certainly less than ideal. > > Sure, but even if you do, then if you connect to a server that has gss > support but is configured for password auth, it will perform password > auth. Right, and that's bad. Think we agree on that. I was just saying that someone who understanding how GSS works wouldn't actually provide their password at that point. Trusting to that is definitely not sufficient though. > > Having a way to explicitly tell libpq what auth methods are acceptable > > was discussed previously and does generally seem like a good idea, as > > otherwise there's a lot of risk of what are essentially downgrade > > attacks. > > That was my point exactly.. Yes, it was my intention to agree with you on this. :) Thanks, Stephen
Attachment
On Mon, 2020-12-21 at 13:44 -0500, Tom Lane wrote: > 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. There was a fair amount of related discussion here: https://www.postgresql.org/message-id/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com My feeling after all of that discussion is that the next step would be to move to some kind of negotiation between client and server about which methods are mutually acceptable. Right now, the protocol is structured around the server driving the authentication process, and the most the client can do is abort. > 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. channel_binding=require is one way to do it, but it also requires ssl. Regards, Jeff Davis
On Thu, Jun 03, 2021 at 11:02:56AM -0700, Jeff Davis wrote: > My feeling after all of that discussion is that the next step would be > to move to some kind of negotiation between client and server about > which methods are mutually acceptable. Right now, the protocol is > structured around the server driving the authentication process, and > the most the client can do is abort. FWIW, this sounds very similar to what SASL solves when we try to select a mechanism name, plus some filtering applied in the backend with some HBA rule or some filtering in the frontend with a connection parameter doing the restriction, like channel_binding here. Introducing a new libpq parameter that allows the user to select which authentication methods are allowed has been discussed in the past, I remember vaguely writing/reviewing a patch doing that actually.. -- Michael