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

One way to fix your rubbish password database

blog.jgc.org

Post reply on HN
Print view View original

81–90 of 94 posts

Re: One way to fix your rubbish password database

#81

Post by pbhjpbhj »

rb2k_ wrote: post #65

Even if you run a bad codebase that just uses unsalted MD5 and you don't want to add a new crypto algorithm: Couldn't you just run your whole database through X more rounds of MD5 and do the same in your authentication function? That way, script kiddies couldn't use precomputed rainbow tables they downloaded somewhere off Bittorrent. Each additional round will also reduce the speed of a brute force attack while still…

One would just check against a top10[000…] list of passwords on which various multiple hash combinations had been applied md5(md5(md5(md5('password')))) is going to be easy to reveal.

Your system would seem to be practical if you know there are no weak passwords or if you dont care if only some of the accounts are compromised.

You've also got to watch you don't DoS yourself.

Re: One way to fix your rubbish password database

#82

Post by pbhjpbhj »

tptacek wrote: post #57
lukeschlather wrote: post #42

Earlier quoted context omitted.

An MD5 hash is not a random number; it is generated from some text string. It's possible that bcrypt(salt + MD5(text)) opens you up to collision attacks that are not possible with bcrypt(salt + text). It seems unlikely that it would open you up to attacks that are not possible with md5(text) but MD5 is not a random number so I'm not too sure.

Can you cite a single example Of a pair of password-length strings that could be entered on a standard keyboard that collide in MD5? Cryptographic pseudorandom number generators also collide and produce cycles. MD5 hashes of arbitrary ASCII strings are reasonably modeled as random numbers, and the concern you cite is unmeaningful.

That seems like a big ask, these are the closest I could find - http://www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html.

An upper limit on string length suddenly makes some sense.

Re: One way to fix your rubbish password database

#83

Post by IgorPartola »

yathern wrote: post #80
IgorPartola wrote: post #79

Earlier quoted context omitted.

Brute force is sometimes all you need. The problem is that using GPU's you can compute so many hashes a second that a short password simply cannot withstand such an attack for long. The salt helps a bit, but if someone is brute-forcing the hashes all it means is that once they have your password they don't have the other person's who happens to use the same one.

I see, but isn't brute-forcing "aecd8c83718c381cpassworda3802..." going to take far, far longer? Even on some huge botnet clusters, I still don't imagine how it could be possible to crack that very quickly.

Oh, of course. But it will still take less time than you think. After trying a common dictionary the attacker just starts brute-forcing every single combination and since md5 is so quick and works so well on the GPU that it may take mere hours to find the answer. I've personally had what I considered a secure password cracked out of a sha1 + salt setup. Now I use LastPass and generate random different 32 character passwords for every service I use. LinkedIn leak does not affect me: 32 chars is enough to give me a day or two to change my password and none of my other accounts are compromised even if the attacker gets my LinkedIn password.

Re: One way to fix your rubbish password database

#84

Post by yathern »

IgorPartola wrote: post #83
yathern wrote: post #80

Earlier quoted context omitted.

I see, but isn't brute-forcing "aecd8c83718c381cpassworda3802..." going to take far, far longer? Even on some huge botnet clusters, I still don't imagine how it could be possible to crack that very quickly.

Oh, of course. But it will still take less time than you think. After trying a common dictionary the attacker just starts brute-forcing every single combination and since md5 is so quick and works so well on the GPU that it may take mere hours to find the answer. I've personally had what I considered a secure password cracked out of a sha1 + salt setup. Now I use LastPass and generate random different 32 character pa…

Okay, thanks for the answer. I was under the impression that brute forcing takes a long time.

Re: One way to fix your rubbish password database

#85

Post by Yeroc »

RyanMcGreal wrote: post #46
healsdata wrote: post #3

Is there a security disadvantage to taking the MD5 hashes you already have and running those through bcrypt? It seems like that would let you get to a salted bcrypt implementation in one day as opposed to waiting for all your users to log in. Perhaps you could do the mix (md5 + bcrypt) until the user logs in and then switch them solely to bcrypt?

Thanks to reading lots of articles on HN about password security, I upgraded my site's passwords from salted MD4 to bcrypt about a year and a half ago (a bit late to the party, but still). Here's what I did: I added a second password column to the users table, then ran a script that queried the table for the existing hash, generated a bcrypt hash from that value and wrote it into the new password column. Then I remov…

Unless I missed something you're describing exactly what the linked article suggested to do.

Re: One way to fix your rubbish password database

#86

Post by cheatercheater »

tptacek wrote: post #7
healsdata wrote: post #3

Is there a security disadvantage to taking the MD5 hashes you already have and running those through bcrypt? It seems like that would let you get to a salted bcrypt implementation in one day as opposed to waiting for all your users to log in. Perhaps you could do the mix (md5 + bcrypt) until the user logs in and then switch them solely to bcrypt?

No. I don't believe there's any disadvantage to this. An MD5 hash is a 128 bit random number; it's 16 fully random characters, better than almost any human password.

Red light coming up in the back of my head. Wouldn't the MD5->scrypt pipeline expose new attacks that scrypt doesn't have? Maybe there's a higher collision probability or some known-text attack, but I'm really shooting in the dark here.

Re: One way to fix your rubbish password database

#88

Post by tptacek »

pbhjpbhj wrote: post #82
tptacek wrote: post #57

Earlier quoted context omitted.

Can you cite a single example Of a pair of password-length strings that could be entered on a standard keyboard that collide in MD5? Cryptographic pseudorandom number generators also collide and produce cycles. MD5 hashes of arbitrary ASCII strings are reasonably modeled as random numbers, and the concern you cite is unmeaningful.

That seems like a big ask, these are the closest I could find - http://www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html . An upper limit on string length suddenly makes some sense.

Huh? Because some unsuspecting user might choose a password so long and so random that it turns out to be collidable with one other string?

Re: One way to fix your rubbish password database

#89

Post by tptacek »

cheatercheater wrote: post #86
tptacek wrote: post #7

Earlier quoted context omitted.

No. I don't believe there's any disadvantage to this. An MD5 hash is a 128 bit random number; it's 16 fully random characters, better than almost any human password.

Red light coming up in the back of my head. Wouldn't the MD5->scrypt pipeline expose new attacks that scrypt doesn't have? Maybe there's a higher collision probability or some known-text attack, but I'm really shooting in the dark here.

No.

Re: One way to fix your rubbish password database

#90

Post by pbhjpbhj »

tptacek wrote: post #88
pbhjpbhj wrote: post #82

Earlier quoted context omitted.

That seems like a big ask, these are the closest I could find - http://www2.mat.dtu.dk/people/S.Thomsen/wangmd5/samples.html . An upper limit on string length suddenly makes some sense.

Huh? Because some unsuspecting user might choose a password so long and so random that it turns out to be collidable with one other string?

I did say "some" sense. I was thinking choosing a string to collide and enter an account without it being apparent that you entered the account with anything other than the correct password. Alright the chances of someone wanting to do that seem slim but I can see someone saying in a meeting "if we leave the passphrase open at the max length side then people could enter a string with a matching hash".
Post reply on HN