Date: Fri, 9 Aug 2019 12:00:21 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
Message-ID: <20190809030021.GG3194@paquier.xyz>
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="9Iq5ULCa7nGtWwZS"
Content-Disposition: inline
In-Reply-To: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
Precedence: bulk


--9Iq5ULCa7nGtWwZS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.

Thanks for working on this!

> I'm not 100% happy with the name "password_protocol", but other names I
> could think of seemed likely to cause confusion.

What about auth_protocol then?  It seems to me that it could be useful
to have the restriction on AUTH_REQ_MD5 as well.

> Sets the least-secure password protocol allowable when using password
> authentication. Options are: "plaintext", "md5", "scram-sha-256", or
> "scram-sha-256-plus".

This makes it sound like there is a linear hierarchy among all those
protocols, which is true in this case, but if the list of supported
protocols is extended in the future it may be not.

I think that this should have TAP tests in src/test/authentication/ so
as we make sure of the semantics.  For the channel-binding part, the
logic path for the test would be src/test/ssl.

+#define DefaultPasswordProtocol "plaintext"
I think that we are going to need another default value for that, like
"all" to reduce the confusion that SCRAM, MD5 and co are still
included in the authorized set in this case.

Another thing that was discussed on the topic would be to allow a list
of authorized protocols instead.  I personally don't think that we
need to go necessarily this way, but it could make the integration of
things line scram-sha-256,scram-sha-256-plus easier to integrate in
application flows.
--
Michael

--9Iq5ULCa7nGtWwZS
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl1M4cUACgkQnvQgOdby
QH1OvBAAoVOaEaw6N4ptF87Oz59q/uIRjmlDcyCTRFEPs+mXbjj5G7/9VcU3kGt6
nQuzJb3jUCgCumiQSdSy0Q9XYPKchrZj/bPW7iksOh3cT2k4CZiA7iwcrOJjJZmz
fZXqlozegCHJCRMZTeX56K8bzYzozPrmsxixQy6lHTapUaU3s27Fxu3qmyZgL82Q
pFcIb5MR3IbrZqNN5u3LWQDxVWFSNCo0vUyM9Xe1CqyEEqxFBWMns3VasJ70Vsaq
h77HQSHuo4pjQFNiHEdbboZOqqJJ0Sxwi5Qrl8XZc0oS9EOgt9G7lJYt1e07VzzU
7amCaWKvlL5Ikxy1G1xTYbLC+B7P5fB5P2+gbVExAI+6HZg10pIbamRmtmNXO53h
0F0jVwsQjNhBWBV2gKkSiApzidUBBooqIm7mwoTQe+ZtWzFfaHzWdHsrC9qCRYUT
8rnzkM2ffV8B/eHuefKNUsbQt8h85e/PSXUUiZNv16AxXRxEEa+HPbVlMxop+CQq
DQZuEZRrOlg3zjdTO0kTRcqko8hxw3PZER2LSfCTSUJwgpMgx2WivrrM840kQQa3
qeDgiCxK07eBcQztz8IXhIiCBlMsufrLz6/a0fFcreei2+CP2aWSVkDSIc6mu4d7
yONABEwSQ6MRcG7kao4O8Rh8MZtsgsehnCaPwfkrm4cfY39Shcw=
=qsel
-----END PGP SIGNATURE-----

--9Iq5ULCa7nGtWwZS--