6.5 Million LinkedIn Password Hashes Leaked • Hacker News Board

Re: 6.5 Million LinkedIn Password Hashes Leaked

#351

Post by drivebyacct2 » Wed, Jun 06, 2012, 5:33 PM UTC

StavrosK wrote: post #24

Can we please start using BrowserID or some other standard so we can secure that one provider and do away with all this? I'd like it if we could authenticate with Google using 2-factor authentication and be less worried about my password getting hacked.

Wow. Not only is every single reply to StavrosK completely wrong about how BrowserID works, they're actually doubly wrong. Not only is it NOT centralized, it also can be used with:

- 2 factor auth

- asymmetric encryption (aka, a challenge/response ala PGP)

- whatever security mechanism you want, frankly. It's up to the browserid provider.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#352

Post by endtime » Wed, Jun 06, 2012, 5:34 PM UTC

jgrahamc wrote: post #170

Some observations on this file: 0. This is a file of SHA1 hashes of short strings (i.e. passwords). 1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact. Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters…

Good posted, upvoted. One clarification:

> That's 25 users per hash

Password choices are probably Zipf-distributed, so averages don't make a ton of sense.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#353

Post by Hannan » Wed, Jun 06, 2012, 5:37 PM UTC

tptacek wrote: post #262

taybenlor wrote: post #255

Earlier quoted context omitted.

You need more than just bcrypt. You've hinted at other things, but a few random things popping in to my mind: * Preventing password logging (many web frameworks log parameters) * Secure password recovery * New alternative attack vectors (eg. Facebook, Twitter auth) * XSS and CSRF There are so, so many simple to make security errors, and worse - many of them are inter-related so that forgetting one will make another v…

A strong password hash doesn't gate on any of those things, so, while you do indeed need to pay attention to them, you don't need to pay attention to them before you deploy a strong password hash. You should deploy a strong password hash immediately.

True point and this is probably off topic, but out of curiosity, what is the recommended approach for his point about logging messages/requests?

On previous projects, we've gone through all sorts of machinations to detect a password in our SOAP logging. This usually involves XML parsing (slow, ineffective on malformed messages) and Regexes (ineffective on malformed or "unusual" messages).

I can't think of anything better, short of "you can't leak what you don't log" which is nice in theory but not always practical.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#354

Post by drivebyacct2 » Wed, Jun 06, 2012, 5:37 PM UTC

16s wrote: post #135

Zirro wrote: post #130

Earlier quoted context omitted.

What's kept me away from such solutions are these questions: How can you trust one service with all your passwords? What if their configuration has a vulnerability?

Use open-source tools such as SHA1-Pass. The passwords it generates can be recreated with openssl and any other standard crypto library. Edit: I wrote SHA1-Pass, so I'm biased, but I know what you mean about having trust issues with closed-source password tools. That's one of the reasons I wrote it.

You might consider renaming it. I've been looking for several minutes and can't find it via that name.

Is it this: http://manpages.ubuntu.com/manpages/natty/man1/sha1pass.1.ht... I don't see how you would use this the same way you'd use the other tools mentioned here. I can imagine a way, but it's no where near as convenient and still has it's own major usability problems.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#355

Post by hangas » Wed, Jun 06, 2012, 5:38 PM UTC

My belief is that the hackers might get the username password combos, but they grouped the hashes to only have unique (sort -u ?) passwords hashes and therefore ease the process of dictionary cracking them as they do not have salts. The 00000 prefix might be an indication of this. I bet there is an automate script taking care of a dict attack and the file was released during execution.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#356

Post by zer01 » Wed, Jun 06, 2012, 5:38 PM UTC

Anyone looking for the file to run these tests yourself -> http://clck.ru/d/jE6Mg-5X1ARpN

Re: 6.5 Million LinkedIn Password Hashes Leaked

#357

Post by [deleted] » Wed, Jun 06, 2012, 5:39 PM UTC

mseebach wrote: post #320

anxrn wrote: post #315

Earlier quoted context omitted.

I believe this is exactly how LastPass is implemented.

Ugh, you're right. Well, then there's no discernible difference between LastPass and KeePass with the DB on Dropbox.

[deleted]

Re: 6.5 Million LinkedIn Password Hashes Leaked

#358

Post by mehrshad » Wed, Jun 06, 2012, 5:42 PM UTC

lt wrote: post #286

jgrahamc wrote: post #170

Some observations on this file: 0. This is a file of SHA1 hashes of short strings (i.e. passwords). 1. There are 3,521,180 hashes that begin with 00000. I believe that these represent hashes that the hackers have already broken and they have marked them with 00000 to indicate that fact. Evidence for this is that the SHA1 hash of 'password' does not appear in the list, but the same hash with the first five characters…

Another data point: I changed my linkedin password about three weeks ago. The old one is in the list (already 00000-ed), the new one isn't.

Don't know if this adds anything, but both my old password (created eight years ago) and current password (changed six months ago) were on the list. Both were very unique - 20 characters mixed.

Need to get better at changing my PWs every three months. It's really not that hard, just a matter of discipline.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#359

Post by betterth » Wed, Jun 06, 2012, 5:43 PM UTC

zxcvb wrote: post #296

dpritchett wrote: post #281

Earlier quoted context omitted.

That's a trivial modification: $ echo linkedin | xargs node -e "var x = require('crypto').createHash('sha1').update(process.argv[1]).digest('hex'); console.log(x.substring(5));" | xargs -I {} grep {} hashes.txt I'm surprised at the backlash to what I thought was fun code golfing. No one called me names after I posted a simple Python solution that didn't check the file. For what it's worth I've changed my LI password…

My point still stands. There's funny and then theres blatent fanboyism. You're like a prepubescent teenager who doesn't understand the context of social situations so always says something stupid.

Pot, meet kettle.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#360

Post by cschneid » Wed, Jun 06, 2012, 5:43 PM UTC

jcarreiro wrote: post #331

Smerity wrote: post #190

Earlier quoted context omitted.

Please refer to my comment above. You can precompute a rainbow table if you know the username (trivial) and the method of hashing[1]. Whilst usernames as salts would increase security over no salt, it results in a potential exploit / vulnerability that would not exist if the salt was truly random. Hence, suggesting the use of usernames as salts is not wise. [1]: http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

I read cschneid's comment twice, and nowhere to I see where he or she specifically recommends using the username as a password; he or she simply recapitulates the logic behind using a unique salt value for each stored hash, and describes using an additional non-unique value which is not stored with the passwords ("pepper"), which is a new and interesting idea, at least to me.

Re: pepper - The devise plugin for Rails uses it. The idea is that the attacker must now steal both the app code AND database, which are often on separate servers.

Just make their life harder.