From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Jeff Davis <pgsql@j-davis.com>,
        "Jonathan S. Katz" <jkatz@postgresql.org>,
        Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
In-reply-to: <20190812171414.GX16436@tamriel.snowman.net>
References: <20190809030021.GG3194@paquier.xyz>
 <3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
 <20190809100922.GI3194@paquier.xyz>
 <20190809132850.GL16436@tamriel.snowman.net>
 <609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com>
 <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
 <daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel@j-davis.com>
 <7a7a2f07-d013-eb80-85ba-9edaaf845038@2ndquadrant.com>
 <95b40ddcb3897772f075e6891521ee3f06f443d1.camel@j-davis.com>
 <93653d2b-7cf7-6992-7d3e-600ffd461354@2ndquadrant.com>
 <20190812171414.GX16436@tamriel.snowman.net>
Comments: In-reply-to Stephen Frost <sfrost@snowman.net>
	message dated "Mon, 12 Aug 2019 13:14:15 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12893.1565630766.1@sss.pgh.pa.us>
Date: Mon, 12 Aug 2019 13:26:06 -0400
Message-ID: <12894.1565630766@sss.pgh.pa.us>
Precedence: bulk

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