Re: [RFC] Throw error for passwords longer than 72 bytes in password_hash() with bcrypt

Hi On 2026-09-29 15:36, Rowan Tommins [IMSoP] wrote:

On 29 September 2026 13:04:21 BST, Kamil Tekiela <tekiela246@gmail.com> 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