Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange |
Дата | |
Msg-id | 0fc10653-2eac-1340-b6e8-3ac560a0805d@8kdata.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange
Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange |
Список | pgsql-hackers |
On 06/04/17 22:05, Tom Lane wrote: > Simon Riggs <simon@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. Regards, Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
В списке pgsql-hackers по дате отправления: