On 29 September 2026 14:51:56 BST, "Tim Düsterhus" <[email protected]> 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]
