LinkedIn faces class action suit over password leak

LinkedIn is facing a class action suit over the security breach that saw millions of users' passwords posted online. Illinois resident Katie Szpyrka leads the complaint, which alleges that LinkedIn failed to "properly safeguard its users' personally identifiable information". The complaint filed in California accuses the …

[Charlie Clark]

Definitions

Salting adds extra arbitrary data to a password when it is hashed

Not quite. Any system will use the same salt, or system, for all passwords. So salting is only as safe as the salt and the security is that rainbow tables generated for one site will not work with others.

[Anonymous Coward]

Re: Definitions - are you sure?

Actually a decent system would use a different salt for each password, which would be randomly generated (aka arbitrary), and therefore require a different rainbow table for each password and so make life a lot more difficult for password crackers.

[Anonymous Coward]

Re: Definitions - are you sure?

But if your salt is random, how to you compare passwords when someone tries to log in?

You cant compare the hash unless you've stored the salt somewhere..... And then your back to the problem of an SQL injection attack can get the salt if your storing it...

[Paul Crawford]

Re: Definitions - are you sure?

The salt can't be "random" but could be something complex and user-specific, such as their email address (or a MD5 hash of that).

The goal is to make the required rainbow table too big so a standard table (for, say, all 8-character passwords and common longer ones) can't be used, and the time & storage to generate one big enough is unworkable for a reasonable time-scale so you are back to brute-forcing each user.

[Anonymous Coward]

Re: Definitions - are you sure?

In a decent system:

. There's a system salt which is in the code not the database. This ensures you need access to both code and db to get anywhere.

. There's a salt stored alongside _each_ password in the database. This means that an attacker performing a dictionary attack has to regenerate his entire dictionary for each password in the database.

. When I say "password" above, I mean encrypted, double salted password.

. The encryption hash used is run multiple times. If I decide it's acceptable to my users that it takes a second to check their password, that means, on a comparable system, each entry in the attacker's dictionary takes a second to build.

Remember that there's no such thing as a secure system. The aim of the security is to slow the attacker down enough for action to be taken.

[eulampios]

@AC

exactly, plus a decent system uses sha-2 hash algorithms. Trying to remember which system still uses the primitive lm hash algorithm...

[Voland's right hand]

Re: Definitions - are you sure?

"But if your salt is random..." - store your salt. This is what unix passwords do.

Open /etc/shadow and see for yourself

The password is stored as $SaltType$Salt$Hash (for GNU extensions). If there is no dollar signs you are dealing with the original 30+ year old format where the salt is the first two characters and the rest is DES crypted salt+password.

If I had to code a web app this day I would use these glibc functions (as readily available) but store the salt separately and rate limit the amount of queries to the salt. Ditto for passwords. You can do that on a database level or use an interim service which provides some form of auth token interface.

Anyone trying to dump the passwd+salt database would be flagged immediately as they will exceed the query rate limit.

For someone the size of LinkedIn not doing this shows a lack of incompetence which is not justified by their valuation :)

It is not that difficult.

[Ben Tasker]

Re: Definitions - are you sure?

You cant compare the hash unless you've stored the salt somewhere..... And then your back to the problem of an SQL injection attack can get the salt if your storing it...

Not too big an issue, they'd still have to generate rainbow tables for each user they wanted to crack. Whilst they could, feasibly, target an admin account it's not impossible that if the password is secure enough, they may never generate a matching hash.

For someone the size of LinkedIn not doing this shows a lack of incompetence which is not justified by their valuation :)

I'd say a lack of incompetence was the least of their issues ;)

[eulampios]

you store both

from the sha1pass manual:

DESCRIPTION

sha1pass creates a SHA1 password hash. In the absence of a salt value

on the command line, a random salt vector will be generated.

Say:

sha1pass aJKHl89o12\&

$4$I3XtGZJp$RS4DK30wq9qnGyutu+4UgtGUdN0$

where I3XtGZJp is a random salt

[Charlie Clark]

Re: Definitions - are you sure?

Yes, I am sure, seeing as I said "salt or system [for generating a salt]". Because it's systematic it's never arbitrary.

[eulampios]

Re: Definitions

OK, if systems uses pseudo-random salts (random numbers could also be seeded to make them less pseudo) the number precomputed combinations will simply get multiplied by the number of the salts available. It just makes both brute force and dictionary attacks considerably slower and harder (depending on the salt quality).

[Anonymous Coward]

Conflict of Interest

"Naturally, the class action suit is looking for attorney fees and damages for US members of LinkedIn."

Many of whom will be one and the same peoples?

The other article I saw on this 'hack' was -

http://www.thedailymash.co.uk/news/science-technology/linkedin-hack-an-anti-prick-hate-crime-2012060729702

