Re: [RFC] Throw error for passwords longer than 72 bytes in password_hash() with bcrypt
| From: | Sjoerd Langkemper | Date: | Tue, 29 Sep 2026 13:03:59 +0000 |
| Subject: | Re: [RFC] Throw error for passwords longer than 72 bytes in password_hash() with bcrypt | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132692@lists.php.net to get a copy of this message | ||
On Tue, Sep 29, 2026, at 14:04, Kamil Tekiela wrote:
> On Tue, 29 Sept 2026 at 12:35, Sjoerd Langkemper wrote:
> > The proposal is to throw a ValueError when a password longer than 72 characters is passed
> > to password_hash and bcrypt is used.
>
> Checking that the input is less than 72 bytes long is the
> application's responsibility, not the algorithm's.
Thank you for your feedback. It is clear to me that you oppose my proposal as is. Do you have a
suggestion for improvement? Something I can change that would restrict misuse of password_hash but
would have your approvement?
> there will be users that will try such passwords and the
> application will crash for them instead of working correctly as
> before.
Yes, this can happen. This is an intentional tradeoff: my proposed change makes the situation more
secure, but could crash applications in some situations. I described in the RFC that users
rarely/never use passwords longer than 72 characters, so I think this is acceptable.
> Such a limitation would only help in really egregious cases of misuse,
> when a developer prepends an almost 72-byte string to a password or
> passes something other than a password as input. Both should be caught
> in a code review by a senior developer, not runtime.
The FreshRSS case is interesting here. Each change was reviewed and seemed secure, but the
combination resulted in authentication bypass. https://pentesterlab.com/blog/freshrss-bcrypt-truncation-auth-bypass
Regards,
Sjoerd