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."
gpg (Score:5, Interesting)
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:Do not use standard passwords (Score:5, Interesting)
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 (Score:5, Interesting)
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.