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

31–40 of 94 posts

Re: One way to fix your rubbish password database

#31

Post by mjschultz »

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 once the user logs in with their actual password, we update entirely to the new scheme of scrypt(s'', p) and store just that. Now the database only has:

    scrypt(s'', p)
But the API user still sends md5(s, p) to authenticate, right?

So then what happens when that same user goes back to the API-using app? It's still uses the API so it'll send the MD5(s, p) and fail since we've discarded the transitional scrypt value when they logged in via the web interface.

Is there a deprecation period that supports both types while API using apps updated to a new API for the new scheme?

Re: One way to fix your rubbish password database

#32

Post by [deleted] »

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.

[deleted]

Re: One way to fix your rubbish password database

#33

Post by jgrahamc »

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…

Should have made clear that you can't do 5 if you need 4.

Re: One way to fix your rubbish password database

#34

Post by mjschultz »

jgrahamc wrote: post #33
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…

Should have made clear that you can't do 5 if you need 4.

Ah, okay. So step 5 is the else condition from the "if" that begins step 4. At least, until the API is upgraded to the new improved edition and most/all API apps are using the new version.

Re: One way to fix your rubbish password database

#35

Post by ErrantX »

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

One time passwords (feed the radio your generated password & let it use that to negotiate authorisation/api keys).

Re: One way to fix your rubbish password database

#36

Post by donpdonp »

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 that can be re-used (possibly with a month expiration time). The user can look up the URL in their inbox when they want to login again, or use a long-lived cookie.

Re: One way to fix your rubbish password database

#37

Post by nateabele »

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.

Re: One way to fix your rubbish password database

#40

Post by ams6110 »

tedunangst wrote: post #17
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.

As far as you know.... but how do you know?
Post reply on HN