Re: [RFC] Throw error for passwords lo nger than 72 bytes in password_hash() with bcrypt
| From: | Rowan Tommins [IMSoP] | Date: | Thu, 01 Oct 2026 08:08:42 +0000 |
| Subject: | Re: [RFC] Throw error for passwords lo nger than 72 bytes in password_hash() with bcrypt | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132740@lists.php.net to get a copy of this message | ||
Hi Tim,
On 30 September 2026 23:07:45 BST, "Tim Düsterhus" <tim@bastelstu.be> 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]