Hi
On 2026-09-30 23:04, Rowan Tommins [IMSoP] wrote:
Let's follow this example a bit:
If a system used CRYPT_STD_DES, and limited user input to 8 bytes, you
might have colliding hashes for "password" and "@7&jp9Q -".
If the system did *not* limit user entry, it would have colliding
hashes for "password1234" and "password !!! password". Note that both
would pass a check for "include at least one digit or punctuation
mark", but both would actually be breached by someone trying the input
"password" which has neither.
Yes, but looping back to the initial example you provided: Someone using
the strong randomly generated password "@7&jp9Q -" might still be
breached by someone trying "password", a property of the small state
space and why DES crypt is no longer secure.
Now, truncating at 72 bytes is obviously very different from truncating
at 8, but it's possible to imagine scenarios where it could lead to a
meaningful loss of entropy.
Indeed for BCrypt the situation is quite different: The 72-byte prefix
is only guessable if it is predictable on its own (e.g. someone
selecting their favorite lyrics). In that case the password is weak with
or without the suffix, since you can just plug in the prefix into a
search engine and look up how the song continues. The RFC will do
nothing for them: They are just going to pick the same song, but cut the
lyrics after one verse rather than two.
A quick search found this alphabet:
<https://en.wikipedia.org/wiki/Osage_script> Stored high enough in
Unicode that it requires 4 bytes of UTF-8 per character, *and* requires
combining diacritics for some sounds. A diceware password of words in
that script might truncate at 3 or 4 words.
The same applies to Osage: The user is limited to the same 3 to 4 words
and will go with those rather than figuring out something more secure.
See also my reply to Andrey.
More likely, as already discussed, a developer misuses the API and
prefixes a password, cutting the effective length limit.
It seems to me that refusing those inputs and alerting the developer to
the limitation leaves the *overall system* more secure.
My expectation is that developers who are “alerted” to the limitation
will just go with whatever solution makes the error message go away the
quickest instead of trying to understand the impact, leaving the overall
system in a less secure state. Incorrect prehashing would be a good
example here: In an attempt to “fix” BCrypt’s length limitation, folks
have passed the *raw* output of a hash function to BCrypt, resulting in
NUL-termination becoming relevant and thus reducing security more than
the 72-byte limit ever could. Now the NUL-termination issue is caught by
PHP nowadays, but I'm positive that folks will figure out equally
fragile workarounds. The obvious one being `substr($password, 0, 72)`
which mimics the status quo, but would *carry forward* the issue once
`PASSWORD_DEFAULT` changes from BCrypt to something else, whatever it
may be.
Best regards
Tim Düsterhus
