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.
