From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Japin Li <japinli(at)hotmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Modern SHA2- based password hashes for pgcrypto |
Date: | 2025-02-06 10:20:31 |
Message-ID: | 202502061020.364t2wmbnuus@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-Jan-28, Bernd Helmle wrote:
> Python's passlib is very strict when it comes to supported characters
> within a salt string. It rejects everything thats not matching '[./0-
> 9A-Za-z]'. So when you provide the example above you get
The reason it uses these chars is that in their scheme the salt bytes
are base64-encoded.
The passlib docs has this page about the "modular crypt format":
https://passlib.readthedocs.io/en/stable/modular_crypt_format.html
and they point this other page as a "modern, non-ambiguous standard":
https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
About the salt, this last document says:
The role of salts is to achieve uniqueness. A random salt is fine for
that as long as its length is sufficient; a 16-byte salt would work
well (by definition, UUID are very good salts, and they encode over
exactly 16 bytes). 16 bytes encode as 22 characters in B64. Functions
should disallow salt values that are too small for security (4 bytes
should be viewed as an absolute minimum).
This "Password Hashing Competition" organization hardly seems an
authority though. It'd be great to have an IETF standard about this ...
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-02-06 10:27:17 | Move wal_buffers_full to WalUsage (and report it in pgss/explain) |
Previous Message | Zhang Mingli | 2025-02-06 10:09:42 | Re: Proposal to CREATE FOREIGN TABLE LIKE |