[PHP-DEV] [RFC] Throw error for passwords longer than 72 bytes in password_hash() with bcrypt

Mailing Lists php.internals
1

Hello,

I have drafted a new RFC: https://wiki.php.net/rfc/bcrypt_max_password_length

The proposal is to throw a ValueError when a password longer than 72 characters is passed to password_hash and bcrypt is used. The current behavior is that the password is silently truncated and only the first 72 characters are hashed.

The goal is to prevent severe security vulnerabilities that are the result of this silent truncation. This will primarily impact applications that pass something else than just the user’s password to password_hash. Please let me know what you think!

Regards,

Sjoerd

2

On Tue, 29 Sept 2026 at 12:35, Sjoerd Langkemper
<sjoerd-php@linuxonly.nl> wrote:

Hello,

I have drafted a new RFC: PHP: rfc:bcrypt_max_password_length

The proposal is to throw a ValueError when a password longer than 72 characters is passed to password_hash and bcrypt is used. The current behavior is that the password is silently truncated and only the first 72 characters are hashed.

The goal is to prevent severe security vulnerabilities that are the result of this silent truncation. This will primarily impact applications that pass something else than just the user's password to password_hash. Please let me know what you think!

Regards,

Sjoerd

Checking that the input is less than 72 bytes long is the
application's responsibility, not the algorithm's. The algorithm is
designed in a way that you don't need to worry about too-long
passphrases as an application developer. Vulnerabilities come from
developers trying to outsmart the algorithm by modifying passwords
before hashing or by providing something other than a
password/passphrase as an input. No change to the algorithm is going
to prevent that.

By adding a ValueError which only fires when the input is too long,
you are introducing a silent failure vector that is difficult to catch
or test for. If an application doesn't limit user password length to
72 bytes, there will be users that will try such passwords and the
application will crash for them instead of working correctly as
before. And since an overlong password is an acceptable input, that
error is not going to help neither the user or the developer.

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.

3

Hi

On 2026-09-29 14:04, Kamil Tekiela wrote:

[…]

I agree with that in full.

Best regards
Tim Düsterhus

4

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

5

On 29 September 2026 13:04:21 BST, Kamil Tekiela <tekiela246@gmail.com> wrote:

By adding a ValueError which only fires when the input is too long,
you are introducing a silent failure vector that is difficult to catch
or test for.

On the contrary, it turns a silent failure into a noisy one, prompting the developer to take action.

If an application doesn't limit user password length to
72 bytes, there will be users that will try such passwords and the
application will crash for them instead of working correctly as
before.

Such a system was not working correctly before - it was accepting passwords that it could not verify later, and consequently accepting logins which did not match the user's intended password.

And since an overlong password is an acceptable input

Why is it an acceptable input? If the algorithm can't correctly hash that input, why should it tell the user it has done so?

It would be a problem if users who have *already* set passwords which they intended to be longer than 72 bytes are prevented from logging in, but the proposal covers that by leaving password_verify unchanged.

Both should be caught in a code review no a senior developer, not runtime.

If every PHP login implementation was reviewed by an expert senior developer, we would not need the password_* API in the first place. The value of this API is that it makes doing the right thing easy, so that you *don't* need to be an expert in the underlying algorithms to use it safely.

I support the RFC as currently proposed.

Rowan Tommins
[IMSoP]

6

Hi

On 2026-09-29 15:03, Sjoerd Langkemper wrote:

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.

The limit is 72 *bytes*, not 72 *characters*. This is a meaningful difference: It means that users might be presented an error for non-ASCII passwords.

An 8-word Diceware password comes in at 100 bits of entropy and is roughly around 72 bytes in length. A 9-word password would exceed the limit, but the extra entropy above 100 bits is not really meaningful with regard to security, so just ignoring that extra word is fine.

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. How "Strengthening Crypto" Broke Authentication: FreshRSS and bcrypt's 72-Byte Limit

The specified authentication protocol with “client side hashing” is a classic case of “rolling your own crypto” and it exposes the BCrypt salt to the client, likely to everyone who asks, since it clearly is pre-auth. I disagree with calling that part “seemingly secure”.

Even the updated nonce-generation, while better than before due to the use of the CSPRNG, includes needless security theater. The `random_bytes()` is what makes the nonce secure. Neither the system salt nor the username needs to be included and the SHA-256 hash just acts as a PRF, so saying “SHA-256 is stronger than SHA-1” is correct, but also utterly meaningless.

