

Changing Your LinkedIn Password Still May Not Have Kept Your Account Safe - superjk
http://www.mobileideafactory.com/2012/06/13/why-changing-your-linkedin-password-still-may-not-have-kept-your-linkedin-account-safe-from-hackers/

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

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

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

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

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

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

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

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

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

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

~~~
tedunangst
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?

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

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

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

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

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

------
endemic
I kept my account safe by deleting it. Zzzing!

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

Not sure how that would have affected existing sessions.

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

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

------
unreal37
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?

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