Just maybe they could throw in a discrimination case, and possibly something in international law as well.

[Alyas]

No one was injured. Inconvenienced, yes. I don't use the same password anywhere else that I did on Linked-In, but I still felt it advisable to make a survey of all my accounts and update any passwords which were even remotely similar. So there went a half day of my life. I don't understand how a company with the resources commensurate with hundreds of millions of users cannot even adequately protect things like the user database. Of course the lawsuit is just an opportunistic attempt by the equivalent of ambulance chasing lawyers to milk an already victimized company for some money.

[Charlie Clark]

And your point is?

The main point of the legal case is to establish guilt, presumably of negligence.

"Injury" is a legal term and covers al manner of things including inconvenience. Whilst I agree that the case may indeed be opportunistic I do think it a perfectly reasonable use of the class action legislation so that once the legal points have been decided further individual cases are not required. I'm ambivalent as to whether I want the case to set a precedent in this. Technically, I think that LinkedIn is guilty of sloppy programming and basically negligence - a bit like a builder skimping on cement in the concrete. But I'm also aware that some of the sites I have worked on myself in the past don't have the best security. However, I suspect the case will spend most of its time worrying about how the data was obtained.

[Anonymous Coward]

So who gets the money?

Do all whatever million users linkedin has get damages? Or just selected few bothering with this lawsuit? Or just lawyers? I dont get it.

[Anonymous Coward]

Re: So who gets the money?

Beats me, but if there's money to be had from the several hours of password changes I went through to be had; count me in!

[Alyas]

Re: So who gets the money?

The article implied that only U.S. residents are included in the class action suit. Anyone wanting a share of any future compensation would have to somehow indicate their wish to be included. As a customer of a stock-trading site, I've occasionally received mass mailings from law firms, usually mandated by the court prior to paying out any damages, stating that if I owned stock X between dates Y and Z, then I could qualify for compensation and contact them to be included in the suit. Presumably the same process would be followed here, except that Linked-In members would receive an e-mail. But what could be the damages? Linked-In didn't have the worst security I've ever seen. I mean some companies have had databases accessed where the passwords were in plain text, not even hashed, and lost credit card numbers as well as other personal data. Illegal access to my Linked-In account, which was temporarily frozen until I changed my password, would only cause me minor inconvenience, as compared to access to my credit card information, which could result in me having to dispute fraudulent charges, a bigger inconvenience. However, if I followed even worse security practices than Linked-In, used the same user name and password for on-line banking, and suffered a theft of funds which the bank refused to reimburse, then whose fault is that? The crooks may have got my Linked-In password due to poor security on their part, but it is not the fault of Linked-In if I in turn practice even worse security by using the same password everywhere. I don't think a judge or jury would hold them accountable for subsequent losses I would suffer. So the damages would be limited to what I would suffer directly from access or loss thereof to my Linked-In account. Which is what? The cost of lost time due to having to change my password? My Linked-In account is free, so I cannot even claim loss of anything I'm paying for.

[Anonymous Coward]

Funny name

I've never actually spoken the name of this firm, and whenever I've seen it on reports I've read it as LINKED-LN and wondered how they could have chosen such an odd moniker. Just realised it's supposed to be 'LINKED IN'.

Sad, aren't I but then it's Friday afternoon. Oh NO. Only Thursday?...

[Anonymous Coward]

LinkedIn screwed this up massively...

don't they have any audit firm to verify that they taking proper security precautions?

[Scott L. Burson]

The CPU power available to crackers has increased to the point that salting is no longer adequate; it would not have protected these passwords from being cracked, assuming (as would have been likely) that the attacker got access to the salts as well.

These days you also need to use a so-called "bit stretching" algorithm such as PKBDF2, bcrypt, or scrypt.

But yes, LinkedIn screwed up here badly.

[Ben Tasker]

The CPU power available to crackers has increased to the point that salting is no longer adequate;

Guess it depends on how interested they are in getting at those password. But then, twas always the same it just took longer. Salting was never a panacea anyway, the intention is only to slow the buggers down.

It also makes things a lot harder for them if you use a site-wide salt and per-user salts.

Hell, there are even additional techniques you can do to help slow them down further. If they've only managed to get db level access, would they know that every vowel in the users password is automatically replaced with a hash of something else? (Not that I'm advocating security by obscurity here, but it can help as part of a solution).

Using strong passwords also helps, as a proper password is less likely to appear in the rainbow tables in the first place. So barring hash collision still wouldn't have been cracked. That would, of course, mean users realising that "drowssap" is not a good token to use.

Not that I'm saying the likes of bcrypt etc shouldn't be used, just that your assertation that you need to use them isn't entirely accurate. You should use them, but we're not yet at the point where proper salting is completely pointless (though when we do reach that point, I suspect a lot of people will continue to use only salting!)