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.
https://pentesterlab.com/blog/freshrss-bcrypt-truncation-auth-bypass
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