The write-up summarizes it well: “Over-engineering can hurt security”. The issue was not caused by the BCrypt truncation, it was caused my multiple problematic decisions. The latter includes the BCrypt truncation, but that ship has sailed and trying to enforce limits that BCrypt itself does not is making the situation worse.

Best regards
Tim Düsterhus

7

Hi

On 2026-09-29 15:36, Rowan Tommins [IMSoP] wrote:

On 29 September 2026 13:04:21 BST, Kamil Tekiela <tekiela246@gmail.com> wrote:

By adding a ValueError which only fires when the input is too long,
you are introducing a silent failure vector that is difficult to catch
or test for.

On the contrary, it turns a silent failure into a noisy one, prompting the developer to take action.

There is no silent failure here. BCrypt acts according to its specification.

[…] it was accepting passwords that it could not verify later […]

I assume it is ambiguous phrasing, but to be clear: Any passwords accepted by password_hash() will verify with password_verify().

And since an overlong password is an acceptable input

Why is it an acceptable input? If the algorithm can't correctly hash that input, why should it tell the user it has done so?

It would be a problem if users who have *already* set passwords which they intended to be longer than 72 bytes are prevented from logging in, but the proposal covers that by leaving password_verify unchanged.

The login will start to fail when the password is being rehashed (password_needs_rehash()) due to a change in the algorithm parameters, such as when increasing the (default) BCrypt cost.

Both should be caught in a code review no a senior developer, not runtime.

If every PHP login implementation was reviewed by an expert senior developer, we would not need the password_* API in the first place. The value of this API is that it makes doing the right thing easy, so that you *don't* need to be an expert in the underlying algorithms to use it safely.

The API is safe if you pass a “password” to it (as the name indicates). The issues described in the RFC were caused by folks passing something that is not a password.

Best regards
Tim Düsterhus

8

On Tue, Sep 29, 2026, at 15:51, Tim Düsterhus wrote:

The API is safe if you pass a “password” to it (as the name indicates).
The issues described in the RFC were caused by folks passing something
that is not a password.

Exactly, and my proposal aims to throw a ValueError in those cases, indicating that it is a programming error to pass anything other than password. The tradeoff is that actual passwords longer than 72 bytes are no longer supported. I think that is acceptable. I have gathered data showing that such passwords are exceedingly rare. Also, if users genuinely need longer passwords, it is also not defensible to silently truncate the password.

The login will start to fail when the password is being rehashed
(password_needs_rehash()) due to a change in the algorithm parameters

That is a good point, I had not considered that. Thanks.

Regards,

Sjoerd

9

Exactly, and my proposal aims to throw a ValueError in those cases, indicating that it is a programming error to pass anything other than password. The tradeoff is that actual passwords longer than 72 bytes are no longer supported. I think that is acceptable.

The function signature already says it will accept a `string` value,
and it is already working under this contract. Limiting it to 72 bytes
does not ensure the passed string is a password, and it is merely an
implementation detail for bcrypt. The php.net manual page for
`password_hash` also already mentions the 72-byte truncation behavior.

Passing an invalid hashing algorithm, unsupported algorithm options,
RNG failures, etc., are indeed programmer/program errors, and it
already throws hard exceptions/errors in those cases.

I wouldn't also characterize the two vulnerabilities mentioned in the
RFC (in other software) as related. In PHP, the salt is now (PHP 7+)
always generated automatically, and the password_hash() output is not
limited to a certain length. While I agree that vulnerable software
could be written around bcrypt's 72-byte behavior, it would not be a
strong relation to PHP.

Thank you,
Ayesh.

10

Hi all,

I echo Rowan’s response and find some of the opposing arguments quite strange:

The limit is 72 bytes, not 72 characters. This is a meaningful
difference: It means that users might be presented an error for
non-ASCII passwords.

That’s a good argument against the current silent truncation behavior, because:

  • It also means effective length can be at least halved, depending on the character set in use.
  • Some character sets (most prominently UTF-16) specifically use NUL bytes inside character codes.

Not accounting for these issues violates modern security standards. I could list multiple, but in all honestly they’re universal consensus on what’s already established by NIST, so see that: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf#subsubsection.3.1.1

An 8-word Diceware password comes in at 100 bits of entropy and is
roughly around 72 bytes in length. A 9-word password would exceed the
limit, but the extra entropy above 100 bits is not really meaningful
with regard to security, so just ignoring that extra word is fine.

It is inappropriate for us to make such a decision for end users. Doubly so when the user would be completely unaware of it, which is what happens when you have silent truncation.

