Live data from Hacker News

I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

github.com

41–50 of 126 posts

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#41
post #20

Earlier quoted context omitted.

Perhaps I should have written it as "unsalted MD5" instead of "plain MD5" to avoid confusion. Unsalted MD5, in my opinion, is horrible. MD5 plays it's part in the mess: it's quick to calculate, which means that anybody can churn out huge lookup databases. Missing salts make those databases universally usable.

> huge lookup databases "Huge" being the key word here. Try searching for the md5sums of arbitrary 8-character alphanumeric passwords. You won't find many results. 62^8 is a big number.

I believe that with GPUs it's now faster to calculate possible MD5s on-the-fly than use rainbow tables.

Hence the current advice is to use "alongpassphraseasyourpassword" rather than "L33$Pa55wd"

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#42
post #7

I don't think it's demonstrating anything other than: 1) many developers don't use salts / HMAC 2) MD5 is popular 3) hashed passwords end up on Google From these 3 points I don't think it follows that MD5 is horrible. Any hashing function would have the same issues, simply because a hashing function is a mathematical function, so for any X from the domain of definition, H(X) will always have the same value, on every…

Perhaps I should have written it as "unsalted MD5" instead of "plain MD5" to avoid confusion. Unsalted MD5, in my opinion, is horrible. MD5 plays it's part in the mess: it's quick to calculate, which means that anybody can churn out huge lookup databases. Missing salts make those databases universally usable.

The salt does not matter. Neither does the specific hash; you'd be just as boned using SHA256. All cryptographic hash functions are designed to be fast.

The vulnerability is "not using a password hash construction", of which the best known are bcrypt and PBKDF2.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#43
post #10

Earlier quoted context omitted.

If using MD5 is all you do, you'd still be susceptible to brute force attacks . MD5 is a really fast hash to compute, salting or not. The solution is to pick a better algorithm and learn how to use it securely. That probably won't happen unless all the ridiculous PHP 'security' tutorials are erased from the history of the internet and only correct methods are shown.

If using MD5 is all you do, you'd still be susceptible to brute force attacks. Only if you know the algorithm and salt used (i.e. your source code is also compromised, not just your database). Otherwise, demonstrate to me how you can find the passwords that relate to these hashes (all of them use the same salt): 23C206503ABD36FCB575FC8F12791CF0 D82BDB4160F60B657D6F994B553D2E63 0DA0572E042F822F91772F14269548E6 CB8BF6C…

You ommited this:

  > MD5 is a really fast hash to compute, salting or not.
Just spend some time thinking about this.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#44
post #27

Obligatory http://codahale.com/how-to-safely-store-a-password/ link which taught me a ton.

Thank you. This article is quick and easy to digest and understand.

There's always a lot of whining and complaining about how {crappyhash} algorithm is bad and how salts don't matter but not a lot a of {dothisinstead}.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#45

Earlier quoted context omitted.

"It usually does" isn't quite accurate here. Common or weak plaintexts might work, but for the vast majority of input you're SOL. Sure "nicetry" comes back, but "nicetry99" produces 0 results and for every "nicetry" there are an infinite number of "nicetry"+i hashes.

In my experience, it is accurate. Google doesn't know "nicetry99", but it does know "octopus99", "octopus98", "octopus97", "hacker99", "hacker98", "hacker97" etc.

Anecdotal evidence might as well be no evidence. I'm not saying that you don't have a unique or clever idea, but it should be judged on its merits. This tool will be great for finding common passwords and variants where a system uses unsalted MD5 hashes; but it relies on known hashes, so for the vast majority of possible input strings that have no reason to be generated or indexed by Google it's ineffective.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#46
post #22

Seriously? Who is still using md5? There are strong hashing libraries for like every language. Anyone reading this uses md5? Can we find these people and just let them know?

Majority of voip connections and some simple http authentication for example: http://en.wikipedia.org/wiki/Digest_access_authentication

That means they're both md5-hashed on the wire and in the database.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#47

The exact same thing could occur if another (unsalted) hash becomes as popular?

Yes, as long as it's designed for speed, it's not a good fit for storing passwords. That's why people should use bcrypt or an equivalent. It has both built-in support for salting & a work factor.

(Source: http://codahale.com/how-to-safely-store-a-password/)

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#48

Earlier quoted context omitted.

If using MD5 is all you do, you'd still be susceptible to brute force attacks. Only if you know the algorithm and salt used (i.e. your source code is also compromised, not just your database). Otherwise, demonstrate to me how you can find the passwords that relate to these hashes (all of them use the same salt): 23C206503ABD36FCB575FC8F12791CF0 D82BDB4160F60B657D6F994B553D2E63 0DA0572E042F822F91772F14269548E6 CB8BF6C…

You ommited this: > MD5 is a really fast hash to compute, salting or not. Just spend some time thinking about this.

Yes MD5 is fast to compute and ... NO, in the example I've given it really does not matter much.

As I said, it should be easy cracking those hashes right? Prove me wrong.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#49
post #10

Earlier quoted context omitted.

If using MD5 is all you do, you'd still be susceptible to brute force attacks . MD5 is a really fast hash to compute, salting or not. The solution is to pick a better algorithm and learn how to use it securely. That probably won't happen unless all the ridiculous PHP 'security' tutorials are erased from the history of the internet and only correct methods are shown.

If using MD5 is all you do, you'd still be susceptible to brute force attacks. Only if you know the algorithm and salt used (i.e. your source code is also compromised, not just your database). Otherwise, demonstrate to me how you can find the passwords that relate to these hashes (all of them use the same salt): 23C206503ABD36FCB575FC8F12791CF0 D82BDB4160F60B657D6F994B553D2E63 0DA0572E042F822F91772F14269548E6 CB8BF6C…

It's somewhat optimistic to assume that the adversary knows no passwords - even if you can't create a user, phishing one isn't that hard. That makes recovering the salt much easier.

Re: I wrote BozoCrack to show why plain MD5 is a horrible way to hash passwords.

#50
post #2

For those who don't want to read the source code, BozoCrack has a simple algorithm. It googles the MD5 hash and hopes the first result page contains the plaintext password. It usually does.

"It usually does" isn't quite accurate here. Common or weak plaintexts might work, but for the vast majority of input you're SOL. Sure "nicetry" comes back, but "nicetry99" produces 0 results and for every "nicetry" there are an infinite number of "nicetry"+i hashes.

Ah, you are technically incorrect in saying there are an infinite number of "nicetry"+i hashes. There are an infinite number of "nicetry"+i passwords, but eventually there will be collisions as the hash set stays a constant size and the password set grows without bound. "Infinite" isn't a term to throw around too lightly.
Post reply on HN