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

From Jeff Davis
Subject Re: BUG #16079: Question Regarding the BUG #16064
Date
Msg-id 2c52f6c582e2fbcea77caa0ae8d83af261522be7.camel@j-davis.com
Whole thread Raw
In response to Re: BUG #16079: Question Regarding the BUG #16064  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16079: Question Regarding the BUG #16064
List pgsql-hackers
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





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SSL SNI
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path