Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256 |
| Дата | |
| Msg-id | CA+TgmoaCPffE4HWVLzgfRiJnyL8z-vfY1wY-k21jX5TTetXJLA@mail.gmail.com обсуждение исходный текст |
| Ответ на | [HACKERS] Implementation of SASLprep for SCRAM-SHA-256 (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: Implementation of SASLprep for SCRAM-SHA-256
|
| Список | pgsql-hackers |
On Tue, Mar 7, 2017 at 10:01 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > RFC5802 (https://tools.ietf.org/html/rfc5802) regarding the > implementation of SCRAM, needs to have passwords normalized as per > RFC4013 (https://tools.ietf.org/html/rfc4013) using SASLprep, which is > actually NFKC. I have previously described what happens in this case > here: > https://www.postgresql.org/message-id/CAB7nPqScgwh6Eu4=c-0L7-cufZrU5rULTSdpMOOWiz1YFvGE6w@mail.gmail.com > This way, we can be sure that two UTf-8 strings are considered as > equivalent in a SASL exchange, in our case we care about the password > string (we should care about the username as well). Without SASLprep, > our implementation of SCRAM may fail with other third-part tools if > passwords are not made only of ASCII characters. And that sucks. Agreed. I am not sure this quite rises to the level of a stop-ship issue; we could document the restriction. However, that's pretty ugly; it would be a whole lot better to get this fixed. I kinda hope Heikki is going to step up to the plate here, because I think he understands most of it already. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: