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

On Wed, 30 Sept 2026 at 17:40, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On 30 September 2026 16:13:58 BST, Kamil Tekiela <tekiela246@gmail.com> wrote: > >We are not lying to them right now. They can set longer passwords. > > > No, they can't. They can *input* longer passwords, but that input is not *stored*. > > If I encountered a database that truncates names to 10 bytes, I would describe it as not > correctly handling longer names. Telling users that they can set longer names, but never actually > storing them, would be lying. Passwords are not stored either. Only the hash is stored. The hash can be a result of multiple distinct inputs. There is no guarantee that a password will always produce a unique hash. > > >It will still match. A hash of 72-byte long password and a hash of > >73-byte long password where the first 72 bytes are the same will > >match. https://3v4l.org/o7dJq#v8.5.11 > > > Yes, and that is a false positive - the user provides the wrong password, and the system lets > them in. It's still a valid password. As I said, conflicts occur, so you don't have to provide the exact same password to be let in. Just one that produces the same hash. > > >Because the password is just as strong as it would be if we didn't > >ignore the unnecessary bytes. It would be corrupted if the password > >got weaker or changed in a way that it could no longer be verified > >against its hash. > > > Of course it gets weaker - it's shorter! Longer passwords are not automatically stronger. In fact, past a certain length, they are either all the same strength or even weaker because an attacker can guesstimate the used characters and structure, e.g. Diceware > >> Imagine if it truncated at 7 bytes; would you still call that "correct > >> handling", as long as it was documented behaviour? > > > >Obviously, yes. I don't understand your point. > > > Then we are stuck. I can't imagine how "most of your password is silently thrown > away" can be considered "correctly handled". It can be *a known limitation*, but from > a user's point of view, it's very clearly *not doing what they asked*, which was to set a > longer password. From a user's POV, it doesn't, and I agree with that. But that's not very important for what we are discussing here. If it works as designed, then it works correctly.