6.5 Million LinkedIn Password Hashes Leaked • Hacker News Board

Re: 6.5 Million LinkedIn Password Hashes Leaked

#451

Post by Terretta » Wed, Jun 06, 2012, 8:31 PM UTC

royce wrote: post #418

eidorianu wrote: post #384

Earlier quoted context omitted.

I agree, I've tried several passwords and they match. If you're a Math person, please shed some light on the chances that this list covers the full space.

I'm not a math person either, but here's some fodder for someone who is. Mark Burnett's extensive password collection (which he acknowledges is skewed, because it's largely based on cracked passwords, he only harvests passwords between 3 and 30 chars, etc.). Here's how some of his stats shake out: * Although my list contains about 6 million username/password combos, the list only contains about 1,300,000 unique passw…

It's neat that the hashes are unique enough to serve as their own key. Obvious in retrospect, but still neat.

Curious why some of the hashes have been obscured with 00000 but not all. It means more than one possible password could generate the remaining characters, but what does that help or protect?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#452

Post by jen_h » Wed, Jun 06, 2012, 8:42 PM UTC

madmaze wrote: post #204

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…

I disagree with #5, I had a few of my coworkers check their sha1 against the DB and most of them were not in the dump. I also checked for truncated hashed, none of which were found. I have the feeling this is a subset of the full database

So I have a funny wild theory...remember back when the Gawker database was compromised? And LinkedIn forced a password reset for users who (according to what I read) used email addresses that matched the Gawker leak?

What if they also (or actually) compared password hashes from their database to the ones released in the Gawker breach? In that case, they likely wouldn't have pulled data straight from the database but actually might have pulled passes from the db, output to text files, cut the text files up to parcel out for processing via Hadoop or something? And somehow one of those text files got loose somehow...or someone MiTMed the actual process (I'd vote for a floating text file just because it's been so long; the Gawker breach was in December 2010).

Re: 6.5 Million LinkedIn Password Hashes Leaked

#453

Post by pruby » Wed, Jun 06, 2012, 8:43 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…

The hash of my password, set when I joined on October 10 2011, appears not to be in the list. Changed it anyway.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#454

Post by Aimes » Wed, Jun 06, 2012, 8:48 PM UTC

My old password is not on the list. However, it seems like somebody tried to log on to windows live with the e-mail address and password I was registered on linkedin with. This is one of my oldest passwords from when I still only had one or two passwords.

I noticed this as window live kept sending another of my e-mail accounts a code needed to log in from an unrecognised computer.

Now it could all be a coincidence, but I wouldn't be surprised if there was a connection, as the e-mail address and the password were identical to the ones used on Linkedin. If that's the case there would be a more complete list with my password/hash as well as the associated e-mail address.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#455

Post by mc32 » Wed, Jun 06, 2012, 8:54 PM UTC

I checked a few 6 char passwords (alphanum) some were not present. So they seem not to be bruteforcing them serially. Maybe just checking against other known tables.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#456

Post by localhost007 » Wed, Jun 06, 2012, 9:17 PM UTC

Here is the original file... http://filevelocity.com/ixhk76jz07m5/SHA1.txt_1.rar

Re: 6.5 Million LinkedIn Password Hashes Leaked

#457

Post by pjscott » Wed, Jun 06, 2012, 9:17 PM UTC

sopooneo wrote: post #236

How on earth were they not salting? There are so many open source auth systems now that get all the basics right. Someone who works at a big company like this and has any insight, please comment. How is this even possible in these days?

There's still an unbelievable amount of ignorance out there about how to properly store hashed passwords. There are countless articles explaining that you need to hash the passwords, and telling you how to use md5("salt" + password), and then the blog comments are full of helpful people saying that you should use SHA256, or "no u also gots to add pepper", or exhorting the author to use a large unique salt from /dev/random (not /dev/urandom, it's not random enough) and then encrypt the salts in the database with 2048-bit RSA. I sometimes google around for these articles when I want some morbid fascination -- it's the intellectual equivalent of those YouTube videos where one car crashes into another, and then a third car crashes into the wreckage, and then another car tries to ramp over it and fails, and then everything explodes, and then the people staggering out of the destroyed cars start shouting bad advice about hash functions.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#458

Post by romaniv » Wed, Jun 06, 2012, 9:21 PM UTC

tptacek wrote: post #438

romaniv wrote: post #425

Earlier quoted context omitted.

Computing a hash on 1MB of data is slower than computing a hash of 6-8 bytes of data. Brute-force attacks are based on trying different passwords and seeing that after being salted they generate the same hash as in the database. Therefore, adding a large string to the password before hashing would force the attacker to hash that string. The question is, can this be pre-computed once or efficiently parallelized?

You're advocating creating a 1MB "salt" string to slow down hashes? That's the same as simply iterating your hash function enough times to invoke the block function repeatedly. Just use bcrypt, scrypt, or PBKDF2. People have already figured this problem out.

First, I do not advocate anything here. I asked a question.

Second, working with a large string of bits is the same as recursive hashing only if you can pre-compute some small intermediate state of the hash function for that string independently from the password you're trying to guess. If you can't, you would have to work with the entire string for every new password tried.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#459

Post by 925601568310 » Wed, Jun 06, 2012, 9:24 PM UTC

Putting people's personal details on the open web, giving anyone access, including malicious hackers... This design used by LinkedIn, as well as Facebook, was a bad idea from the beginning. Don't think they are not aware of the risks. How much spam and other annoyances do people get as a result? These companies are killing privacy just to make a quick buck. Maybe they'll be sued.

Direct link to SHA1 file on mediafire (117MB) to avoid javascript, captchas, popups, etc.

http://205.196.120.123/c2o80hrlhteg/n307hutksjstow3/SHA1.txt...

Re: 6.5 Million LinkedIn Password Hashes Leaked

#460

Post by tptacek » Wed, Jun 06, 2012, 9:30 PM UTC

romaniv wrote: post #458

tptacek wrote: post #438

Earlier quoted context omitted.

You're advocating creating a 1MB "salt" string to slow down hashes? That's the same as simply iterating your hash function enough times to invoke the block function repeatedly. Just use bcrypt, scrypt, or PBKDF2. People have already figured this problem out.

First, I do not advocate anything here. I asked a question. Second, working with a large string of bits is the same as recursive hashing only if you can pre-compute some small intermediate state of the hash function for that string independently from the password you're trying to guess. If you can't, you would have to work with the entire string for every new password tried.

I answered your question: using a very large "salt" to force a password hash to run more block functions is a bad idea.

Modern password crackers are extremely fast without precomputing anything.