Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe | Hacker News Reader

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

mobileideafactory.com

25 pointssuperjk24 comments

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.

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.

Yes, sha2 is more than sufficient for protecting auth tokens. If it's not, the problem is your auth tokens are too simple.

I'm fairly certain that LinkedIn has little or no regard for user privacy and security. Why do I say this? Even as early as 2007, I noticed that LinkedIn displayed 3 rotating links to people I might be 'interested' in connecting with. And among names of people I knew well, one or two names repeatedly popped up that were vaguely familiar, but they were neither friends nor friends of friends (as far as I knew). Then it dawned on me -- one of those vaguely familiar names is a person living halfway around the world whom I've never met except for the email inquiry he made to a mailing list and his followup to my response. The only way LinkedIn (or any real person) could think that we had any sort of affinity is if they read that singular email thread in my email. Yes, my email+password combo for LinkedIn was my email+password combo for my email.

So LinkedIn was snooping in my email, for which they would needed to have saved my password in plaintext (or equivalent) somewhere.

If I needed further proof, after my changing my email addr that I used to login to LinkedIn, I stopped getting those invasive people suggestions. I then googled (again, back in 2007) about LinkedIn and snooping in people's email accounts, and an interview with the CEO had a brief mention of it, where the CEO flatly denied any sort of privacy breach.

I think we need to supersede the commentary of LinkedIn's incompetent handling of security and privacy (which they spectacularly proved already) with the idea that not only do they not give a flip, but they want to keep it that way for their own maximum benefit.

It seems more likely that the person on the other end of the conversation simply did the "import gmail contacts" option, and during this process they noticed the correspondence between you and him. Then when you changed your email for linkedin that connection was broken.

Exactly. All of these "there's no way anyone could have known that" stories ignore the fact that there is another person who could have known and provided that info.

That's a good point. I'll keep that in mind.

I'm still hesitant to feel like it explains everything -- in 2007, LinkedIn still didn't seem that ubiquitous (after all, FB was then just opening itself up to non-college students, and LinkedIn's target demog. was still the pre-internet generation). So there weren't a whole lot of people I knew on the site to begin with, and there wasn't anybody I knew in common on LinkedIn connecting me to at least 2 of the vaguely familiar people I knew. And those 2 people started getting suggested to me by the site at the same time -- it seems too coincidental that these people (and others) provided their email contacts to LinkedIn at exactly the same time.

One good takeaway is, despite it taking me 5 more years to learn my lesson, and the really hard way :-(, I'm now using KeePass and creating difficult, unique passwords for each site, and using git to sync across computers. That helps.

Although that might seem like a likely explanation, LinkedIn wasn't putting the "import email contacts" widget in your face like they do, now.

Of the two people I vividly remember as only vaguely familiar suggested people, neither was in my Gmail address book. I had a 2-sent-emails thread with one person, and no direct emails with the other. In 2007, Gmail might have already been auto-collecting contact info of people you email directly, but that can't explain the 2nd person.

I don't think they were logging into email surreptitiously without you first doing a "Find My Friends" thing--that's clearly illegal. However, my guess is that they did at least the following (which is still creepy, IMHO):

- Used phone contacts from the mobile app to use as suggestions. I noticed a serious uptake on weird connection suggestions after I first installed the app a few years back. Checking it out on a proxy, I noticed that it wasn't using SSL, either, so I uninstalled that puppy quick. I assume they've fixed this between then and now.

- The "Find My Friends" from the Web and Mobile works both ways - so if someone you've emailed in the past chooses to do this, you start seeing them in your suggestions list. If I remember correctly, their original method for doing this was an actual login to email (which may be what happened to you; I don't know if there's any way to get them to clear out those suggestions once you've done it. I contacted Support about this awhile back & couldn't get an answer). What seemed weird to me about this is that all my wedding vendors popped up at the same time as suggestions...like they all got on LinkedIn at once or something.

- If you look at someone's profile or they look at yours--even anonymously, you're linked somehow for suggestions. I've seen people I haven't talked to or emailed in 15 years and three email accounts ago recommended, as well as their spouses(!). Serious privacy issues here if you spend a few minutes thinking about the possibilities. ;)

A quick tip--would bet many HN folks already know this, but I've talked to bunches of people who don't: Unless you explicitly set the "Select what others see when you view their profile," option (and keep checking it occasionally - just found mine was reset somehow), anyone whose profile you've viewed can see that you've viewed it. I love this feature (from the who's-viewed-me side, at least), but it's still creepy and something to be aware of if you're LinkedIn stalking someone...

Also, it does look like they finally added a "Security" checkbox in Settings to always browse using https - would highly recommend setting that one if you haven't already.

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.

I suspect that it is much worse than that.

The fact that the mobile app can still access LinkedIn means that there is an authentication back door that it uses. What does that back door look like? Clearly it does not care about your password.

If someone studies the mobile app and figures out how it does this authentication trick, then we'll know the damage. Is there a universal authentication where you just need to know the person's name to connect? Is there a table inside of LinkedIn that can simply grant access? (If the blackhats can get a dump of the user table, they probably can manage to insert things into other tables.) Whatever the mechanism turns out to be, it provides a way for the blackhats to bypass security and access your stuff even if they do not know your password. And the odds are depressingly high that they'll be able to do it even if they never knew your password.

I suspect that back door is a browser cookie. Tons of sites don't deauth old cookies on password change. Hacker News being one of them. Why doesn't anybody freak out over the HN backdoor?

Then capture that cookie over the wire, and voila you are in.

As mentioned in other comments in this thread, LinkedIn's tech team frequently disregards security standards.

I found a CSRF attack on LinkedIn by accident when searching in Duck Duck Go some months back. I clicked a link in my search results and was presented with a page thanking me for signing up for some LinkedIn group. I then received an email thanking me for joining the group as well.

LinkedIn was joining a group whenever an authenticated user performed a GET request to a particular URL in their browser. I followed this up by searching Google for other URLs that suffered from the same problem and found many. I wrote an exploit (very easy for that issue) and contacted LinkedIn. They have fixed the issue by now but it took more than 6 months.

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.

This seems like security/session management 101

I kinda hope/expect any password change will invalidate all client side tokens when I am using an app web based or otherwise. At the least, invalidate it when I do something that requires a rights check. ( IE adding scammer@someplace.tld as the recovery email or w/e ).

FYI, the Facebook app does this as well. I changed my Facebook password and the app still worked fine on my iPad.

I kept my account safe by deleting it. Zzzing!

Easy solution. I simply deleted my LinkedIn account. :-)

Not sure how that would have affected existing sessions.

when i changed password in google account -- all sessions, tokens and other must be reauthorized. i think this is a good practice.

Does they use oAuth/xAuth for the mobile client possibly? Seems like you could go in and deauth the mobile client, no?

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.

Reply on news.ycombinator.com