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

by aparadja • 15 years ago

227 117 15 years ago

aparadja7• 15 years ago

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.

themouth2• 15 years ago

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

aparadja7• 15 years ago

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

TheEskimo• 15 years ago

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.

MrEnigma• 15 years ago

A simple salt would fix the issue with it finding on google (unless your salt is incredibly common).

aparadja7• 15 years ago

Yep. I find it fascinating why plain unsalted md5 hashes are as common as they are. Developers go through the trouble of hashing, but don't go the single necessary step further.

Torn• 15 years ago

Salted md5 is still surely laughably weak in an age of GPU cracking?

bad_user7• 15 years ago

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 call. Therefore, if a hashing method is popular enough and developers don't salt their hashes, then hashes for common passwords will inevitably end up on Google. However, if you salt your hash calls with your own key, the hashes produced will be different from everybody else's.

carbocation2• 15 years ago

If using your own salt is all you do, you'd still be susceptible to easy statistical attacks once someone compromises your database. But, yes, they probably wouldn't be available on google.

seabee• 15 years ago

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.

asharp4• 15 years ago

I don't believe you understand what the salt is for.

You use a salt so that time/space tradeoff attacks are no longer viable. All you need to do is provide a few bits (say 20) of entropy to make them infeasable.

bdhe• 15 years ago

Think of (3) as saying without salting, with Google and the internet, the precomputed tables that are used for brute-force attacks are already out there and can be queried with a simple Ruby program.

skeptical• 15 years ago

Why ruby in particular?

aparadja7• 15 years ago

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.

TillE• 15 years ago

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

tptacek7• 15 years ago

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.

mcritz• 15 years ago

I dub this “shameware” and declare it awesome.

spacehaven• 15 years ago

Note to self: poison search results for md5 hashes of my passwords.

feral• 15 years ago

Because that way, anyone sniffing or monitoring your traffic doesn't even need to crack the systems to steal the hash, and so you'll be saving everyone some time?

Edit: I'm trying to illustrate the general principle, that you shouldn't take any action thats visible outside your secure perimeter, that depends on knowledge of your password.

