5 ms·
It sort of does matter for bcrypt, surprisingly: http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length http://security.st
by sk5t 10y ago
It sort of does matter for bcrypt, surprisingly: http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length http://security.stackexchange.com/questions/39849/does-bcryp...
In the interests of hewing closest to cryptographic reality, I design not to allow a password longer than the algorithm can usefully use.
- Dylan16807 10y agoThat's just a bug. Truncation invalidates the 'stored properly' part of the statement.
- mannykannot 10y agoCould you expand on that? I did not think bcrypt was responsible for storing the resultant hash. The limit appears to be in calculating the hash.
- sk5t 10y agoBcrypt spits out a string, that the caller must store, somewhere. I presume the parent post means that Bcrypt "stores" in its output string a value that, for all practical purposes, varies reliably with the same salt but different plaintext.
- Dylan16807 10y agoThe original phrasing was "stored properly, (i.e. bcrypt)". That's including the hashing as part of the 'storing'. Bcrypt has a size limit, but a size limit is not the same thing as truncating. It's broken code on the front end that truncates instead of doing something like sha512.
- dlubarov 10y agoI think it's best to allow longer passwords for those who use long phrases. It's easier to remember the full phrase than a truncated version. You could show a warning that the extra chars beyond 50-55 will be ignored.
- kijin 10y agoOr you could SHA256 the original password and feed the hash to bcrypt. Remember to use the 64-byte hexadecimal hash, not the 32-byte binary because bcrypt chokes on null bytes. Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice. We really need to work on getting scrypt and argon2 into the most popular programming languages and frameworks a.s.a.p.
- bschwindHN 10y agoIs "just use scrypt" an acceptable answer then? I'm not a security expert and I don't know the advantages of one over the other.
- amenghra 10y agoYes, scrypt is a perfectly fine password hash. If you are currently using something else (say salted md5 or even just plain md5), you can migrate your passwords to scrpyt(current_hash()) without having to change everyone's password and/or wait for everyone to log in. See also this comment thread: https://news.ycombinator.com/item?id=12549110 https://news.ycombinator.com/item?id=12549110
- aaronbasssett 10y agoDon't do that. You've essentially just turned the old hashes into plain-text passwords, and how sure are you that those hashes don't exist in backups anywhere?
- StavrosK 10y agoNot if you mark the converted versions and try scrypt(oldhash()) on users authenticating with them.
- fractal618 10y agoWoah! Very good point!
- baby 10y agoThis is surprising, do you know how Argon2 behaves compared to this?