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

On Wed, 30 Sept 2026 at 14:39, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > This is a good point, but I don't think it's a fatal problem. The affected > applications are the same ones liable to see the error for new passwords, and the fix is the same: > reject or explicitly truncate over-length inputs. Truncating passwords is just as bad or even worse. The user will have no idea that anything changed, and the developer has extra unnecessary code. Rejecting them helps nobody either. When you reject them, the user needs to truncate it without understanding why. No added security there. The security problems arise when developers are modifying passwords or applying arbitrary restrictions. We improve security by not forcing them to touch passwords. > In fact, I think it would make sense to add a *Warning* to password_verify and > password_needs_rehash, to prompt developers to check their implementation there as well. A warning is just a worse version of an exception. Besides, what are we warning them about? The fact that a user mistyped a password? The hash is already there, so comparing it with a password of arbitrary length makes no difference. > Such passwords should be rejected, not silently corrupted by an implementation detail of the > underlying hash algorithm. The algorithm doesn't corrupt the passwords. The algorithm correctly handles a password whether it's 8 bytes long or 80 bytes long. When the password is too long, it just ignores the extraneous input, but the security of the algorithm is the same.