On Sat, 2022-03-05 at 01:04 +0000, Jacob Champion wrote:
> TL;DR: this patch lets you specify exactly one authentication method in
> the connection string, and libpq will fail the connection if the server
> doesn't use that method.
>
> (This is not intended for PG15. I'm generally anxious about posting
> experimental work during a commitfest, but there's been enough
> conversation about this topic recently that I felt like it'd be useful
> to have code to point to.)
>
> == Proposal and Alternatives ==
>
> $subject keeps coming up in threads. I think my first introduction to
> it was after the TLS injection CVE, and then it came up again in the
> pluggable auth thread. It's hard for me to generalize based on "sound
> bites", but among the proposals I've seen are
>
> 1. reject plaintext passwords
> 2. reject a configurable list of unacceptable methods
> 3. allow client and server to negotiate a method
>
> All of them seem to have merit. I'm personally motivated by the case
> brought up by the CVE: if I'm expecting client certificate
> authentication, it's not acceptable for the server to extract _any_
> information about passwords from my system, whether they're plaintext,
> hashed, or SCRAM-protected. So I chose not to implement option 1. And
> option 3 looked like a lot of work to take on in an experiment without
> a clear consensus.
>
> Here is my take on option 2, then: you get to choose exactly one method
> that the client will accept.
I am all for the idea, but you implemented the reverse of proposal 2.
Wouldn't it be better to list the *rejected* authentication methods?
Then we could have "password" on there by default.
Yours,
Laurenz Albe
