On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
> Jacob Champion <pchampion@vmware.com> writes:
>> = Client-Side Auth Selection =
>> The second request is for the client to stop fully trusting the server
>> during the authentication phase. If I tell libpq to use a client
>> certificate, for example, I don't think the server should be allowed to
>> extract a plaintext password from my environment (at least not without
>> my explicit opt-in).
>
> Yeah. I don't recall whether it's been discussed in public or not,
> but it certainly seems like libpq should be able to be configured so
> that (for example) it will never send a cleartext password. It's not
> clear to me what extent of configurability would be useful, and I
> don't want to overdesign it --- but that much at least would be a
> good thing.
I recall this part being discussed in public, but I cannot put my
finger on the exact thread. I think that this was around when we
discussed the open items of 10 or 11 for things around channel binding
and how libpq was sensitive to downgrade attacks, which would mean
around 2016 or 2017. I also recall reading (writing?) a patch that
introduced a new connection parameter that takes in input a
comma-separated list of keywords to allow the user to choose a set of
auth methods accepted, failing if the server is willing to use a
method that does not match with what the user has put in his list.
Perhaps this last part has never reached -hackers though :)
Anyway, the closest thing I can put my finger on now is that:
https://www.postgresql.org/message-id/c5cb08f4cce46ff661ad287fadaa1b2a@postgrespro.ru
--
Michael
