Обсуждение: Re: BUG #16079: Question Regarding the BUG #16064

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

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

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

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

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