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

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. >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. >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! >> 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. Rowan Tommins [IMSoP]