6.5 Million LinkedIn Password Hashes Leaked
521–530 of 547 posts
Re: 6.5 Million LinkedIn Password Hashes Leaked
#522Whatever 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…
Think you might be expecting too much from large companies =/
Re: 6.5 Million LinkedIn Password Hashes Leaked
#523We'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
#524Earlier 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…
(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
#525Earlier 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?
Re: 6.5 Million LinkedIn Password Hashes Leaked
#526Earlier 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?
Re: 6.5 Million LinkedIn Password Hashes Leaked
#527Earlier 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?
Re: 6.5 Million LinkedIn Password Hashes Leaked
#528Earlier 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?
Re: 6.5 Million LinkedIn Password Hashes Leaked
#529Earlier 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…
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.