Lessons Learned From Cracking 2M LinkedIn Passwords 198
An anonymous reader writes "Qualys researcher Francois Pesce used open source password cracker John the Ripper to try to crack SHA-1 hashes of leaked LinkedIn passwords. He ran the John the Ripper default command on a small default password dictionary of less than 4,000 words. The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords. The results? After 4 hours, approximately 900,000 passwords had been cracked. Francois then ran numerous iterations, incorporating older dictionaries to uncover less common passwords and ended up cracking a total of 2,000,000 passwords."
Do not use standard passwords (Score:5, Insightful)
Surely this is not news.
Real lesson -- make guessing expensive! (Score:4, Insightful)
The predictable whining (and obligatory xkcd rebut) will be to make passwds "stronger", because open hashes or fast guessing is acceptable provider security.
I call BS! More "blaming the victim". Any secadmin/netadmin who has hashes available or allows unthrottled passwd guessing is INCOMPETANT. Staff are paid for professional-level knowledge so users do not need to be concerned.
The work itself is very nice, MD5 hashes can be cracked quickly in massive parallel on GPU hardware. This only matters after the hashes have already been stolen.
Practical security should be more systemic -- the cost of a wrong guess is more than a nanosecond of GPU. There are at least network delays, and in many cases lockouts. The latter make random guessing too costly/slow, especially progressive systems that allow 5 wrongs immediately, 10 in an hour, 20 in a day, and lock hard (manual intervention) above that.
My father had one of the early ATM cards but had me operate the machinery. It had an 8 digit assigned PIN, but dropped quickly to 4 when it was realized the 8 were hard to remember, and swallowing the card after 3 wrong guesses was more than adequate.
Re:Value of a linkedin account (Score:5, Insightful)
It probably has little value, but the account name is an email address. Many people use the same account/pass combination for multiple sites, including perchance their paypal account. If they manage to pull a few million email/password combos from linkedin, I can guarantee you that some of those combinations will match paypal exactly.
Re:Do not use standard passwords (Score:5, Insightful)
Salting doesn't stop brute force crackers like JtR, it only stops attackers from using a rainbow table and/or discovering that two people have the same password.
The real lesson here is just because your password database is hashed (with or without salt) doesn't mean you should let just whoever download the thing.
Re:Real lesson -- make guessing expensive! (Score:4, Insightful)
What the hell are you talking about?? The problem wasn't the hashing - SHA1 is perfectly strong - it was the lack of salting, which makes attacks like this one possible. And "unthrottled passwd guessing" might be "incompetant" but preventing it doesn't do you a lick of good if you're testing against a list you downloaded.
Yeah, they screwed up. They shouldn't have allowed the password hashes to be compromised, and they should've salted the hashes so they would be essentially worthless if compromised, but that doesn't negate the value of a strong password.
Some more important questions (Score:4, Insightful)
We all know that people tend to choose weak passwords, this is not really newsworthy. Ever since the database was leaked, many people, including professionals, have performed various analyses of cracked passwords. This is fine, but I think there are more important things we need to know right now:
1) When exactly was the database leaked? It seems that it's been floating around the internet for some time before it hit the news last week.
2) What the attack vector was?
3) What security measures have been taken by LinkedIn to ensure this will not happen again?
And perhaps one more: is there a relation between LinkedIn, eHarmony and last.fm database leaks? Did the same person/group do this?
Re:Do not use standard passwords (Score:4, Insightful)
Re:Real lesson: some web devs should be out of a j (Score:2, Insightful)
Why is it the devs who get the short end of the stick in most 'xyz should be fired!' comments in this topic?
I've worked at several places (in QA) where the devs were perfectly aware that there were security weaknesses (usually a result of some small system that organically grew into some big web service - but never was designed to be a big web service) - but until something is on fire (read: bad press), management tends to not prioritize highly needed refactoring (lets not argue over what to call it) over new shiny features.
Re:Check your password (Score:4, Insightful)
As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server.
You make a fair point, but this is Slashdot, we're not supposed to be "users" here.
Re:Check your password (Score:4, Insightful)
In this case, you have all the tools to satisfy your inner skeptic: the source is right there, if you don't trust yourself to read it, it's trivial enough to examine all communication the page does. As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server. You make a fair point, but this is Slashdot, we're not supposed to be "users" here.
You also make a fair point, and I'll admit I didn't catch that and replied hastily in light of that.
There are, however, a lot of known website tricks that can get around this (e.g., collaborating iframes, etc.) as well as server-side tricks (e.g., serve a malicious page every nth visitor). A full client-side audit will prove any given instance harmless, and I suspect the site likely will pass all such tests, but I still think the encouraged trust of a one-factor authentication credential to a third-party site is in bad security taste, especially as the link propagates outside of the "expert" community to relatives and friends who will likely not have the know-how to perform such auditing.
Thank you for pointing that out!