On 06/04/17 22:05, Tom Lane wrote:
Simon Riggs <si...@2ndquadrant.com> writes:
How would we provide the list of protocols? Surely the protocol is
defined by pg_hba.conf, which makes it dependent upon username,
database and ip range. If the list were accurate, it would allow an
attacker to discover how best to attack. If the list were inaccurate
it would just be an annoyance.
At minimum, providing the list of protocols means an extra round trip
to the server.
Yeah, that's a problem.

I don't see it. The message AuthenticationSASL.String could contain a CSV of the SCRAM protocols supported. This is specially important to support channel binding (which is just another protocol name for this matter), which is the really enhanced security mechanism of SCRAM. Since this message is sent regardless, and the client replies with PasswordMessage, no extra round trip is required. However, PasswordMessage needs to also include a field with the name of the selected protocol (it is the client who picks). Or a different message would need to be created, but no extra round-trips more than those required by SCRAM itself (4 messages for SCRAM + 1 extra for the server to tell the client it needs to use SCRAM).

ISTM that if you have a valid role to connect to then you'll also know
what authentication mechanism to use so you should be able to specify
the mechanism in your connection message and save the extra trip.
I do not buy that in the least.  It has never been the case before now
that clients know in advance what the auth challenge method will be.
If we put that requirement on them for SCRAM, we're just going to be
exporting a lot of pain and end-user-visible inconsistency.

Perhaps we could turn this around: have the client send (in the connection
request packet) a list of auth protocols it thinks it is able to handle.

Per the SCRAM RFC, it is the server who advertises and the client who picks.




Álvaro Hernández Tortosa


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to