Hi Tim, On 30 September 2026 23:07:45 BST, "Tim Düsterhus" <[email protected]> wrote: >The same applies to Osage: The user is limited to the same 3 to 4 words and >will go with those rather than figuring out something more secure.
Would they? If I'm asked for a 6-character password, I don't go to a diceware list and pick one word. Worst case, they do just use those 3 words, and they're no worse off than before. Best case, they pick a different type of password and gain security. I don't see a scenario where they end up with something *worse*. > `substr($password, 0, 72)` which mimics the status quo, but would *carry > forward* the issue once `PASSWORD_DEFAULT` changes from BCrypt to something > else, whatever it may be. As a developer, I have three options of how to deal with the bcrypt limitation: 1) reject longer passwords 2) truncate longer passwords 3) use a different algorithm At the moment, if I don't choose explicitly, the implementation chooses option 2 for me. The RFC changes that to option 1, *but I still have the exact same choices*. Doing the truncation explicitly would mean I can correctly perform additional validation, such as looking up on haveibeenpwned, using the truncated string, not the full input. I would even argue that keeping the truncation after switching algorithm might be a valid choice, at least in a rehashing flow; because otherwise I am "rehashing" an input which might be varying every time the user types it, rather than the part of the string actually being verified. On the other hand, rejecting instead of truncating would mean I can correctly handle things like "must not match previously used password". And the user has the *chance* to change their behaviour based on the limitation, rather than being lied to. Neither solution is great, and yes, plenty of developers won't think it through, and plenty of users will set terrible passwords either way; but by making the limitation more noticeable, we at least give people a chance to do something about it. Rowan Tommins [IMSoP]
