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

Hi On 2026-09-30 09:26, Sjoerd Langkemper wrote:

The tradeoff is that actual passwords longer than 72 bytes are no longer supported. I think that is acceptable. I have gathered data showing that such passwords are exceedingly rare.

Even something that is “exceedingly rare” has a non-zero chance of occurring. And at the scale of PHP’s deployment it will occur at non-trivial numbers.

Also, if users genuinely need longer passwords, it is also not defensible to silently truncate the password.

Mathematically users don't *need* longer passwords, but they might *feel* they need longer passwords, because they are not aware of the maths behind it [1]. This is a user experience concern: If the user *feels* the need a long password to remain secure then telling them that their password is “too strong” will not help the user *feel* secure and they might be worried that the website is insecure for unfounded reasons. Best regards Tim Düsterhus [1] I'm seeing this all the time in code bases where developers call random_bytes() with an unreasonable output length, because “longer is better” and then also include “retry loops” in case the output *still* collided. 16 bytes / 128 bits matches the key size of AES-128, which is considered secure and the algorithm of choice for TLS server operators who care about performance rather than big numbers, this includes Google and Cloudflare who negotiate AES-128 rather than AES-256.