Slashdot Mirror
Lessons Learned From Cracking 2M LinkedIn Passwords
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."
Surely this is not news.
gpg - --gen-rand 1 9 | gpg -cat > linkedin.asc
And presto, 72 bits of sweet entropy in your password which you don't even need to remember. It suffices to remember ONE password.
Need your linkedin password?
gpg linkedin.asc | xsel
(and type your one password).
Note that this way your linkedin password is never typed and never shows up on the screen.
... It is only useless if you have a criminal intent.
For those of us who do not actually want to abuse this leak, but instead learn from it, this is a great source of data!
It shows just how *****ingly clueless most people are when it comes to creating a password.
It shows how getting a bit smarter makes your password harder to crack, but still vulnerable to dictionary+statistical attacks.
It shows how 100% random is probably the way to go for anything of value.
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
Like "correct horse battery staple"?
Life is like a web application. Sometime you need cookies just to get by.
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.
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.
own up, who used the password slashdot - 0000003627a75d6c96a3d965247584a78779bc3d
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?
www.leakedin.org/
Nobody should use this site, period.
You seriously expect people to go to an arbitrary site and enter their password, knowing that the hashes have been leaked alongside account information?
In the kindest possible world this may be seen as a service, but the skeptic in everyone should hear very loud alarm bells. This site could easily log all of the passwords that are entered for "testing", use them to solve the harder-to-brute-force hashes, and deliver to the site operator the resulting account information and plaintext password!
Even if you had the best intentions posting that link, and even if the site actually is completely innocuous, one should never encourage any user to enter their password into a random third-party site. Please take it down immediately.
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.
sic transit gloria mundi
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!
because she refused to properly secure her ports to outside access.