Bad day for LinkedIn: not only did 6 million of their passwords get stolen and published online (as SHA1 hashes, but still), their iOS and Android applications uploaded your calendars to LinkedIn (after opting in, though). The Sensationalist Headline of the Day Award goes to Ars Technica. I guess everyone’s starting to feel the sting of The Verge’s fully deserved success.
I don’t understand this reference “I guess everyone’s starting to feel the sting of The Verge’s fully deserved success.”
I guess I don’t understand the significance of The Verge in the reference aside from them just being an Arse competitor?
Also, I wonder how “opt in” the linkedin feature is. Opt in like you have to go into a menu and enable having the data sent to Linkedin or Opt-in like “additional permissions are needed to do such and such, click yes to agree”
The Verge seems to be recognized as where the Linked In password story broke first. Everyone else is linking back to them as the source.
Regarding Opt-in calendar sharing. When my Android app updated, the next time I openned it I got screen message “do you wish to upload your calendar” or something similar. That would be the “opt-in” mentioned.
Password storage in plain text is a bad idea, but that doesn’t mean that storing password hashes in itself is a good idea. The hashes _must_ be salted, otherwise you can easily find out at least some of those, using rainbow tables or even less sofisticated techniques, like finding out who uses the password “password” or “123456”.
Salted password hashes is increasingly irrelevant these days though. The only point of rainbow tables is to save the time of calculating each hash. These days though, an off the shelf PC gpu can compute on the level of 2.3 billion SHA1 hashes per second. Doing a rainbow table for a new salt is no longer in any way prohibitive. See for example http://www.golubev.com/hashgpu.htm
Edited 2012-06-07 07:36 UTC
You’d have to have a rainbow table for each salt+hash combination, which is different per user. The problem gets exponentially harder with more users. Its a space issue.
What I am saying is that using rainbow tables today is not really necessary, since enumerating the hashes on the fly on GPU is so cheap that keeping the table is not an all that huge optimization. 2.8 billion hashes per second means that you run through 56 gigabytes worth of potential hashes per second, and that’s on a single cheaply available 5970 GPU. Storage is not an issue since you will just hash, check for a match, and then immediately discard it if unsuccessful.
Rainbow tables would of course help in that there are so many users in the LinkedIn dump, but it is still fairly easily within reach for an enterprising hacker to brute-force through a ton of them one by one. On smaller systems the salt is basically irrelevant, the GPU will go through the possibilities so fast that it is not worth the trouble to look at a table. This also means that anyone looking at a password dump can select some especially interesting user accounts and spend more resources on those, brute-forcing them more deeply than was ever practical with a rainbow table (which were always, of course, only good for short or simple passwords).
The accounts in the LinkedIn dump should be considered compromised with or without salt. Adding salt costs nothing, but it hardly makes a practical difference in the attitude you can take towards the crack.
Edited 2012-06-07 11:56 UTC
If the CPU/GPU hashing performance is sufficiently fast (due to parallelism), then your right rainbow tables might become a bottleneck instead of helping. I cannot vouch for your numbers, but if accurate then maybe we’re already at a point where rainbow tables aren’t necessary.
If one has already broken into a website though, it may be quite easy to modify the server code to capture the passwords when they are used before they are hashed at all.
“The accounts in the LinkedIn dump should be considered compromised with or without salt. Adding salt costs nothing, but it hardly makes a practical difference in the attitude you can take towards the crack.”
Ideally if an advanced attacker can go through one trillion hashes per second (using parallelism), then you could hash your password recursively so the attacker’s effective speed is rate limited to a few passwords per second. However obviously this places a rather large burden on servers just to run billions of hashes to slow the attackers down.
Edited 2012-06-07 15:23 UTC
Just echoing Sodki.
Why would a (supposedly) professional organization like LinkedIn be storing unsalted user passwords anywhere on their systems in the first place?!
Edited 2012-06-07 02:52 UTC
Incompetence? Stupidity?
Edited 2012-06-07 05:07 UTC
Last.fm possibly joining that club:
http://www.last.fm/passwordsecurity
http://www.last.fm/forum/21713/_/2054638
(and it they’re almost implying that “recent password leaks on other sites” are some sort of justification…)
This is why I’ve been saying for years that if banks, credit card companies and transaction processors have to follow PCI standards for storing your FINANCIAL information and passwords, then a subset of PCI should be implemented for ALL companies that store any kind of passwords. That way there’s some accountability, the latest Global Payments fiasco aside, overall the PCI standards are good and solid. As long as they’re properly enforced and “self auditing” (what a joke!) is removed from the standard.
seanc7,
I understand your sentiment, but please lets not look to the credit card companies as a model for security. What PCI achieves by keeping secret could be better accomplished by using cryptography.
In a true crypto commerce model, a merchant would receive a digital certificate from customers that entitles that merchant to debit our funds within the constrains listed on the certificate. Whether these are one time or reoccurring, it would simply be impossible to use the certificate elsewhere even if it were published in plain sight. This works because cryptography isn’t dependent upon the secrecy that makes credit cards so vulnerable.
I work in a financial company that must follow PCI and other standards. PCI is pain but when properly implemented and followed (key words) it’s reduces the risk of passwords being stolen. Even if they are, they’re properly encrypted.
I understand your concerns about the financial industry, the thefts from Global Payments and the others in the last few years are scary, but it’s because those companies are NOT following standards properly. Whoever did Global Payment’s audit, needs to loose their job. The auditing we’re going through for PCI v2, is an even bigger PITA, but it’s necessary.
seanc7,
“I understand your concerns about the financial industry, the thefts from Global Payments and the others in the last few years are scary, but it’s because those companies are NOT following standards properly.”
I’m not sure you are understanding the point I’m trying to make. A proper cryptographic solution takes the merchants completely out of the loop when it comes to the security of consumer bank account.
The flaw inherent in credit card security still exists in 100% PCI compliant businesses. No one within a company, no matter how trustworthy, no matter how protected the data is, no matter how secure internal encryption is, should have access to make arbitrary charges against customer accounts in the first place. PCI compliance is a bandaid on top of a fundamentally broken security model. Credit cards were a necessary evil when cryptography was impractical and networks were missing, but now we need to be looking away from that model to embrace cryptographically secure ones.
By the way there are several of us here who are more than happy to discuss the more technical side of encryption and what it has to offer if you are so interested.