Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

51–60 of 126 posts

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

#51

Post by Confusion »

bad_user wrote: post #38
seabee wrote: 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…

Mostly, there will be a column conveniently labeled 'salt'. And in e.g. a MySQL database, you can bet the native hashing format has been used.

Ignoring that, if someone got your database, you should assume they got your code. If you care about passwords not being lost, you use bcrypt or something similar.

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

#52

Post by storborg »

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?

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

#53

Post by bad_user »

JoachimSchipper wrote: post #49
bad_user wrote: post #38

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…

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.

Well yeah, but then you're proposing a brute force against the salt and the salt can be anything of any length.

So if you're assuming a salt that can contain standard latin letters and digits and is 256 in length, that's 62^256 possible variations.

Do note that I'm not saying here that MD5_HMAC doesn't have flaws, but it definitely doesn't have the same flaws as MD5, cracking it ain't easy and I can't find a reference for an instance in which this was actually done.

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

#54

Post by Freaky »

aparadja wrote: post #25
TillE wrote: post #20

Earlier quoted context omitted.

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

Covering the whole solution space would be an enormous (as compared to just huge) undertaking. But if you limit yourself to the types of passwords people usually use, you can prune it down quite a bit. The currently available databases are surprisingly large, even if not in the scale of 62^8. Consider a random pick from decrypt.fr: "phytostrote972". It's far from a random string, but not exactly a trivial one either.

> Covering the whole solution space would be an enormous (as compared to just huge) undertaking

A HD 5870 can churn through MD5s at about 2.8 billion/sec - 62^8 inside 24 hours on a single unremarkable GPU.

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

#55

Post by ohyes »

JoachimSchipper wrote: post #49
bad_user wrote: post #38

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…

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.

except you shouldn't have 'the' salt, you should have 'a' salt for each user...

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

#56

Post by peterwwillis »

tptacek wrote: post #28
phzbOx wrote: post #23

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…

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.

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)

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

#57

Post by JoachimSchipper »

ohyes wrote: post #55
JoachimSchipper wrote: post #49

Earlier quoted context omitted.

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.

except you shouldn't have 'the' salt, you should have 'a' salt for each user...

The parent to my post specified "all use the same salt".

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

#58

Post by JoachimSchipper »

bad_user wrote: post #53
JoachimSchipper wrote: post #49

Earlier quoted context omitted.

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.

Well yeah, but then you're proposing a brute force against the salt and the salt can be anything of any length. So if you're assuming a salt that can contain standard latin letters and digits and is 256 in length, that's 62^256 possible variations. Do note that I'm not saying here that MD5_HMAC doesn't have flaws, but it definitely doesn't have the same flaws as MD5, cracking it ain't easy and I can't find a referenc…

Where did the HMAC come from? I thought we were discussing plain MD5.

And yes, a huge secret salt will help. Of course, if your source code is ever visible to anyone you'll have to lock all accounts.

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

#59

Post by [deleted] »

aparadja wrote: post #14
bad_user wrote: 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.

[deleted]

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

#60

Post by tptacek »

peterwwillis wrote: post #56
tptacek wrote: post #28

Earlier quoted context omitted.

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.

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 b…

Strong password hashes don't protect your users from the consequences of security flaws in your own application.

They protect the (majority of) users that re-use passwords on multiple services, and, more importantly, they protect you from the PR shitstorm of having dumps of cracked passwords posted to Pastebin after a compromise.

Post reply on HN