Live data from Hacker News

6.5 Million LinkedIn Password Hashes Leaked

translate.google.com

521–530 of 547 posts

Re: 6.5 Million LinkedIn Password Hashes Leaked

#521
Obviously the list was filtered to eliminate duplicates. It contains only what the hackers wanted it to contain. So, why does nobody mentions that it is HIGHLY LIKELY that the user names associated with the passwords (which are actually mainly e-mail addresses for LinkedIn) are also in the possession of the hackers. So, if I would be the hacker - strip usernames, strip duplicate hashes, post list of unique hashes to let others do the CPU intensive cracking, retrieve cracked passwords, match with usernames (e-mail address), check same password on other accounts (first on the e-mail account, then google the e-mail address on forums or try on the services that interests me and say "forgot password, send it again to this e-mail address - thank you telling me that this e-mail has indeed an account with you..."), monetize somehow the data. As a user that implies - IMMEDIATELY change your password for the e-mail address used to login at LinkedIn (if it was the same password); verify if settings of this e-mail account have changed (like an additional unknown address added to allow retrieval of the password, DUH), try to remember where you use the same address either as login or to recover credentials, try to remember where you used the same password, google you e-mail address to help you remember; change passwords; consider abandoning the e-mail address if it is not your primary one,... Also - did the amount of SPAM that you receive on the e-mail address used to login at LinkedIn suddenly increased, while SPAM remained constant on a similar mail account not connected to LinkedIn ? Maybe someone just sold your e-mail address, so the LinkedIn break may affect you even if the password is not in the list. Bottom line is - LinkedIn approach appears to be: We have no proof that this particular account was hacked since password hash is not in the list - let's not overreact and let'sassume it is not hacked even if we don't have a clue what was actually hacked. I'm not to judge if it is the best approach for the business, but sure as hell I don't like this approach as a user.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#522

Whatever manager it was that tasked some junior programmer (particularly one that didn't know that unsalted SHA1 is a terrible idea) with implementing the password system at LinkedIn needs to be fired. Making the programming mistake means that you don't know much about web security, and while not a great thing, that's forgivable; putting someone that's utterly unqualified for code with security implications on such a…

"I expect this from some shady Bitcoin market that a high school kid runs off of a server in his bedroom. I do not expect this type of amateurism from a 10 billion dollar company with hundreds of engineers.."

Think you might be expecting too much from large companies =/

Re: 6.5 Million LinkedIn Password Hashes Leaked

#523
Guys, this all doesn't parse for me. My password on LinkedIn was 13 characters long, and included symbols (!@#$%^&&*()), numbers, and alphabet characters. A 13-character password like this would imply a search space of (26 + 26 + 10 + 20) ^ 13 = BIG. If a GPU can check 11 billion passwords per second, this implies that someone ran 2.4 x 10^7 GPUs for a month.

We're either looking at someone with a seriously ridiculous password cracking computer (i.e. ASIC-based -- not even FPGAs), a compromise for SHA-1 (very unlikely), or a keylogger/proxy/trojan/etc... I vote for keylogger.

If your password is in this database, I don't think it's because your password was brute-forced.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#524

Earlier quoted context omitted.

Like you can't break bcrypt... The weakest link, either in bcrypt or MD5 is the password quality. Of course, in pure MD5 today you're a google search away and modern computers can eat salted MD5 for breakfast But the easiest passwords are going to be broken first

Am not a cryptographer by any means, so please correct me if I'm wrong: If you use any reasonable cost for bcrypt, you're talking hundreds of milliseconds per attempt on a modern CPU. For each 6-character password (since you can't generate a rainbow table) at 100ms per pop, you're talking about something on the order of 2+ years per password divided by the number of CPUs. With something like 900 CPUs running continuo…

The math doesn't sound right. Google allows any ASCII character for their passwords, which is 95 chars. I calculate 2330 years to crack each password. Did I get something wrong?

(95^6 * .1sec per hash) / (60sec 60min 24hrs 365days)

The key difference is bcrypt does ~10 hash/sec. A GPU-enabled password cracking machine can do over 500 million hashes per second. That generates a rainbow table in ~30 minutes.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#525
post #220

Earlier quoted context omitted.

I'm not sure what you're implying. How have they 'closed the leak'? If you find your hash in the list, you should change your password. If you don't, you should change your password. I use LastPass to manage my passwords so I just generated another random 20+ char password and forgot about it.

The point is that LinkedIn haven't even confirmed they know how the passwords were stolen (they haven't even confirmed they were stolen, yet). In that case, when you change your password and feel all secure again, what's to say the hackers haven't just lifted your new hash as well?

That's a fair point.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#526
post #220

Earlier quoted context omitted.

I'm not sure what you're implying. How have they 'closed the leak'? If you find your hash in the list, you should change your password. If you don't, you should change your password. I use LastPass to manage my passwords so I just generated another random 20+ char password and forgot about it.

The point is that LinkedIn haven't even confirmed they know how the passwords were stolen (they haven't even confirmed they were stolen, yet). In that case, when you change your password and feel all secure again, what's to say the hackers haven't just lifted your new hash as well?

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#527
post #220

Earlier quoted context omitted.

I'm not sure what you're implying. How have they 'closed the leak'? If you find your hash in the list, you should change your password. If you don't, you should change your password. I use LastPass to manage my passwords so I just generated another random 20+ char password and forgot about it.

The point is that LinkedIn haven't even confirmed they know how the passwords were stolen (they haven't even confirmed they were stolen, yet). In that case, when you change your password and feel all secure again, what's to say the hackers haven't just lifted your new hash as well?

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#528
post #253

Earlier quoted context omitted.

While not entirely random, would a "date based" salt work as well? Say, the date that the entry was added? This would still negate rainbow tables as a specific user entry needs to be targeted.

It would probably work well enough, but... why not just add a proper random salt field that isn't tied to anything an attacker could guess? Is something like 8 bytes per user too expensive?

Perhaps I'm missing something but... wouldn't you still need to store the random salt field somewhere in the database?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#529
post #63

Earlier quoted context omitted.

Pbkdf2 is extremely good. Without deeper analysis (or a feature comparison) I'd be hesitant to say that bcrypt or scrypt are better.

I sincerely mean no offense but this statement came directly out of your butt. Read the table on page 14 of Colin Percival's Usenix paper "Stronger Key Derivation Via Sequential Memory-Hard Functions" (which you could have found by Googling [scrypt paper]); PBKDF2 is ~5x faster (ie: costs ~5x less to break) than bcrypt; PBKDF2 and scrypt aren't even in the same ballpark. From exactly where did you derive the idea tha…

All three are extremely good for this use case, when the competition is SHA-1. Beyond that, I don't know enough to compare the three. So yeah, it came out of my butt.

If Colin has a paper on it then I trust his comparison. What I really meant to say is what you said: all three are just fine.

Also, I thought I remembered my comment's parent saying something stronger, either it was edited later, or I was drunk when I decided it was worth commenting on.

Post reply on HN