Hacker Newsnew | past | comments | ask | show | jobs | submit | thatdude's commentslogin

But the words themselves follow an identifiable pattern (their spelling). As such, a 4 letter word in your password is cracked much quicker than a portion of your password being 4 characters of random info.


That only matters if, for some reason, your password is length limited. If your password must not be more than four letters long, then yes, choosing your tokens from an ascii table has the highest possible entropy. (Example: WPA2 PSKs, shitty websites.)

If your password can have arbitrary length (or arbitrary enough, about ~120 letters), you can generate a 128 bit password with dictionary words as tokens. Sure, the password will be much longer (factor ~6), but also much easier to memorize.


Thanks for reminder. Likely couldn't crack these in SHA-1 (or without substantially more effort), let alone some of the more new age hashing algorithms.

Still, it's impressive.


Unsalted SHA1 is just as easy to brute force as unsalted MD5. There is maybe a ~30% speed difference.

Now adding a salt would have made it ~2 millions time harder for these ~2 million unique passwords.


On a 2012 laptop with john 1.8:

• 24 million tries/second for unsalted MD5

• 18 million tries/second for unsalted SHA1

• 80,000 tries/second for crypt-md5 (state of the art… in 1995)

• 2400 tries/second for bcrypt (already becoming obsolete in 2012)

• And a tremendous 100 tries/second for scrypt (then state of the art)

So yeah, the ~30% performance hit roughly fits. But even md5 can be used much more intelligently than just salting, and would have been available in major programming languages.


Still scanning the MD5 key space 2^128 would take a while to brute force passwords. Of course it only takes time. But a lot of time. SHA1 is better, because it's 2^168 options. Also there's a problem, what if the data isn't in single block. Then you might find collision, but that collision might include something which can't be put in the password field, and therefore doesn't solve the problem.

MD5 for PQKDEj52vGQVKudQaBMSewJ5MMifgaVxNYK9zsRTxMzBkyvompLMtgYCYv6SNzDE is cd5480cf1ad1cf7fab3aedbc6495609d. I would love to see someone to reverse that. Even if you find the colliding hash with sorter set of input bits. It's highly likely, it won't be in the acceptable character set. Or am I getting something wrong?


> Or am I getting something wrong?

Yes, we're talking about passwords, not private keys. Virtually all passwords found in the wild have a massively lower entropy, so the amount of possible hashes doesn't really matter, only how long it takes to iterate through our much smaller password space. The longer that takes, the less attractive it is for attackers to try and brute-force people's passwords so they can try them on other services.


Unsalted MD5 is not that much worse than unsalted SHA-1 in this case. Afaik the only vulnerability MD5 has over SHA-1, fundamentally, is that MD5 has easy collision exploitation. But that doesn't matter when bruteforcing passwords.

* I'm not 100% on this, but let's be bold :) please forgive me if I'm wrong.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: