10 ms·
Why should I have to choose a different, shorter password because of your implementation details? Seems like an unnecessary annoyance.
by rescripting 12y ago
Why should I have to choose a different, shorter password because of your implementation details? Seems like an unnecessary annoyance.
- deleted 12y ago[deleted]
- thirsteh 12y agoIt 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.
- just2n 12y agoI 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).
- mscarborough 12y agoYour passwords are routinely longer than 72 bytes, and this is an inconvenience?