Hacker News Reader

Comment by thirsteh | Hacker News Reader

With bcrypt you should set a limit of 72 bytes to avoid fooling users into thinking the stuff beyond the 72nd byte matters (bcrypt truncates it.)

View on HN

Why should I have to choose a different, shorter password because of your implementation details? Seems like an unnecessary annoyance.

It is annoying, but it is necessary to avoid users choosing longer passwords where the necessary randomness is beyond the 72nd byte. Allowing a password of unlimited length when you support only e.g. 20 or 50 bytes is just as bad as putting in a maximum length restriction when you don't have one. Ideally, just use scrypt or PBKDF2, which don't have length restrictions.

I wouldn't want to limit the password a user supplies. Any password should work, including 1 byte or 1 gb passwords. Restrictions of any form have always just caused more problems than they've solved.

But the solution I've favored is hashing the user's password on the client with a hash that provides enough significant bits that your key derivation on the server is not weakened. This way you get the benefit of not needing to deal with differences in transmission size and the user's plaintext password is never exposed to any listener (regardless of whether the connection is secure, or believed to be secure).

Your passwords are routinely longer than 72 bytes, and this is an inconvenience?

Or hash it first using SHA3. Then you get the slowness of bcrypt (which is what you're using it for) and the variable length input of SHA3. You're only risk is a SHA3 collision, which is not something that is realistically going to happen.

Yep. Absolutely.

Reply on news.ycombinator.com