Feedback-ID: ia2694551:Fastmail
Date: Thu, 6 Feb 2025 11:20:31 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Bernd Helmle <mailings@oopsware.de>
Cc: Japin Li <japinli@hotmail.com>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Modern SHA2- based password hashes for pgcrypto
Message-ID: <202502061020.364t2wmbnuus@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0ea9c29350e76987e7564fac5662e8a5741ddfbf.camel@oopsware.de>
Archived-At: 
 <https://www.postgresql.org/message-id/202502061020.364t2wmbnuus%40alvherre.pgsql>
Precedence: bulk

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/