Re: Proposal: Support custom authentication methods using hooks,Re: Proposal: Support custom authentication methods using hooks

Greetings,

* Tatsuo Ishii (ishii(at)sraoss(dot)co(dot)jp) wrote:
> > On 2/25/22 12:39 PM, Tom Lane wrote:
> >> Jeff Davis <pgsql(at)j-davis(dot)com> 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.
>
> There's at least one use case to use plaintext passwords. Pgpool-II
> accepts plaintext passwords from frontend (from frontend's point of
> view, it looks as if the frontend speaks with PostgreSQL server which
> requests the plaintext password authentication), then negotiates with
> backends regarding authentication method they demand. Suppose we have
> 2 PostgreSQL clusters and they require md5 auth. They send different
> password encryption salt and Pgpool-II deal with each server using the
> salt and password. So Pgpool-II needs plaintext password. Same thing
> can be said to SCRAM-SHA-256 authentication because it's kind of
> challenge/response based authentication.

Passing around plaintext passwords isn't good, regardless of what's
doing it. That some things do that today is a problem, not something
that should be held up as an example use-case that we should be
retaining support for.

> Actually it is possible for Pgpool-II to not use plaintext passwords
> reading from frontend. In this case passwords are stored in a file and
> Pgpool-II reads passwords from the file. But this is annoying for
> users because they have to sync the passwords stored in PostgreSQL
> with the passwords stored in the file.

Users authenticating to an application and then independently having
applications authenticate to the database server is actually rather
common. I agree that proxying credentials is generally better and I'm
hoping to commit support for exactly that during this CF for GSSAPI (aka
Kerberos), where it's cleanly supported. Proxying using plaintext
passwords isn't good though.

> So, dropping plaintext password authentication support from libpq will
> make it impossible for users to use the former method.

Yes, just like dropping support for md5 would make it impossible for
users to have their passwords be hashed with md5, which is an altogether
good thing considering how easy it is to brute-force md5 these days.

Thanks,

Stephen