
LinkedIn Legal's Response to Their 2012 Breach - deathhand
http://imgur.com/ObGgdm0
======
jaitsu
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...](http://arstechnica.com/security/2012/06/8-million-leaked-passwords-
connected-to-linkedin/)) 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...](https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html)).

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.

~~~
ProAm
> art of recruitment

What is this?

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

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

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

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

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

~~~
blowski
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.".

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

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

~~~
icebraining
How could the site know how the passwords are hashed?

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

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

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

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

~~~
icebraining
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).

------
tuna-piano
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?

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

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

~~~
sp332
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...](https://www.troyhunt.com/observations-and-thoughts-on-the-linkedin-
data-breach/)

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

------
5251841591
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...](http://gadgets.ndtv.com/social-networking/news/fbi-to-help-
linkedin-on-password-theft-228800)

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

