Hi
On 2026-09-30 22:01, Andrey Andreev wrote:
I pointed to NIST SP 800-63 as the root source, but not the only
standard. If I pointed to the OWASP ASVS for example, most of what you
wrote would be irrelevant, but my basis - the correct implication of
the
bytes vs characters distinction - is still proven. All of the math
arguments you've brought up previously are eroded by that, and I really
must say it - deceiving developers and end-users about behavior is not
a
math problem to begin with.
Even with a non-ASCII 2-byte per character diceware password you are at
roughly 50 bits of entropy in the 72 bytes, which makes the math go from
“an attacker that started at the big bang still wouldn't have cracked
it” to “a dedicated attacker with 20_000 GPUs at hand might be able to
crack a single password within a year” (given the current default BCrypt
cost of 12 and 1.5kH/s/GPU which is within the range you mentioned in
the Argon2 thread). And as further elaborated below, the RFC does not
change that ceiling and turns the “not a math problem” into a usability
problem.
The RFC would thus trade a SHALL violation for a SHOULD deviation that
affects exactly the users using non-ASCII character sets.
I don't see an added SHALL violation; the RFC is only making an
already-present limitation visible.
I said that it would be trading a SHALL for a SHOULD, not that it would
add new SHALL violations. This is theoretically better when going purely
based on standard reading, but does not improve the real world
situation.
Might be true for CJK; not true for Cyrilic, Greek - halved in length
and
strength no matter how you look at it. And I'm not mentioning others
simply
because I'm not familiar with them, but there are multiple.
The conclusion remains the same: The user picks a shorter password and
you are back to square 1. And of course telling the user “your password
may be at most 72 bytes in length” when they don't know what bytes are
and why some characters are more than 1 byte (so they can't even count
the number of bullets in the password input to check if their password
fits) will just lead to frustrated users picking much weaker passwords
instead.
I don't necessarily disagree with the BCrypt truncation being a
problem,
but in this case the cure is worse than the disease.
As long as you recognize the problem, I don't think we'd be far apart.
I
absolutely recognize the BC break as a major concern that might take
higher
precedence. Until now though, your position has been a lot closer to
"no
problem here at all" than "I draw the line at breaking existing
applications".
Your interpretation is not quite correct. My position is roughly “it
sure would be better if BCrypt wouldn't have the truncation limit, but
that ship has sailed”. My main issue with this proposal is not the
“breaking existing applications” bit, but “forcing applications to
expose the byte limitation to the non-technical end user”. The RFC is
turning a theoretical security issue (for genuine passwords) into actual
usability issues for non-technical users who learned “longer = better”.
Best regards
Tim Düsterhus
