LinkedIn Legal's Response to Their 2012 Breach | Hacker News Reader

LinkedIn Legal's Response to Their 2012 Breach

imgur.com

33 pointsdeathhand28 comments

What makes this even worse is the fact that they're trying to cover up just how bad this really is. LinkedIn use(d) the sha1 hashing algorithm (see: http://arstechnica.com/security/2012/06/8-million-leaked-pas...) which is easily breakable through rainbow tables when not used with a salt (which LinkedIn failed to use).

The sha1 hash has been known to be cryptographically insecure since as early as 2007 (https://www.schneier.com/blog/archives/2005/02/cryptanalysis...).

The very fact that LinkedIn reset everyone's passwords backs this up.

After this data leak I deleted my account, not only is LinkedIn destroyed the art of recruitment it has been completely irresponsible with user's data.

Also deleted my account. Although according to them, it might take several months before my profile actually goes away "for real" and I stop getting spam emails from recruiters.

Apparently there is no nuke it from orbit option.

> art of recruitment

What is this?

Sounds like he's not happy with the impact LinkedIn has had on talent acquisition.

As if it was ever an art, or not shitty, at any point in history.

This is an interesting response, because it reveals a few things:

- Linkedin was not aware of the size of the 2012 breach.

- Linkedin did not use preventive measures one would usually do after a significant breach (They only now issued a password reset for accounts older than 2012).

It seems like they also botched the 2012 post-hack evaluation.

I wonder if their security engineer(s) could be held personally liable. Someone has advertised him/herself as a security engineer, while completely botching the password scheme (unsalted Sha-1), and leaving massive holes in the post-evaluation of the breach.

For anyone to be liable, there'd have to be a criminal or civil suit against LinkedIn, neither of which has happened or seems likely to happen. Maybe a class action lawsuit, but I don't think there's a precedent for an individual employee being held personally liable in a class action suit.

Also I really doubt there was a single employee you could place the blame on.

What irked me the most about this email was the lack of ANY sort of excuse/word of sorry.

Since it's a "legal response", my guess is it was written by a group of lawyers. Hence the robotic, minimal-engagement, no responsibility, no admission of guilt, "This is indeed a thing that happened. That is all." response.

True, but other companies have issued legal responses and still managed to include a small apology. Here's Snapchat from 2014:

> Our team continues to make improvements to the Snapchat service to prevent future attempts to abuse our API. We are sorry for any problems this issue [the security breach] may have caused you and we really appreciate your patience and support.

LinkedIn's just sounds like "sorrynotsorry. It's all somebody else's fault.".

Not to mention the way the phrased it on the initial email asking users to reset the password:

"We've recently noticed a potential risk to your LinkedIn account coming from outside LinkedIn"

Outside LinkedIn, yeah...

sites should include a "password hashing and salting" page along with their privacy statement where they outline what algo they use for storing passwords.

Rather, there should be a public website that lists the privacy measures of all websites.

Then you could have a browser extension warning you if the current site uses bad/unknown practices.

Actually this could go further, telling you as well if the current site uses advanced fingerprinting, known dark patterns etc...

How could the site know how the passwords are hashed?

Well it would need to be a crowd-sourced effort with people finding the info somewhere on the website itself or some other trustworthy source, and providing a link to it.

The idea is to have websites that don't give that info seen as "bad". This would put pressure on them to do things right and disclose it.

Unless Chrome starts including this sort of functionality by default (sort of how like it now complains about HTTP) I don't think the majority of people will notice or care.

The fact that this still happens so frequently even with libraries that make things so easy boggles my mind. Was the engineer who designed this system developing under a rock? Did not a single other person take a minute to review their code?

fwiw I don't see this kind of problem being solved with code reviews (although of course it is possible someone could have spotted a problem in a review). The proper way imho to address this kind of risk is to have someone in authority responsible for security, and that person needs to do their job which would include asking questions like "how are we hashing passwords?". Then that person should go dump the database and look for themselves since the answer supplied to the above question is often incorrect.

That said, this could have been a deliberate design decision -- when changing hash function the question arises "what about all the existing stored hashes we have?". One possible answer is "leave them as-is, we'll only compute a new hash when the user changes their password". Of course this is the wrong answer, but I've been involved with hashing transition projects at major sites where this was suggested as a serious option. Better design clearly would have been to update the hash the next time the user logs in, with an expiry/grace time of a few weeks to catch accounts that don't see the user presenting a new plaintext password (force password reset on those accounts after the grace period).

This of course would have also lowered site traffic slightly due to users never re-logging in after the password reset.

Another option is just hashing the current hash, ie., if you have sha1(pass), you can apply bcrypt and store bcrypt(sha1(pass)). Possibly add a per-user flag to indicate this was done, which can be cleared after the user logs in the next time and you can store simply bcrypt(pass).

How do hackers gain access to databases in breaches like this? I really don't understand, and I never see it written.

Is it just SQL injection?

That's a good question, and it seems to be something that's usually glossed over when we're talking about password security. I think it's anything from SQL injection to breaching live database or backup servers. That's why hashing and salting are important, because patching holes in your infrastructure is a lot easier than dealing with the nightmare of all your users' passwords being known.

Maybe an intern downloaded it onto a USB drive.

Interesting to note that this is their first communication about this issue that I could find that came from 'legalnotice@linkedin.com'. With this language they knew about the breach and didn't tell me?! It sets a scary precedent that users are only notified if the information becomes available online. I could be supporting Hillary Clinton and this could be used as a vector for attack before the data dump. 0 Day information has real value.

The breach was public, but at the time it was only known to include password hashes, without even associated email addresses, so it was not a big deal. https://www.troyhunt.com/observations-and-thoughts-on-the-li...

Define 'Public'. There was no communication from the legal team :)

What does Hillary Clinton have to do with anything?

Nothing - She is a high profile public figure and when talking about cleaning a server said 'with what a cloth or something?'. There are CEOs who run Fortune 500 companies who are just as clueless about technology. She was only referenced because lucrative targets for attacks may not use the best technical practices.

She knows exactly what happened. They ordered her server to be wiped to cover up and she is acting ignorant to try to avoid the consequences.

What amazes me the most, is that they likely new passwords were probably compromised way back in 2012, and might have suspected it was a far worse compromise, but only forced the password reset for most users now, after they leaked. "Durzy said it was not yet determined whether the email addresses that corresponded to the hacked passwords were also stolen." - http://gadgets.ndtv.com/social-networking/news/fbi-to-help-l...

Why would they think/assume only the passwords were compromised and not all of the associated email addresses?! Why did they assume only the number of leaked passwords were the number originally stolen?

The only reason why the millions upon millions of unsalted SHA1 password hashes leaked now, is likely because they stopped being useful for attackers. People working in the incident response space know: the 2012 breach quickly resulted in hundreds of follow-up breaches, some of them known, some of them not public. How? Likely from shared passwords due to the linkedin breach, also likely why linkedin was targeted in the first place... as a precursor for follow-up attacks targeting Google apps accounts and VPNs without 2FA (which leads to more passwords, and repeat.)

Reply on news.ycombinator.com