Re: [HACKERS] SCRAM protocol documentation

Поиск
Список
Период
Сортировка
От Álvaro Hernández Tortosa
Тема Re: [HACKERS] SCRAM protocol documentation
Дата
Msg-id 7f864c1f-dd06-cca6-32de-e4555fb55d95@8kdata.com
обсуждение исходный текст
Ответ на Re: [HACKERS] SCRAM protocol documentation  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] SCRAM protocol documentation  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] SCRAM protocol documentation
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] Page Scan Mode in Hash Index