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

51–60 of 94 posts

Re: One way to fix your rubbish password database

#51

Post by tedunangst »

donpdonp wrote: post #36
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.

What would a password bankruptcy pattern look like? One thought is to invalidate all passwords and fall back on email password recovery when a login is attempted. This leads me to an idea I've tried once - if access to the inbox is equivalent to password credentials, why not use an email to login? By this I mean the web site login is a single field - email address. The system emails a one-click-login URL to the user…

I have lots of logins tied to email addresses no longer in use. As a real world example, people sign up for services with work emails. The day they get fired, they suddenly lose access to that email and all of the email login services tied to it. Not good.

Re: One way to fix your rubbish password database

#52

Post by pbreit »

mjschultz wrote: post #31

I'll admit, I must be the only one that doesn't quite get the jump from step 4 to step 5. In step 4, we make the assumption that their API is out in the wild, in use, and sends the md5(s, p) in the request. I get that we take that value, run it through scrypt and match against our stored value to authenticate. So the database has: scrypt(s', md5(s, p)) No problem authenticating the API requests with that. Step 5 says…

I had trouble following along as well. I think the gist is, 1) immediately re-compute strong hashes for all of your existing weak hashes. 2) when someone attempts to log in, try both hash computations. 3) if you used the old weak computation, re-compute a new strong hash.

Re: One way to fix your rubbish password database

#53

Post by lmkg »

joshuahedlund wrote: post #48
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.

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?

If you compose hash functions, you get the union of possible collisions.

Let's say that "foo" and "bar" are two distinct passwords that have the same MD5 hash. Then bcrypt(md5("foo")) == bcrypt(md5("bar")), regardless of how bcrypt("foo") compares to bcrypt("bar"). By pre-hashing with MD5, you have added possible collisions that weren't there previously, and those collisions remain regardless of how many more hashes you pile on top.

Re: One way to fix your rubbish password database

#54

Post by [deleted] »

lmkg wrote: post #53
joshuahedlund wrote: post #48

Earlier quoted context omitted.

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?

If you compose hash functions, you get the union of possible collisions. Let's say that "foo" and "bar" are two distinct passwords that have the same MD5 hash. Then bcrypt(md5("foo")) == bcrypt(md5("bar")), regardless of how bcrypt("foo") compares to bcrypt("bar"). By pre-hashing with MD5, you have added possible collisions that weren't there previously, and those collisions remain regardless of how many more hashes…

[deleted]

Re: One way to fix your rubbish password database

#55

Post by chc »

lmkg wrote: post #53
joshuahedlund wrote: post #48

Earlier quoted context omitted.

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?

If you compose hash functions, you get the union of possible collisions. Let's say that "foo" and "bar" are two distinct passwords that have the same MD5 hash. Then bcrypt(md5("foo")) == bcrypt(md5("bar")), regardless of how bcrypt("foo") compares to bcrypt("bar"). By pre-hashing with MD5, you have added possible collisions that weren't there previously, and those collisions remain regardless of how many more hashes…

We're not pre-hashing with MD5. The MD5 was already there. It's the only source text we have. The proper comparison here isn't MD5+bcrypt vs. just bcrypt — it's MD5+bcrypt vs. just MD5. So any collisions that MD5 causes are immaterial — they'd be there either way.

It seems to me that the most obvious problem is that you get two chances at colliding — once with MD5 and once with bcrypt. But bcrypt is not known to be especially vulnerable to collision attacks, so this setup is probably not noticeably worse than MD5 alone. But that's just looking at probabilities — I ain't no fancy crypto expert or nothin', so there might be much more subtle vulnerabilities than the added chance of collision.

Re: One way to fix your rubbish password database

#56

Post by 16s »

tptacek wrote: post #23
pilsetnieks wrote: post #20

Earlier quoted context omitted.

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

The hexadecimal is just UI; ignore it.

Amen to that. It could be b64 encoded or whatever. Focus on the raw bytes. They are truth.

Re: One way to fix your rubbish password database

#57

Post by tptacek »

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.

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.

Re: One way to fix your rubbish password database

#58

Post by abscondment »

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 very open to correction, but won't the increased time complexity of bcrypt also mitigate this kind of attack?

Re: One way to fix your rubbish password database

#60

Post by dfc »

alexmuller wrote: post #30
gioele wrote: post #14

> 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...

Why do you write/footnote like that? Is there a geographical disparity in how to footnote?
Post reply on HN