Hacker News Reader

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

View on HN

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?

Reply on news.ycombinator.com