What you define as 'outside the perimeter' depends. In the case of your corporate systems, its probably everything outside the corporate network. In the case of your gmail password, its everything outside of [your computer, the SSL connection to google's auth servers, and those servers].

You shouldn't ever leak any information outside that perimeter, that reveals knowledge of your password.

Its generally pretty hard to steal the password hash; if you start revealing what your password hash is to someone doing passive analysis, you compromise a lot.

If its worth thinking about poisoning hashes to protect, then don't try and poison the hashes!

watty• 15 years ago

If someone is sniffing his traffic he has much bigger things to worry about...

icebraining2• 15 years ago

Poison over TOR?

Cushman• 15 years ago

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?

jeffreymcmanus• 15 years ago

This kind of work is one way we let people know.

aparadja7• 15 years ago

Wasn't MtGox, the Bitcoin exchange that was hacked a while ago, using md5?

maratd2• 15 years ago

> Anyone reading this uses md5?

I use MD5 all the time, just not for security.

throwaway644• 15 years ago

Ultimately, data integrity is the same thing as data security. If you cannot trust your data not be detectably corrupt in the face of a malicious collision attack, you do not have data integrity. Collided data can be used to cause a DoS, to overrun buffers, any number of nasty things that arbitrary user data can cause when trusted implicitly.

viraptor• 15 years ago

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.

city41• 15 years ago

Your post feels rather optimistic to me. Not only do a lot of people still use md5, I'd argue a sizable number of sites still store passwords in plain text.

nateberkopec• 15 years ago

37signals used to store passwords in plaintext.

http://blog.jgc.org/2009/05/can-you-trust-37signals-with-you...

Natsu• 15 years ago

Take a look at the PHP code in this question and weep:

http://stackoverflow.com/questions/1581610/how-can-i-store-m...

I think we need more code examples of how to do things right, because that code is very, very wrong.

16s2• 15 years ago

Microsoft Active Directory Server systems use MD4 in their central distributed credential database (ntds.dit). Yes, that's a 4, not a 5... MD4. This is the strongest storage hash that one can use in Active Directory.

Shock and horror when geeks meet the real-world. Yes, I know.

phzbOx2• 15 years ago

To the other posts saying how MD5 is not bad and/or it's stupid to use MD5 without salt (or whatever):

See this script more as a fun little hack rather than a "Formal proof". Thanks aparadja for sharing. That being said, using MD5 without salt is asking for trouble. I mean, I know security is usually just a time vs $ vs quality problem, but it costs almost nothing more to add a salt in front of the password. Why not do it?

tptacek7• 15 years ago

Using MD5 with a salt is asking for trouble.

Using SHA256 with a salt is asking for trouble.

Use bcrypt, scrypt, or PBKDF2. Do not DIY your password hash.

peterwwillis2• 15 years ago

A question on the practicality of expensive compute time for password hashes:

If somebody got read-level access to your password hashes, it follows (based purely on the assumption that any app with the rights to read the hash will probably have the right to change it when applicable) that one could simply overwrite the password hash with a new one that is already known, gain unauthorized access, and change the hash back to prevent the user from finding out. Unless you really need that password to crack multiple accounts that might be reusing it, it seems unnecessary. (And honestly I wouldn't care to implement these special password hashes just to protect extraneous accounts of my customers which I don't control)

edit I should clarify that while I agree that expensive compute time for password hashes helps prevent the ultimate compromise of a user's password, I find it a much more worrisome prospect that somebody got access to the database in the first place. To me, a person's password strength is almost irrelevant compared to the importance of preventing brute-force attacks on a login API or ensuring the integrity of the password database and db apps.

That being said, for those wishing to implement a bcrypt-type hash:

  perl -le'print crypt("something", "\$2a\$random")'

should give you blowfish-encrypted password hashes on systems with it patched into glibc. ("6" instead of "2a" for SHA-512)

jeltz• 15 years ago

PostgreSQL does this right by supporting adaptive Blowfish hashing in their pg_crypto extension[1]. I checked to make sure since we do use pg_crypto.

1. http://www.postgresql.org/docs/current/static/pgcrypto.html

phzbOx2• 15 years ago

Thanks for the enlightenment. I have to agree that once you have access to the db, salt or not doesn't really matter security wise. But at the end, it really boils down to: Do you have a strong password? If yes, even md5 is "somewhat" safe. But to be fair, I don't know how big the rainbow tables are.. and could become.

For instance, I've got lots of password with over 20 characters mixed with upper/lower cases with a few symbols in it. (i.e. Seems hard but: phzb0xis@mynickname.on.hackernews.com is already pretty long and hard to crack but still easy for me to type/remember), btw that is not my password ;) I wonder if I encrypt that with MD5.. Could it be contained in a rainbow table somewhere?

Your search - 822d6c6e12b26dd30161967354aa4302 - did not match any documents.

gaving• 15 years ago

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

misterbwong• 15 years ago

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

sdkmvx2• 15 years ago

I see that link referenced a lot and don't think that's a good thing. He's right, but he doesn't explain why we should use bcrypt (or any other adaptive password hashing function). Picking bcrypt without knowing why is just as bad as picking MD5 without knowing why.

mentat• 15 years ago

No, it's really not, as long as you follow current guidance on counts for iteration. There are people smarter than <x> random person and sometimes (often with crypto) it's better to follow their advice. Anyone can make a system that they themselves cannot break. Don't be that person.

rsiqueira• 15 years ago

This is the HN discussion and comments about this article (How To Safely Store A Password): http://news.ycombinator.com/item?id=2004833

snorkel• 15 years ago

You need an app for this?

icebraining2• 15 years ago

An app proves automated cracking is possible. Doing it manually is often unfeasible, therefore many don't worry about such security issues.

tomelders• 15 years ago

Tried it with a bunch of passwords that I know my friends use (yes, they treat me like tech support) and it failed miserably with all of them.

It did however get a password that I use regularly (though not anymore) which I though was pretty complex.

So, friends with "idiot" passwords 1. Their so called computer-expert mate (me) 0.

I'm not so smug anymore.

pavel_lishin• 15 years ago

I've used Google before at work.

We inherited a system, without inheriting the administrator passwords, that we had to work on. It was a spaghetti mess, so creating a new account didn't seem obvious, and I wasn't sure how the passwords were hashed, but they did seem md5-like to me, so I googled one.

Turns out, 90% of them, including most of the admin passwords, were just four numeric characters, like 9678.

georgefox• 15 years ago

    wordlist = response.split(/\s+/)

Thank God I use spaces liberally in my passwords.

chimeracoder• 15 years ago

Unfortunately, the same sites that are naive enough to use MD5 for cryptographic hashing are also likely the same sites naive enough to use oversimplified regexes that fail to validate all possible inputs.

(If I had a dollar for every time the 'emailaddress+foo@gmail.com' failed to validate....)

drivebyacct2• 15 years ago

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

elisee• 15 years ago

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

storborg2• 15 years ago

Whenever one of these posts comes up it seems like there's a lot of comments rushing to defend salted MD5 or SHA1.

What's actually wrong with bcrypt that prevents people from using it? Is it not available on all platforms? Too computationally expensive?

burgerbrain2• 15 years ago

When people rush in to defend salted MD5/etc, they aren't actually doing it because they objectively think it's ok. They're doing it because presumably at some point in the past they have done it or allowed it to be done, they're just defending themselves. Unfortunate, since this is meant to be constructive criticism.

brunnsbe• 15 years ago

I would use bcrypt but it's not available as a encryption option for the realms in Apache Tomcat. One possibility would be to write an own realm but it's not that easy. Plus additional work is needed to update existing hashes, currently I therefore use salted MD5-hashes.

16s2• 15 years ago

Integrate your email systems with Google mail or MS mail. You'll quickly find that they do not accept bcrypt. Plain md5 or plain sha1 is all they support (at least that was the case two years ago). When you are forced to inter-operate with the big guys, you'll find not many actual use bcrypt.

storborg2• 15 years ago

If you need to authenticate from another party's hashes, why not run bcrypt on those?

teflonhook• 15 years ago

There's a bunch of MD5 search engines with rainbow tables etc. plugged in, it could tap into that easily as well.

bluehex• 15 years ago

I think this is exactly why this method is so effective. Google's index all of those sites.

The first result when I searched the hash for superman (84d961568a65073a3bcf0eb216b2a576) was a link to a page titled literally "Google Hash: md5(superman) = 84d961568a65073a3bcf0eb216b2a576", the page is hosted at(http://www.nth-dimension.org.uk/utils/ghash.php), basically someone's gone through the trouble of making a rainbow table that's easily crawlable that makes this method of lookup via Google even easier.

The page has a description:

  > Google Hash is a PoC implementation of an hash search engine using Google.  
  > Unlike other implementations, the aim here is to get Google to store the  
  > word and associated hash. We do this by putting them into the title where it  
  > will always be stored by Google's spider....

The next top hit is md5rainbow.com etc. etc. I would guess that most of the positive results from BozoCrack.rb are thanks these sites.

zaken• 15 years ago

I don't understand. This is pretty much the definition of a dictionary attack. The dictionary is just stored and accessed through Google rather than packaged with the program.

alpb• 15 years ago

Great. I think `bcrypt` is another way of hashing passwords. Read this: How to safely store a password http://codahale.com/how-to-safely-store-a-password/

crtv• 15 years ago

#1 rule - don't use unsalted md5. I think md5(md5($pass) + $seperator + $pass) works great.

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

Related Stories