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."

Comments

Do not use standard passwords

[Anonymous Coward]

Surely this is not news.

Re:Do not use standard passwords

[Richard_at_work]

The problem is, even passwords that would have been considered "non-standard" 5 years ago is now easily crackable - according to GRC, a password I used 5 years ago consisting of ten characters, alpha numeric, mixed case and a symbol would take just an hour or so to crack. That was quite eye opening.

So what next?

Re:Do not use standard passwords

[Qzukk]

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:Do not use standard passwords

[Shetan]

So what next?

Two factor authentication.

Re:Do not use standard passwords

[ShanghaiBill]

Salting doesn't stop brute force crackers like JtR

Salting doesn't make brute force crackers impossible, but it makes brute force much, much less effective. If I have two million unsalted passwords, I just need to compute a hash for a dictionary word one time and then do two million string comparisons. If I have two million salted passwords, then I need to hash the dictionary word two million times. That is far, far more time consuming.

Re:Do not use standard passwords

[RenderSeven]

What an excellent opportunity! I just told everybody on my LinkedIn account what I *really* thought of them, waited an hour, and told them all my password was hacked. Good times, good times.

Re:Do not use standard passwords

[Junta]

If you have a salt in *code* (I presume a static one), I would wager it would be easy to discern. A salt is not supposed to be 'secret', it's just supposed to prevent easy identification of common passwords and a simplistic rainbow table attack.

Now if each client had a machine generated salt to append before transmit to server, that actually is servicable. Of course, the standard practice of complete obfuscation of the password through local algorithms is better.

Re:Do not use standard passwords

[hoggoth]

Yeah, me too. I told my brother that stealing my girlfriend in the 8th grade was a shitty thing to do and he should stop getting drunk in bars. Then an hour later I told him my account was hacked and that wasn't me who wrote that.

Re:Do not use standard passwords

[zzsmirkzz]

That's not really feasible. Presumably if they have access to the passwords they also have access to the salts. In the end the legitimate application requires access to both, so if they've compromised the application they can probably get both.

It seems perfectly feasible to me.

1) A part of the salt is static and hidden in application code. This means even in the DB of salts is compromised, deduction of the missing piece is still required (as well as knowledge of its existence).

2) In a example setup there are three servers, the Application/Authentication server that is accepting login requests (Server A), the Database server hosting the DB of password hashes (Server B), and the Database server hosting the DB of the password salts (Server C).

3) The servers are configured so that Server A can communicate with the outside world and servers B and C. Server B can only communicate with Server A. Server C can only communicate with Server A.

In this setup the only server than can be remotely compromised is Server A which does not have direct access to either the list of hashes or the list of salts. In order to get this information an attacker would have to take control of Server A and query both databases, one record at-a-time. The search/index key in both databases would be the username, so the attacker would also need the complete list of usernames as well.

Now, I dreamed up this scenario in about 5-10 minutes. Please explain why it's unfeasible and assume security is high priority consideration.

gpg

[Anonymous Coward]

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.

Re:gpg

[Terrasque]

http://hashapass.com/ have a bookmarklet. Not completely auto, you still need to write in a keyword for the site, but still.. Does a good job.

Did he crack any random passphrases?

[khendron]

Like "correct horse battery staple"?

Real lesson -- make guessing expensive!

[redelm]

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

[Anonymous Coward]

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.

slashdot

[rapiddescent]

own up, who used the password slashdot - 0000003627a75d6c96a3d965247584a78779bc3d

Re:Check your password

[Jahava]

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.