Hi
On 2026-10-01 08:57, Sjoerd Langkemper wrote:
Is there anything you could think of that would improve the situation
but would potentially have your approval? First switch the default
password hash from bcrypt to something else? Increase the length at
which an exception is thrown? Not an exception but a warning?
PHP Warnings are commonly converted to Exceptions by a throwing error
handler, particularly when using one of the major frameworks. The native
ErrorException exists just for this purpose. For a significant number of
applications emitting a warning is equivalent to throwing an Exception.
Regarding the length increase my understanding is that the argument in
favor of the RFC is that “silently truncating inputs is a security
issue”, so increasing the length would keep the security issue, while
also keeping the usability issue.
------
For PASSWORD_BCRYPT the only acceptable option to me is “leave it
alone”. Generally speaking user-provided passwords must never throw
(with the possible exception of ASCII control characters, including
NUL).
To provide a constructive suggestion: Borrowing passlib’s
`bcrypt-sha256`
(https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt_sha256.html)
algorithm (including the output format) might be a valid option for a
well-defined pre-hashing solution.
In fact even your RFC gets pre-hashing wrong by specifying that folks
should pass the raw prehash to BCrypt, which would result in a
ValueError for 12% of users (for SHA-256) due to a NUL byte appearing in
the raw output - and catastrophic NUL truncation if PHP would not be
checking for NUL. This is the kind of fragile workaround that I
mentioned in my reply to Rowan
(https://news-web.php.net/php.internals/132734).
Best regards
Tim Düsterhus
