On Tue, 29 Sept 2026 at 12:35, Sjoerd Langkemper <[email protected]> wrote: > > Hello, > > I have drafted a new RFC: https://wiki.php.net/rfc/bcrypt_max_password_length > > The proposal is to throw a ValueError when a password longer than 72 > characters is passed to password_hash and bcrypt is used. The current > behavior is that the password is silently truncated and only the first 72 > characters are hashed. > > The goal is to prevent severe security vulnerabilities that are the result of > this silent truncation. This will primarily impact applications that pass > something else than just the user's password to password_hash. Please let me > know what you think! > > Regards, > > Sjoerd
Checking that the input is less than 72 bytes long is the application's responsibility, not the algorithm's. The algorithm is designed in a way that you don't need to worry about too-long passphrases as an application developer. Vulnerabilities come from developers trying to outsmart the algorithm by modifying passwords before hashing or by providing something other than a password/passphrase as an input. No change to the algorithm is going to prevent that. 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. If an application doesn't limit user password length to 72 bytes, there will be users that will try such passwords and the application will crash for them instead of working correctly as before. And since an overlong password is an acceptable input, that error is not going to help neither the user or the developer. Such a limitation would only help in really egregious cases of misuse, when a developer prepends an almost 72-byte string to a password or passes something other than a password as input. Both should be caught in a code review by a senior developer, not runtime.
