5 ms·

You can also trivially truncate to 72 bytes server side.

Dylan16807 6y ago
That's a horrible thing to do. If you're really paranoid about cryptography then reject it. If you're slightly less paranoid then pass it through SHA512 before bcrypting it. Never silently truncate a password.
- fwip 6y ago
  Why not?
  - int_19h 6y ago
    Because you're misleading the user. Loudly complaining about invalid input is okay, but accepting and silently changing it in a way that affects it properties is not.
    - monadic2 6y ago
      How would the user tell the 73rd byte is truncated? Might as well call bcrypt itself misleading. In any case this doesn’t preclude client-side validation.
  - skosch 6y ago
    A year after you leave the job, your team is told to build a new auth backend against the database, using a different bcrypt implementation. They just know to use bcrypt, but not about your truncation hack. The deployment is a success. Two weeks later, an angry user (the only one with a 100-digit password) complains that they can't log in anymore. The guy is the company's best-paying customer; the boss is furious. The whole team goes on a wild goose chase for two days and nights just to find out what happened, as clearly there's nothing wrong with their code. A few years later, a former colleague shares the episode on HN. As you read the comments, it dawns on you that the idiot antagonist of the story is you. In this moment, you are enlightened.
    - deleted 6y ago
      [deleted]
    - fwip 6y ago
      The point of the upstream post was that bcrypt implementations often already truncate your passwords to 72 characters. If you switch to a different bcrypt implementation that does/does not truncate at 72 characters, the server-side truncation keeps all those 73 character passwords working. If the server-side truncation were not in place, you'd get angry users.
  - zrm 6y ago
    Suppose a user whose first name is Jonathan and whose wife's name is Katherine uses the password "JonathanAndKatherineLU8zWNmkimQanaSdPdqatWJEWR8goyyhdtQeqZOp2+0" and you truncate it to 20 characters.
    - monadic2 6y ago
      You would truncate to 72 bytes, not 20 characters (which might be more than 72 bytes anyway).
      - zrm 6y ago
        So potentially even worse. Somebody decides they don't like variable-width encodings and uses UTF-32 and now 72 bytes doesn't even get you 20 code points, only 18. But it's the same principle no matter where you cut. User thinks they can use an arbitrarily long password, puts a long but low entropy or easily guessable string at the front and makes up for it by having some good entropy at the end, and then you chop off the end.
- monadic2 6y ago
  Ah the explanation this was missing was that the length validation for bcrypt is sufficient to bypass truncation.

That's a horrible thing to do. If you're really paranoid about cryptography then reject it. If you're slightly less paranoid then pass it through SHA512 before bcrypting it. Never silently truncate a password.

fwip 6y ago
Why not?
- int_19h 6y ago
  Because you're misleading the user. Loudly complaining about invalid input is okay, but accepting and silently changing it in a way that affects it properties is not.
  - monadic2 6y ago
    How would the user tell the 73rd byte is truncated? Might as well call bcrypt itself misleading. In any case this doesn’t preclude client-side validation.
- skosch 6y ago
  A year after you leave the job, your team is told to build a new auth backend against the database, using a different bcrypt implementation. They just know to use bcrypt, but not about your truncation hack. The deployment is a success. Two weeks later, an angry user (the only one with a 100-digit password) complains that they can't log in anymore. The guy is the company's best-paying customer; the boss is furious. The whole team goes on a wild goose chase for two days and nights just to find out what happened, as clearly there's nothing wrong with their code. A few years later, a former colleague shares the episode on HN. As you read the comments, it dawns on you that the idiot antagonist of the story is you. In this moment, you are enlightened.
  - deleted 6y ago
    [deleted]
  - fwip 6y ago
    The point of the upstream post was that bcrypt implementations often already truncate your passwords to 72 characters. If you switch to a different bcrypt implementation that does/does not truncate at 72 characters, the server-side truncation keeps all those 73 character passwords working. If the server-side truncation were not in place, you'd get angry users.
- zrm 6y ago
  Suppose a user whose first name is Jonathan and whose wife's name is Katherine uses the password "JonathanAndKatherineLU8zWNmkimQanaSdPdqatWJEWR8goyyhdtQeqZOp2+0" and you truncate it to 20 characters.
  - monadic2 6y ago
    You would truncate to 72 bytes, not 20 characters (which might be more than 72 bytes anyway).
    - zrm 6y ago
      So potentially even worse. Somebody decides they don't like variable-width encodings and uses UTF-32 and now 72 bytes doesn't even get you 20 code points, only 18. But it's the same principle no matter where you cut. User thinks they can use an arbitrarily long password, puts a long but low entropy or easily guessable string at the front and makes up for it by having some good entropy at the end, and then you chop off the end.
monadic2 6y ago
Ah the explanation this was missing was that the length validation for bcrypt is sufficient to bypass truncation.