I’ve personally witnessed many lack-of-MFA “mitigation” strategies that rely on absurdly-long passwords, and the people involved in those decisions didn’t even include developers. GRC types and over-confident IT admins trying to reason about how to use off-the-shelf software. To account for bcrypt’s inherent limitation in this context would require people with very specialized skills and superhuman foresight.

[… in response to the FreshRSS example …]

The write-up summarizes it well: “Over-engineering can hurt security”.
The issue was not caused by the BCrypt truncation, it was caused my
multiple problematic decisions. The latter includes the BCrypt
truncation, but that ship has sailed and trying to enforce limits that
BCrypt itself does not is making the situation worse.

Bcrypt is the footgun that fired. Yes, the FreshRSS dev(s) made many wrong decisions and clearly didn’t understand what they were doing. Okta also fell into a trap and that’s a company which no doubt most people here would trust on security matters. That in itself demonstrates why truncate-at-72-bytes is a bcrypt deficiency that we should want to fix - the number of people who truly understand the problem space is extremely small.

The RFC is rather roughly-argumented as is (I’d be happy to help Sjoerd with that) and there’s plenty of room to debate on BC break grounds, but the problem it tries to address is spot on.

P.S. I’ve quoted Tim, but only because he’s been most thorough and well-worded; other responses have made even less logical sense.

Cheers,
Andrey.

11

On 29 September 2026 14:51:56 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote:

There is no silent failure here. BCrypt acts according to its specification.

I think we're coming at this from opposite directions: you're looking at bcrypt as an algorithm, and saying that it has a well-defined behaviour; I am looking at password verification as a task, and saying that bcrypt performs that task incorrectly for long inputs.

[…] it was accepting passwords that it could not verify later […]

I assume it is ambiguous phrasing, but to be clear: Any passwords accepted by password_hash() will verify with password_verify().

You're right, it was ambiguous - I was talking about false positives, rather than false negatives. That is, a correctly entered password will be accepted, but an incorrectly entered password may *also* be accepted.

Another failure state would be password change policies which mandate "must not match previous X passwords". A user would reasonably expect that adding or changing something at the end of a long passphrase would be allowed; but since the passphrase was silently truncated, their change would be rejected.

The login will start to fail when the password is being rehashed

(password_needs_rehash()) due to a change in the algorithm parameters,
such as when increasing the (default) BCrypt cost.

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.

In fact, I think it would make sense to add a *Warning* to password_verify and password_needs_rehash, to prompt developers to check their implementation there as well.

There's actually another rehash edge case: the developer switches the preferred algorithm from bcrypt to argon2, and the user enters more than 72 bytes at login. The additional bytes won't be verified against the old hash, so might include a typo; but the full input will be used in the new hash, so the user will be locked out unless they can reproduce that typo.

The API is safe if you pass a “password” to it (as the name indicates). The issues described in the RFC were caused by folks passing something that is not a password.

As you pointed out yourself, a real user password could exceed the limit if using a multibyte encoding, or a diceware phrase.

Such passwords should be rejected, not silently corrupted by an implementation detail of the underlying hash algorithm.

Rowan Tommins
[IMSoP]

12

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. The user will have
no idea that anything changed, and the developer has extra unnecessary
code. Rejecting them helps nobody either. When you reject them, the
user needs to truncate it without understanding why. No added security
there.

The security problems arise when developers are modifying passwords or
applying arbitrary restrictions. We improve security by not forcing
them to touch passwords.

In fact, I think it would make sense to add a *Warning* to password_verify and password_needs_rehash, to prompt developers to check their implementation there as well.

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.

Such passwords should be rejected, not silently corrupted by an implementation detail of the underlying hash algorithm.

The algorithm doesn't corrupt the passwords. 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, but
the security of the algorithm is the same.

13

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]

14

On Wed, 30 Sept 2026 at 15:43, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

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:
>
> 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. Online PHP editor | output for o7dJq

>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.

15

Hi

On 2026-09-30 16:34, Rowan Tommins [IMSoP] wrote:

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?

I would. This is in fact almost exactly the behavior of the classic `CRYPT_STD_DES` algorithm, except the limit is 8 bytes (with the high bit ignored) with a 64 bit internal state: Even if the additional characters would not be ignored, the 64 bit state means that there are equivalent inputs of 8 bytes or fewer for inputs of 9 bytes or more.

It is no longer secure today due to the 56-bit key size, but given the computing limitations back then, I would consider it reasonable. Of course users will not be entering raw bytes, but characters. Still 8 randomly selected alphanumeric bytes would be around 48 bits of entropy.

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?

