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

On 30 September 2026 15:08:23 BST, Kamil Tekiela <tekiela246@gmail.com> wrote: >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. Truncating passwords is *what happens right now*. Making that choice explicit means the behaviour is stable, e.g. a rehash with a different algorithm won't add previously insignificant input to the hash. It also prompts the developer to tell users that it's happening, although we can't force them to do that. > 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. >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. >The algorithm doesn't corrupt the passwords. How is deleting part of the input not corrupting it? >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? >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? Rowan Tommins [IMSoP]