Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: