Re: [RFC] Throw error for passwords lo nger than 72 bytes in password_hash() with bcrypt

On 30 September 2026 16:47:30 BST, "Tim Düsterhus" <tim@bastelstu.be> wrote: >I would. This is in fact almost exactly the behavior of the classic 7ib >‰) ä«W7…·0¤$CRYPT_STD_DES algorithm, except the limit is 8 bytes (with the high bit >ignored) with a 64 bit internal state: Even if the additional characters would not be ignored, the >64 bit state means that there are equivalent inputs of 8 bytes or fewer for inputs of 9 bytes or >more. 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. 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. 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. 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. Hi Kamil, Tim, Replying to two messages in one here to cut down on traffic... On 30 September 2026 17:53:57 BST, Kamil Tekiela <tekiela246@gmail.com> wrote: >From a user's POV, it doesn't, and I agree with that. But that's not >very important for what we are discussing here. If it works as >designed, then it works correctly. I think this is the crux of our disagreement: I don't understand why the user's POV is "not very important". Rowan Tommins [IMSoP]