LinkedIn password hack sueball kicked to the kerb by judge
Leaked hashes not an automatic threat of identity theft
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
A class-action lawsuit launched against LinkedIn after hackers leaked the website's user passwords has been dismissed before reaching trial.
Northern California US District Judge Edward Davila ruled that two premium-account holders had been unable to demonstrate they suffered any actual harm as a result of the 2012 hack, which resulted in the online exposure of 6.5 million password hashes.
LinkedIn failed to salt these encoded login credentials, which were created using the outdated SHA-1 algorithm. Salting hashes, for the uninitiated, thwarts attempts to recover the original passwords.
Katie Szpyrka of Illinois and Khalilah Wright of Virginia sued within days of the breach becoming public knowledge in June 2012, alleging that LinkedIn failed to stick by a promise on security outlined in its privacy policy.
The duo sought compensation for an alleged breach of contract, claiming in part that they would not have paid to upgrade to a premium account if they had known that the social network didn't offer industry-recommend security even to its paying customers.
However, Judge Davila said premium users were paying for extra networking tools and website features rather than tighter security.
Szpyrka and Wright also admitted that they had not read LinkedIn's privacy policy prior to the hack, another factor that counted against them, according to Threatpost.
The privacy policy at the time made a promise that "LinkedIn is password-protected, and sensitive data (such as credit-card information) is protected by SSL encryption" and stated that the social network audits its system for vulnerabilities. The policy also declared that "all information that you provide will be protected with industry-standard protocols and technology" which could be taken to refer to how LinkedIn itself stored and protected passwords, among other things. The policy went on to warn that security breaches were a potential problem for any online business.
Judge Davilia tossed out the case after ruling that the exposure of Wright's password didn't necessarily place her at greater risk of identity theft.
It was feared miscreants would crack the unsalted password hashes, discover the original passwords and use them to unlock accounts on other websites as too many folks reuse the same login credentials across the web for convenience.
But the breach didn't result in any financial harm or injury to Wright, according to the judge:
Wright merely alleges that her LinkedIn password was “publicly posted on the Internet on June 6, 2012”. In doing so, Wright fails to show how this amounts to a legally cognizable injury, such as, for example, identify theft or theft of her personally identifiable information.
Judge Davila's ruling can be found here [PDF]. ®
COMMENTS
Re: Unsalted hashes
Thanks for that, it means that there is now another set of accounts I have to change the password on
SSL encryption
People seem to mis-understand what level of security SSL encryption offers. You can make a web form that collects user data and have this sitting behind SSL. Let's say one of the fields on the form is your password. The SSL cert will help protect that as it's posted from the form to the server. However what happens to it once it reaches the server (e.g. in terms of storing it to a database) is a completely different matter. Just because the site uses SSL does not mean anything in relation to the encryption used when storing/processing that data beyond the initial post.
Their privacy policy said "all information that you provide will be protected with industry-standard protocols and technology". To not use a salt is arguably poor practice, but I even reckon it's not considered industry standard to do this by some devs anyway, so it's not clear cut.
As for "admitted that they had not read LinkedIn's privacy policy prior to the hack"...well that just tells you they were trying to make money from this retrospectively.
Re: Unsalted hashes
You can be pretty sure that "j67-*^%fg" will be included in the next edition of the table.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
