Re:Changing Your LinkedIn Password Still May Not Have Kept Y...
by LammyL on Saturday June 23, 2012 @02:03PM
(#4151387)
Hashing the access token with bcrypt isn't really a good idea. Bcrypt is designed to be slow, and hashing the submitted token on EVERY request would really affect performance. Bcrypt is great for password hashing which only happens once per session. You are probably better off securing access tokens using a fast hash (sha) and compensating for security with a long and random access token.
Re:Changing Your LinkedIn Password Still May Not Have Kept Y...
by tedunangst on Saturday June 23, 2012 @05:23PM
(#4151848)
Yes, sha2 is more than sufficient for protecting auth tokens. If it's not, the problem is your auth tokens are too simple.
Session ids are often just ephemeral access tokens, and any other sessions for the same user should also be deleted from the server's session store when the password is changed. I would keep just the one session that actually issued the change password request, as I hate it when sites log me off when I change my password, forcing me to enter the new password a 3rd time.
Since an access token trumps the password, perhaps it should be equally hard to derive an access token given the database dump as it is to derive a password. In this case, you would want to use bcrypt for hashing the access token, the same way you use bcrypt for hashing the password itself. Alternatively, make sure the keyspace for your access tokens is 'very large'. But if hackers have read access to your database, perhaps brute forcing access tokens is the least of your concerns.