On Wed, 30 Sept 2026 at 15:43, Rowan Tommins [IMSoP] <[email protected]> wrote: > > On 30 September 2026 15:08:23 BST, Kamil Tekiela <[email protected]> wrote: > >On Wed, 30 Sept 2026 at 14:39, Rowan Tommins [IMSoP] > ><[email protected]> wrote: > > > > Rejecting them helps nobody either. When you reject them, the > >user needs to truncate it without understanding why. No added security > >there. > > > The added security is not lying to users that they can set longer passwords.
We are not lying to them right now. They can set longer passwords. It's just that longer doesn't mean it's more secure. > >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. > > > We are warning them that the input provided by the user may not actually > match the password they provided at registration, because only part of it can > be verified against the stored hash. And that the user should be advised of > that fact. 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 > >The algorithm doesn't corrupt the passwords. > > > How is deleting part of the input not corrupting it? 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. > >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 > > > I find this statement completely baffling. It *silently throws away input*; I > simply do not accept that as "correctly handling" it. > > 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. > >the security of the algorithm is the same. > > > The algorithm treats 255 different 73-byte inputs as identical. A different > algorithm would distinguish them. Are you really saying those are equally > secure algorithms? Yes, that is what I am saying. Password length doesn't affect how secure the algorithm is. If bcrypt relied on password length for security, it would be an inadequate password-hashing algorithm. A 1-byte password is just as secure as a 1000-byte one when we are talking only about the algorithm's strength. 72 bytes is the input space, and that dictates how secure the algorithm is. The length of the actual input doesn't matter. >From the perspective of application security, developers may want to establish the minimum length to prevent users from entering easy-to-guess passwords, but that's to stop attackers from brute-forcing them. The hash of "password" or "123" is just as secure as the hash of the entire play of Hamlet. A user who chooses a password longer than 72 bytes may feel like the implementation is causing their password to be weaker because only the first 72 bytes matter, but that's not the case.
