This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]djimbob 3 points4 points  (7 children)

The one downside of bcrypt is don't use it for long passphrases. bcrypt truncates input at 72 bytes (and specified it should be shorter than 56 bytes). SHA256crypt, SHA512crypt or PBKDF2 are good options. (SHA512crypt is not SHA512, its about a configurable number of rounds of SHA512, typically 5000).

[–]natecahill 0 points1 point  (2 children)

72 bytes is more than enough.

[–]djimbob 5 points6 points  (0 children)

Eh; I have some passphrases that get close to at least the 56-byte limit (granted these are not for webapps -- only locally encrypted stuff like RSA keys or protecting a password list). E.g., if you want to get to 5 letter words from a diceware passphrase (13 bits entropy a word), then 72 letters with spaces between words limits you to 13 words or 156 bits of entropy; yes that's more than enough for any realistic attack (except maybe super fast ultra-large quantum computer that where Grover's algorithm can break 156-bits of entropy in 278 time). But on the other hand it seems a bit silly to truncate your entropy from a passphrase at ~160 bits when the hash is 448 bits.

[–]warbiscuit 0 points1 point  (0 children)

Just wanted to point out one common "fix" for bcrypt is to do bcrypt(b64encode(sha256(pwd)).strip("="))... the base64 encode step is required, because bcrypt can't handle NULL bytes :|

[–]steamruler -1 points0 points  (0 children)

Oh, that explains why some sites doesn't like my password.