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
