Live data from Hacker News

Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe

mobileideafactory.com

1–10 of 25 posts

Re: Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe

#3

The proposed scheme seems overly complex and I don't immediately see any advantage over explicitly invalidating all issued (randomly generated) tokens after the password has been reset.

The idea of hashing the server side token is still a good idea, just incase the db of valid tokens is ever stolen, they would be useless. But I don't really see the need of hashing the server side token+the encrypted password, since, as you said, just invalidate all tokens on password reset.

Re: Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe

#6
If the requirement is "access tokens become invalid when the password is changed," then you should simply delete (or mark as deleted) the affected access tokens from the server-side database inside the ChangePassword() function.

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.

Re: Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe

#7
post #6

If the requirement is "access tokens become invalid when the password is changed," then you should simply delete (or mark as deleted) the affected access tokens from the server-side database inside the ChangePassword() function. 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…

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 Your Account Safe

#8
post #5

Yes, I'm sure the hackers downloaded the iPad app and logged in to your account before you changed your password (as opposed to the 6 million other peoples passwords). Paranoid much?

it's reasonable to assume that, if you steal a pile of passwords and then release them to the web for cracking, people will change their passwords. given that, it's not too crazy to write some kind of script that gets (and renews, as required) a valid session key for each password you crack - it's a simple, smart way of keeping access to the system even after the expected change in password.

sarcastic comments don't make things any better.

Re: Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe

#10
It's likely that the site uses oAuth. Your login on a mobile device grants you a token that you can use to access the site. Changing your password may not revoke the token (it could).

If you logout from your mobile device and log back in it should require your new password.

Post reply on HN