An ASCII diceware password is probably the least information dense method of choosing a secure password and as per the math I provided in php.internals: Re: [RFC] Throw error for passwords longer than 72 bytes in password_hash() with bcrypt, you can fit 100 bits of “Diceware entropy” into the 72 byte limit. While not “equally secure” under a literal reading you are well past the point of diminishing returns: Trying to guess 100 bits of entropy is impossible, trying to guess 101 bits is just more impossible. The “stretching” provided by BCrypt’s cost factor effectively adds another $cost number of bits of effective security, since increasing the cost by 1 doubles the execution time.

Constructing one of the 255 colliding 73-byte inputs requires you to know the 72-byte prefix. In practice knowing the prefix means that you know the password, so the extra bytes are irrelevant for security. Furthermore similarly to the classic DES crypt, BCrypt also has an output size of 184 bits. Once the input exceeds that, there's a different input that results in the same output. This is a fundamental information theoretic limit, not an arbitrarily selected one. For a completely random 40 byte input you are already well beyond the output size, so some 40 byte inputs necessarily collide, but this doesn't mean it's feasible to find those.

Forcing the user to select a different password by emitting an error message if they input a needlessly long one (“more is better”) is not improving the security, while decreasing user experience.

Best regards
Tim Düsterhus

16

Hi

On 2026-09-30 09:26, Sjoerd Langkemper wrote:

The tradeoff is that actual passwords longer than 72 bytes are no longer supported. I think that is acceptable. I have gathered data showing that such passwords are exceedingly rare.

Even something that is “exceedingly rare” has a non-zero chance of occurring. And at the scale of PHP’s deployment it will occur at non-trivial numbers.

Also, if users genuinely need longer passwords, it is also not defensible to silently truncate the password.

Mathematically users don't *need* longer passwords, but they might *feel* they need longer passwords, because they are not aware of the maths behind it [1]. This is a user experience concern: If the user *feels* the need a long password to remain secure then telling them that their password is “too strong” will not help the user *feel* secure and they might be worried that the website is insecure for unfounded reasons.

Best regards
Tim Düsterhus

[1] I'm seeing this all the time in code bases where developers call `random_bytes()` with an unreasonable output length, because “longer is better” and then also include “retry loops” in case the output *still* collided. 16 bytes / 128 bits matches the key size of AES-128, which is considered secure and the algorithm of choice for TLS server operators who care about performance rather than big numbers, this includes Google and Cloudflare who negotiate AES-128 rather than AES-256.

17

On 30 September 2026 16:13:58 BST, Kamil Tekiela <tekiela246@gmail.com> wrote:

We are not lying to them right now. They can set longer passwords.

No, they can't. They can *input* longer passwords, but that input is not *stored*.

If I encountered a database that truncates names to 10 bytes, I would describe it as not correctly handling longer names. Telling users that they can set longer names, but never actually storing them, would be lying.

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. Online PHP editor | output for o7dJq

Yes, and that is a false positive - the user provides the wrong password, and the system lets them in.

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.

Of course it gets weaker - it's shorter!

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.

Then we are stuck. I can't imagine how "most of your password is silently thrown away" can be considered "correctly handled". It can be *a known limitation*, but from a user's point of view, it's very clearly *not doing what they asked*, which was to set a longer password.

Rowan Tommins
[IMSoP]

18

On Wed, 30 Sept 2026 at 17:40, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 30 September 2026 16:13:58 BST, Kamil Tekiela <tekiela246@gmail.com> wrote:
>We are not lying to them right now. They can set longer passwords.

No, they can't. They can *input* longer passwords, but that input is not *stored*.

If I encountered a database that truncates names to 10 bytes, I would describe it as not correctly handling longer names. Telling users that they can set longer names, but never actually storing them, would be lying.

Passwords are not stored either. Only the hash is stored. The hash can
be a result of multiple distinct inputs. There is no guarantee that a
password will always produce a unique hash.

>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. Online PHP editor | output for o7dJq

Yes, and that is a false positive - the user provides the wrong password, and the system lets them in.

It's still a valid password. As I said, conflicts occur, so you don't
have to provide the exact same password to be let in. Just one that
produces the same hash.

>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.

Of course it gets weaker - it's shorter!

Longer passwords are not automatically stronger. In fact, past a
certain length, they are either all the same strength or even weaker
because an attacker can guesstimate the used characters and structure,
e.g. Diceware

>> 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.

Then we are stuck. I can't imagine how "most of your password is silently thrown away" can be considered "correctly handled". It can be *a known limitation*, but from a user's point of view, it's very clearly *not doing what they asked*, which was to set a longer password.

