public inbox for [email protected]  

help / color / mirror / Atom feed
From: Jonathan S. Katz <[email protected]>
To: Tom Lane <[email protected]>
To: Jeff Davis <[email protected]>
Cc: samay sharma <[email protected]>
Cc: [email protected]
Cc: Andres Freund <[email protected]>
Subject: Re: Proposal: Support custom authentication methods using hooks
Date: Fri, 25 Feb 2022 13:40:54 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAJxrbyxTRn5P8J-p+wHLwFahK5y56PhK28VOb55jqMO05Y-DJw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 2/25/22 12:39 PM, Tom Lane wrote:
> Jeff Davis <[email protected]> writes:
>> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
>>> ... and, since we can't readily enforce that the client only sends
>>> those cleartext passwords over suitably-encrypted connections, this
>>> could easily be a net negative for security.  Not sure that I think
>>> it's a good idea.
> 
>> I don't understand your point. Can't you just use "hostssl" rather than
>> "host"?
> 
> My point is that sending cleartext passwords over the wire is an
> insecure-by-definition protocol that we shouldn't be encouraging
> more use of.

This is my general feeling as well. We just spent a bunch of effort 
adding, refining, and making SCRAM the default method. I think doing 
anything that would drive more use of sending plaintext passwords, even 
over TLS, is counter to that.

I do understand arguments for (e.g. systems that require checking 
password complexity), but I wonder if it's better for us to delegate 
that to an external auth system. Regardless, I can get behind Andres' 
point to "check Port->ssl_in_use before sendAuthRequest(AUTH_REQ_PASSWORD)".

I'm generally in favor of being able to support additional 
authentication methods, the first one coming to mind is supporting OIDC. 
Having a pluggable auth infrastructure could possibly make such efforts 
easier. I'm definitely intrigued.

Jonathan


Attachments:

  [application/pgp-signature] OpenPGP_signature (840B, ../[email protected]/2-OpenPGP_signature)
  download

view thread (7+ messages)  latest in thread

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Proposal: Support custom authentication methods using hooks
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox