Re: Modern SHA2- based password hashes for pgcrypto
От | Japin Li |
---|---|
Тема | Re: Modern SHA2- based password hashes for pgcrypto |
Дата | |
Msg-id | ME0P300MB044591448FAFF397FFC1ED9CB6F02@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Modern SHA2- based password hashes for pgcrypto (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-hackers |
On Fri, 07 Feb 2025 at 10:31, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2025-Feb-07, Japin Li wrote: > >> Since there is no standard, how do we handle this? I prefer to use >> the strict mode like passlib. > > I definitely like that passlib have documented their thought process > thoroughly. > > I think using their strict mode is good on principle, but if we're going > to do that, then the salt string should not be used verbatim, but > instead base64-decoded first to get the actual salt bytes, like they do. > Does this break compabitibility with other systems? Are > passlib-generated password hashes incompatible with, say, "openssl > passwd" which you (Bernd) mentioned at the beginning of the thread? > Maybe if the password hashes are no longer compatible, then we should > ditch the idea of restricting salts to base64 chars and accept the whole > range of bytes, like Drepper. Thinking about compatibility, the Drepper's behavior is a good choice. Or we can accept the whole range of bytes except the $ character since it is a separator. Of course, it is also not compatible with other systems. > > But in any case ISTM we should reject, as they suggest, the use of less > than 4 bytes of salt (and should perhaps settle for a default of 16, as > passlib suggests). I suppose this is why passlib returns NULL with > empty salt. What we should do in that case IMO is ereport(ERROR). +1 -- Regrads, Japin Li
В списке pgsql-hackers по дате отправления: