Earlier quoted context omitted.
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.
No problem, glad to have helped!
One way to fix your rubbish password database
21–30 of 94 posts
Re: One way to fix your rubbish password database
#22Is 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.
Pedantically, it's 16 random bytes. You aren't going to lose much entropy from an upper/lower/number password unless it's at least 20 characters, or even longer if it's a pass phrase.
Re: One way to fix your rubbish password database
#23Earlier 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.
To nitpick a bit, it's 16 bytes, usually represented by 32 hexadecimal numbers.
The hexadecimal is just UI; ignore it.
Re: One way to fix your rubbish password database
#24Earlier 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.
Pedantically, it's 16 random bytes. You aren't going to lose much entropy from an upper/lower/number password unless it's at least 20 characters, or even longer if it's a pass phrase.
Sorry; C programmer.
Re: One way to fix your rubbish password database
#25Is 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.
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...
Re: One way to fix your rubbish password database
#26Earlier quoted context omitted.
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
That was an absolutely amazing hack
Re: One way to fix your rubbish password database
#27Is 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?
If you were on MD5 your passwords all have at most 128-bit of entropy. A user with a password of say, 30 random bytes from [a-ZA-Z0-9] will be getting some entropy truncated in the hashing process. If you now move to say, bcrypt your hashes are 448-bits long. So you are throwing a way a lot of the keyspace by using a shorter hash function first. So yes, it's weaker, in one sense, it's just massively more difficult to attack already and you can still upgrade to pure bcrypt as users log-in in future.
Re: One way to fix your rubbish password database
#28Isn't the fact that s/bcrypt is by design costly preventing this idea from being executed?
[deleted]
Re: One way to fix your rubbish password database
#29Earlier 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.
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
Re: One way to fix your rubbish password database
#30> 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.
Theoretically, sure. But I can't think of a nice way to authorise users on something like [1]. They'd then need a computer with the radio to provide some kind of access code, I guess?
[1] http://www.robertsradio.co.uk/Products/Internet_radios/STREA...