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

91–100 of 126 posts

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

#91

Post by storborg »

16s wrote: post #83
storborg wrote: post #52

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?

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.

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

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

#92

Post by phzbOx »

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.

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.

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

#93

Post by bluehex »

teflonhook wrote: post #86

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

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.

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

#94

Post by pavel_lishin »

tomelders wrote: post #32

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.

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.

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

#95

Post by angelbob »

eru wrote: post #75
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…

A standard assumption in cryptography, known as Kerckhoff's principle ( http://en.wikipedia.org/wiki/Kerckhoffs%27_principle ), is: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." or "Don't rely on security by obscurity.".

In this case, the salt is effectively part of the key. They know how you use the salt, sure. Just not the big arbitrary hex string that is the salt.

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

#97

Post by sdkmvx »

mentat wrote: post #74
sdkmvx wrote: post #68

Earlier quoted context omitted.

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.

No, it's really not, as long as you follow current guidance on counts for iteration. There are people smarter than 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.

I strongly disagree. If you are the person tasked with implementing password verification, then you really should learn enough about the field to give a rough explanation of why you've used bcrypt (or whatever you use). If you know what MD5 (and other simple hashes)'s deficiency is (and Hale explains it), then you should know how bcrypt, etc. solve that problem. One should follow expert advice but not blindly.

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

#98

Post by buff-a »

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…

If I have your hashes, I probably have your salts too. (Unless you use a single salt, in which case, I can easily get your salt if I've already got a username/password for your site.)

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

#99

Post by throwaway64 »

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…

security is about defense in depth, and doing as much as is feasible to mitigate damage. Proper password hashing wont protect you from a break in on a primary system, but it could very easily prevent a break in on secondary ones.

Also, a note to anyone reading the above post, that is not how bcrypt works and is incredibly insecure.

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

#100

Post by throwaway64 »

angelbob wrote: post #95
eru wrote: post #75

Earlier quoted context omitted.

A standard assumption in cryptography, known as Kerckhoff's principle ( http://en.wikipedia.org/wiki/Kerckhoffs%27_principle ), is: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." or "Don't rely on security by obscurity.".

In this case, the salt is effectively part of the key. They know how you use the salt, sure. Just not the big arbitrary hex string that is the salt.

No it is not, because the salt is stored in a plaintext or easily reversible format somewhere, and has to be in order for authentication to work, if you are in a position to grab the hashes, it will also be trivial to grab the salts. The point of the salt is not to add some padding bits to the password. Salts should be publicly knowable without it causing a loss of security.

The one and _only_ use of a salt is to prevent precomputation attacks (rainbow tables).

Post reply on HN