Re: Add "password_protocol" connection parameter to libpq - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add "password_protocol" connection parameter to libpq
Date
Msg-id 12894.1565630766@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add "password_protocol" connection parameter to libpq  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Add "password_protocol" connection parameter to libpq  (Stephen Frost <sfrost@snowman.net>)
Re: Add "password_protocol" connection parameter to libpq  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> I'm not really thrilled with approach #2 because it means the user
> will have to know which of the PG authentication methods involve, eg,
> sending the password in the clear to the server, and which don't, if
> what they're really looking for is "don't send my password in the clear
> to the server" which seems like a really useful and sensible thing to
> ask for.

What problem do we actually need to solve here?

If the known use-case is just "don't send my password in the clear",
maybe we should just change libpq to refuse to do that, ie reject
plain-password auth methods unless SSL is on (except maybe over
unix sockets?).  Or invent a bool connection option that enables
exactly that.

I'm not really convinced that there is a use-case for client side
specification of allowed auth methods beyond that.  In the end,
if you don't trust the server you're connecting to to handle your
password with reasonable safety, you have got bigger problems than
this one.  And we already have coverage for MITM problems (or if
we don't, this sideshow isn't fixing it).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Add "password_protocol" connection parameter to libpq
Next
From: Stephen Frost
Date:
Subject: Re: Add "password_protocol" connection parameter to libpq