Hi
On 2026-10-05 11:20, Sjoerd Langkemper wrote:
I propose to add a new hashing algorithm to use in password_hash and
password_verify.
RFC: https://wiki.php.net/rfc/bcrypt_sha256
PR: https://github.com/php/php-src/pull/24073
The existing bcrypt has problems with null bytes and only hashes the
first 72 bytes. The proposed PASSWORD_BCRYPT_SHA256 algorithm solves
those problems by first hashing the password with HMAC SHA256 before
passing it through bcrypt.
Tim suggested this in the discussion on my earlier RFC to throw errors
on passwords longer than 72 bytes
(https://wiki.php.net/rfc/bcrypt_max_password_length). That suggestion
receives much criticism because of its backwards incompatibility, and I
don't think it is worth pursuing further at the moment. I think this
new hash is a gentler way to solve the underlying problem.
Thank you for the RFC. I believe this is a much better solution than
modifying `PASSWORD_BCRYPT` in a way that breaks compatibility. I have
the following comments to the RFC:
1. The status in the RFC itself still says “Draft”.
2. The main NUL issue is resolved for PHP (by throwing ValueError for
new passwords). The proposal phrasing implies that this would not yet be
the case. In particular the referenced #21675 makes compatibility with
external BCrypt producers worse. The different between the NUL
truncation and the 72B truncation is that the latter is reasonably
reasonable by users, whereas NUL is not.
3. Unrelated to the primary topic and a separate concern: Should we add
support for the `$2b$` identifier? My understanding is that it's
identical to `$2y$`.
The proposal itself I support, with Python’s passlib there is precedent
and the proposed behavior is the obvious one.
Best regards
Tim Düsterhus
