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

41–50 of 94 posts

Re: One way to fix your rubbish password database

#41

Post by bmelton »

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?

Well, I mean there's always the possibility that you'll have users that won't log in any time soon, and you don't want them to be vulnerable in the mean time, right?

If it were me doing it, I'd take the article's approach as the first whack, and then as each user logs in, validate their password (as per the article), and then also set their password to scrypt('salt', 'password') vs. scrypt('salt', md5('password')), so that they were current. Then just set a flag on the user record like "new_password=True" or something.

That gets you the stopgap without having to muck around with scrypted hashes forever. Send out a few emails to your user population with a note that you've upgraded your password strategy and that they should log in. You're still not going to get 100% coverage, but at least for whoever you don't get to log in, their passwords aren't 'in the wind', so to speak.

Edit: I'm not sure if you edited yours, or if I just read it poorly, but I think we're saying the same thing. Note, the article's strategy is basically your first scenario -- just bcrypting (or scrypting in the article) the existing md5 hash.

Re: One way to fix your rubbish password database

#42

Post by lukeschlather »

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.

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.

Re: One way to fix your rubbish password database

#43

Post by joshrice »

nateabele wrote: post #37

Okay, I must really be missing something here. If your original database contains a bunch of unsalted SHA1 (or worse, MD5) hashes, what good does securing the hashes themselves do if the means to generate the corresponding plaintext has already been released into the wild? Someone please tell me I'm missing something obvious.

It's how to fix your rubbish password storage, not LinkedIn's or the others who've been compromised. That's the difference.

Re: One way to fix your rubbish password database

#45

Post by StavrosK »

simonbrown wrote: post #29
StavrosK wrote: post #25

Earlier quoted context omitted.

What's your opinion on SuperGenPass and the like? I'm sure it would still get cracked, but I feel that it would take a lot of effort to crack the provider's hash, even if it were md5, and then less effort to crack the SuperGenPass hash, so hopefully nobody would recognise it or bother...

Not entirely on-topic but SuperGenPass and probably similar bookmarklets has a security problem: http://akibjorklund.com/2009/supergenpass-is-not-that-secure

Ah, I hadn't considered that... That's a shame...

Re: One way to fix your rubbish password database

#46

Post by RyanMcGreal »

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 removed the old password column. No need to wait for the user to log in.

When people log in today, the code takes their password, runs it through the old hash routine, runs the output through the new hash routine, and compares that to the password on file.

Re: One way to fix your rubbish password database

#47

Post by ww520 »

ernesth wrote: post #15

Isn't the fact that s/bcrypt is by design costly preventing this idea from being executed?

It's unlikely that you have more users than the enumeration of the 128-bit key space (if MD5 was used). The slowness of bcrypt prevents the brute force attack through the key space for EACH user. That's N x 2^128 for N users, whereas to upgrade, you only have to do it N times.

Re: One way to fix your rubbish password database

#48

Post by joshuahedlund »

lukeschlather wrote: post #42
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.

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.

I'm still trying to learn this stuff, but I do not understand fundamentally how bcrypt(salt + MD5(text)) could be worse than bcrypt(salt + text). What if everyone's plaintext password was already a string of characters identical to some MD5(text)? If bcrypt(salt + MD5(text)) could be bad, then doesn't that mean bcrypt(salt + text) could be bad too?

Re: One way to fix your rubbish password database

#49

Post by tedunangst »

ams6110 wrote: post #40
tedunangst wrote: post #17

Earlier quoted context omitted.

The idea is you do this before the password database is stolen. It's too late for LinkedIn, but not too late for you.

As far as you know.... but how do you know?

Know what? Maybe the attacker is logging all the passwords that are entered. Maybe they installed a passwordless backdoor. Maybe they installed spyware on all your users' machines. There's very little point discussing all the imaginary attacks which may have already happened that you don't know about, that could be anything.

Re: One way to fix your rubbish password database

#50

Post by icebraining »

StavrosK wrote: post #45
simonbrown wrote: post #29

Earlier quoted context omitted.

Not entirely on-topic but SuperGenPass and probably similar bookmarklets has a security problem: http://akibjorklund.com/2009/supergenpass-is-not-that-secure

Ah, I hadn't considered that... That's a shame...

Just wanted to point out that any implementation as a browser extension (as opposed to bookmarklet) is safe from DOM manipulation; searching on Google for "supergenpass extension" returns results for at least Chrome, Firefox and Opera.
Post reply on HN