One way to fix your rubbish password database
blog.jgc.org
One way to fix your rubbish password database
1–10 of 94 posts
Re: One way to fix your rubbish password database
#2On 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 forget it ever existed."
Re: One way to fix your rubbish password database
#3Is 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?
Re: One way to fix your rubbish password database
#4On 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.
Re: One way to fix your rubbish password database
#5Did you get that from here?: http://news.ycombinator.com/item?id=4078751
Re: One way to fix your rubbish password database
#6Is 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.
Re: One way to fix your rubbish password database
#7Is 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.
Re: One way to fix your rubbish password database
#8Did you get that from here?: http://news.ycombinator.com/item?id=4078751
No, I asked a question yesterday about this (http://news.ycombinator.com/item?id=4080823) and spent a long time thinking about it. Great minds...
Re: One way to fix your rubbish password database
#9Did you get that from here?: http://news.ycombinator.com/item?id=4078751
No, I asked a question yesterday about this ( http://news.ycombinator.com/item?id=4080823 ) and spent a long time thinking about it. Great minds...
Yeah, I guess it's not that amazing a coincidence... Most people would arrive at that.
Re: One way to fix your rubbish password database
#10Earlier quoted context omitted.
No, I asked a question yesterday about this ( http://news.ycombinator.com/item?id=4080823 ) and spent a long time thinking about it. Great minds...
Yeah, I guess it's not that amazing a coincidence... Most people would arrive at that.
A more fun instance of this sort of thing on HN is when I suggested that HN might be attackable because of a flaw in random number generation and then someone else who hadn't seen my suggestion went ahead and did it.
Me mentioning it: http://news.ycombinator.com/item?id=596126
The attack: http://news.ycombinator.com/item?id=639976