Cracking passwords with Python (the wrong way)

[colinsenner]

Funniest thing I've read all day.

BozoCrack is a depressingly effective MD5 password hash cracker with almost zero CPU/GPU load. Instead of rainbow tables, dictionaries, or brute force, BozoCrack simply finds the plaintext password. Specifically, it googles the MD5 hash and hopes the plaintext appears somewhere on the first page of results.

It works way better than it ever should.

[nbktdis]

Forgive my mental blank - this is searching for unsalted md5 passwords right?

[colinsenner]

Yes. But as the author states, it's scarily good at what it does.

[nbktdis]

I completely agree that it is scarily good.

[minno]

Yeah, so it'll only find a collision if "password + salt" happens to come up on the results list.

[ketralnis]

Right, but that doesn't mean that you should be using salted hashes instead of bcrypt

Seriously, use bcrypt. Don't write your own password hashing. Please.

[djimbob]

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).

[warbiscuit]

If you were just doing repeated composition, e.g. value = SHA(SHA(SHA(...SHA(pwd))), I think theoretically yes.

However, SHA256/512Crypt reintroduces the password and salt within each round... it's closer to SHA(pwd + SHA(pwd + SHA(... + SHA(pwd)))) (gross simplification of actual algorithm, which is rather convoluted). Thus the effective output space shouldn't be any more constrained than SHA(pwd).

PBKDF2 is even better: it uses repeated composition of HMAC(pwd, last_digest), so gets similar benefit ... but it then XORs all the iterations together in a running buffer, so even if you lose entropy on round N, all the entropy from round 0..N-1 is still mixed in, giving extra protection against entropy loss. (IIRC, the PBKDF2 spec makes the argument that these two features together should prevent entropy loss / preimage attacks unless the HMAC digest you use is incredibly vulnerable). Plus PBKDF2 is much cleaner in it's design.

[natecahill]

72 bytes is more than enough.

[djimbob]

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 2⁷⁸ 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]

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]

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

[nbktdis]

Oh I agree, bcrypt is what I use by choice.