Re: [HACKERS] SCRAM protocol documentation - Mailing list pgsql-hackers
From | Álvaro Hernández Tortosa |
---|---|
Subject | Re: [HACKERS] SCRAM protocol documentation |
Date | |
Msg-id | 7f864c1f-dd06-cca6-32de-e4555fb55d95@8kdata.com Whole thread Raw |
In response to | Re: [HACKERS] SCRAM protocol documentation (Michael Paquier <michael.paquier@gmail.com>) |
Responses |
Re: [HACKERS] SCRAM protocol documentation
|
List | pgsql-hackers |
On 11/08/17 15:00, Michael Paquier wrote: > On Fri, Aug 11, 2017 at 9:31 PM, Álvaro Hernández Tortosa > <aht@8kdata.com> wrote: >> On 11/08/17 13:18, Michael Paquier wrote: >>> On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa >>> <aht@8kdata.com> wrote: >>>>> Relatedly, the SCRAM specification doesn't appear to allow omitting the >>>>> user name in this manner. Why don't we just send the actual user name, >>>>> even though it's redundant with the startup message? >>> The problem is where a username includes characters as a comma or '=', >>> which can be avoided if the string is in UTF-8 as the username is >>> prepared with SASLprep before being used in the SASL exchange, but we >>> have no way now to be sure now that the string is actually in UTF-8. >>> If at some point we decide that only things using UTF-8 are good to be >>> used during authentication, using the username in the exchange >>> messages instead of the one in the startup packet would be fine and >>> actually better IMO in the long term. Please note that the >>> specification says that both the username and the password must be >>> encoded in UTF-8, so we are not completely compliant here. If there is >>> something to address, that would be this part. >> The reason why the username is ignored, unless I'm wrong, is not exactly >> that it is already sent. It is that Postgres does not restrict usernames to >> be UTF-8 only, while SCRAM does. As such, if a username would not be UTF-8, >> it will not be sent reliably over SCRAM. > That's basically the point I was making. Note that I would not be > against Postgres forcing strings to be in UTF-8. Now things are fuzzy > because of the lack of restrictions. I'm +10000 for that. But I guess that involves a protocol change, and that's a completely different can of worms.... > >>>> If there's a clear meaning about ignoring the user here, why not >>>> settle >>>> on something like the "*"? It's not going to change the world sending a >>>> few >>>> bytes less on initialization, but I guess it doesn't hurt either... >>> I am not sure either that '*' would be that much helpful. Requiring >>> that things are in UTF-8 would be more compliant with the original >>> RFC. >> But we really don't need to send the username, since Postgres already >> knows it (and that accommodates for non UTF-8 usernames). So why bother? >> Just sending something like "*" (which is UTF-8 and produces the same value >> under Saslprep) should be enough. I think the idea of ignoring the username >> is pretty neat, but maybe a "standard" like "send me an asterisk here" could >> be even better than leaving it empty. > Personally I don't see much difference between both, so I'd rather > leave things as they are now. Strictly speaking the RFC assumes that the username is at least 1 character. I understand this was precisely Peter's original comment. Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
pgsql-hackers by date: