From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Modern SHA2- based password hashes for pgcrypto |
Date: | 2025-02-07 09:31:44 |
Message-ID: | 202502070931.7mcjufnk5g5l@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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).
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Porque Kim no hacía nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2025-02-07 10:31:13 | Re: Increased work_mem for "logical replication tablesync worker" only? |
Previous Message | Álvaro Herrera | 2025-02-07 09:22:34 | Re: Docs for pg_basebackup needs v17 note for incremental backup |