One way to fix your rubbish password database • Hacker News Board

Re: One way to fix your rubbish password database

#11

Post by notmyname » Fri, Jun 08, 2012, 1:10 PM UTC

jgrahamc wrote: post #4

notmyname wrote: post #2

On step 3, where you say "scrypt(s'i, md5(si, password))", don't you actually need "scrypt(s'i, md5(s0, password))", where s0 is the original salt? In other words, you still need to know the original salt you were using to successfully migrate. Therefore, if you are storing the per-user salt as the first bytes in the hashed password field, then you have to be careful when you "throw away the old weak hash hi and forg…

The original salt is s_i which you do need to keep around. The new salt is s^'_i.

Ah. my mistake. I completely missed the "'" as I was reading it.

Re: One way to fix your rubbish password database

#12

Post by peteretep » Fri, Jun 08, 2012, 1:12 PM UTC

Here's a worked example of a similar technique I wrote up ages ago:

https://gist.github.com/1051238

Re: One way to fix your rubbish password database

#13

Post by jcromartie » Fri, Jun 08, 2012, 1:14 PM UTC

This is a good step, but unfortunately all of the actual passwords are still out there, so they need to be changed.

I think a better idea would be to establish an easily implemented pattern for "password bankruptcy" that companies could follow in the case of a leak.

Re: One way to fix your rubbish password database

#14

Post by gioele » Fri, Jun 08, 2012, 1:22 PM UTC

> 4. If, like last.fm, you were also allowing third-parties to authorize users...

... then you should stop doing that and you should start using OAuth, so the client application never sees your user's password.

Re: One way to fix your rubbish password database

#15

Post by ernesth » Fri, Jun 08, 2012, 1:25 PM UTC

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

Re: One way to fix your rubbish password database

#16

Post by tedunangst » Fri, Jun 08, 2012, 1:30 PM UTC

ernesth wrote: post #15

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

Assuming you use 0.01s per hash settings, you can upgrade somewhere around a million accounts per hour.

Re: One way to fix your rubbish password database

#17

Post by tedunangst » Fri, Jun 08, 2012, 1:31 PM UTC

jcromartie wrote: post #13

This is a good step, but unfortunately all of the actual passwords are still out there, so they need to be changed. I think a better idea would be to establish an easily implemented pattern for "password bankruptcy" that companies could follow in the case of a leak.

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

Re: One way to fix your rubbish password database

#18

Post by joshrice » Fri, Jun 08, 2012, 1:32 PM UTC

ernesth wrote: post #15

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

Sorta, but chances are you'll be generating way less then an attacker would need to do. More importantly, you owe it to your users to keep their passwords secure.

Re: One way to fix your rubbish password database

#19

Post by healsdata » Fri, Jun 08, 2012, 1:33 PM UTC

StavrosK wrote: post #6

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?

That's what the article says.

Thanks for pointing that out. For some reason, when I read it earlier, I missed the bullet point about the conversion process.

Re: One way to fix your rubbish password database

#20

Post by pilsetnieks » Fri, Jun 08, 2012, 1:35 PM UTC

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.

To nitpick a bit, it's 16 bytes, usually represented by 32 hexadecimal numbers.