Hi
On 2026-09-29 15:36, Rowan Tommins [IMSoP] wrote:
On 29 September 2026 13:04:21 BST, Kamil Tekiela <[email protected]>
wrote:
By adding a ValueError which only fires when the input is too long,
you are introducing a silent failure vector that is difficult to catch
or test for.
On the contrary, it turns a silent failure into a noisy one, prompting
the developer to take action.
There is no silent failure here. BCrypt acts according to its
specification.
[…] it was accepting passwords that it could not verify later […]
I assume it is ambiguous phrasing, but to be clear: Any passwords
accepted by password_hash() will verify with password_verify().
And since an overlong password is an acceptable input
Why is it an acceptable input? If the algorithm can't correctly hash
that input, why should it tell the user it has done so?
It would be a problem if users who have *already* set passwords which
they intended to be longer than 72 bytes are prevented from logging in,
but the proposal covers that by leaving password_verify unchanged.
The login will start to fail when the password is being rehashed
(password_needs_rehash()) due to a change in the algorithm parameters,
such as when increasing the (default) BCrypt cost.
Both should be caught in a code review no a senior developer, not
runtime.
If every PHP login implementation was reviewed by an expert senior
developer, we would not need the password_* API in the first place. The
value of this API is that it makes doing the right thing easy, so that
you *don't* need to be an expert in the underlying algorithms to use it
safely.
The API is safe if you pass a “password” to it (as the name indicates).
The issues described in the RFC were caused by folks passing something
that is not a password.
Best regards
Tim Düsterhus
