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.