From a user's POV, it doesn't, and I agree with that. But that's not
very important for what we are discussing here. If it works as
designed, then it works correctly.

19

Hi,

On Wed, Sep 30, 2026 at 7:56 PM Kamil Tekiela <tekiela246@gmail.com> wrote:

Yes, and that is a false positive - the user provides the wrong password, and the system lets them in.

It’s still a valid password. As I said, conflicts occur, so you don’t
have to provide the exact same password to be let in. Just one that
produces the same hash.

You can’t base your argument on the premise that it’s all fine because the algorithm itself is strong and at the same time claim that conflicts occur. Collision resistance underpins all security claims about hashing algorithms.

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.

Then we are stuck. I can’t imagine how “most of your password is silently thrown away” can be considered “correctly handled”. It can be a known limitation, but from a user’s point of view, it’s very clearly not doing what they asked, which was to set a longer password.

From a user’s POV, it doesn’t, and I agree with that. But that’s not
very important for what we are discussing here. If it works as
designed, then it works correctly.

… and who’s to say that the design is correct to begin with?
Why are you assuming that a design from 1999 has seriously considered the problem at hand?
Will a 32-bit UNIX timestamp be correct in 2038?

It is very hard to respect your POV when it’s based on circular logic.

Cheers,
Andrey.

20

Hi

On 2026-09-30 15:00, Andrey Andreev wrote:

The limit is 72 *bytes*, not 72 *characters*. This is a meaningful

difference: It means that users might be presented an error for
non-ASCII passwords.

That's a good argument *against* the current silent truncation behavior,
because:
- It also means effective length can be at least halved, depending on the
character set in use.
- Some character sets (most prominently UTF-16) specifically use NUL bytes
inside character codes.

Not accounting for these issues violates modern security standards. I could
list multiple, but in all honestly they're universal consensus on what's
already established by NIST, so see that:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf#subsubsection.3.1.1

You are correct in that the NIST standard specifies that:

9. Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it)

However: The NIST standard applies to the “Verifier” (i.e. the application), not to the primitive. While `password_hash()` is certainly intended to be usable as-is, an application requiring strict compliance with all SHALLs and SHOULDs of the NIST standard already needs to perform some steps that cannot be solved by `password_hash()`, such as verifying that known-insecure passwords cannot be used. And when trying for pedantic compliance with NIST you cannot use BCrypt at all, since BCrypt technically is not in the list of NIST-approved hashing functions. For that you need an approved hash function, and my latest knowledge is that neither BCrypt nor Argon2’s BLAKE2b primitive are acceptable. In practice this means using `hash_pbkdf2()`.

If we ignore all that, implementing the RFC would mean that BCrypt hashing with PHP would start to deviate from a combination of two different requirements:

2. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.

and

4. Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

The RFC would thus trade a SHALL violation for a SHOULD deviation that affects exactly the users using non-ASCII character sets.

And while the effective length is reduced for e.g. CJK characters, they are also much more information dense than ASCII characters. An English word taking up 5-7 bytes can often be represented as a single 3-byte CJK character. Of course the RFC also does nothing about this: Instead of reducing the effective length, inputs exceeding “the effective length” are rejected, forcing the user to pick a shorter password. The achievable security ceiling is the same - and high enough.

The NUL byte point is moot, because NUL bytes are already rejected during hashing. For that I agree with the ValueError / check, since the truncation on NUL is much more catastrophic - and because actually including a NUL in a legit user-provided password is much more complicated than exceeding a 72 byte limit. In practice the Internet has also converged on “just using UTF-8”.

It is inappropriate for us to make such a decision for end users. Doubly so
when the user would be completely unaware of it, which is what happens when
you have silent truncation.

I've personally witnessed many lack-of-MFA "mitigation" strategies that
rely on absurdly-long passwords, and the people involved in those decisions
didn't even include developers. GRC types and over-confident IT admins
trying to reason about how to use off-the-shelf software. To account for
bcrypt's inherent limitation in this context would require people with very
specialized skills and superhuman foresight.

I did the math in a sibling email: Truncating absurdly-long passwords still results in “you ain't gonna need it” amounts of entropy.

The RFC is rather roughly-argumented as is (I'd be happy to help Sjoerd
with that) and there's plenty of room to debate on BC break grounds, but
the problem it tries to address is spot on.

I don't necessarily disagree with the BCrypt truncation being a problem, but in this case the cure is worse than the disease.

Best regards
Tim Düsterhus