Live data from Hacker News

6.5 Million LinkedIn Password Hashes Leaked

translate.google.com

151–160 of 547 posts

Re: 6.5 Million LinkedIn Password Hashes Leaked

#151
post #142
post #108

Earlier quoted context omitted.

The dump is not complete -- my password is also missing. As other people said, that file contains about 6.5 million hashes, while LinkedIn has 30 times more users. Considering how usernames weren't leaked, there's a big chance that the intruder is just sitting on them and the other passwords.

My password is missing too (if i've done right the hash generation as illustrated above). It's strange that only hashes starting with "000000a9" are present, someone said here that it's just presentation but my hashed password is 40char long as those leaked including the 000000a9

Either you don't have a complete file or you haven't scrolled through it. Only the first 277 hashes start with that string (and some others scattered throughout).

Re: 6.5 Million LinkedIn Password Hashes Leaked

#152
post #130
post #98

Am I glad that I use LastPass and have a different, 12-character password for every service? Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.

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?

I think it's a risk with a solution like this, but much less of a risk of having to remember all these passwords myself (a practice which tends to devolve to re-using passwords).

Re: 6.5 Million LinkedIn Password Hashes Leaked

#153

"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain resp…

Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)

Please don't downvote posts like the parent. It's a legitimate comment, asking a question, if you have something to say please reply.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#154
I didn't see it in the post, but does anyone know if these were current passwords (as of this post)? I use a unique password for linked-in, but some number of months ago I used a password I shared with another site. Wondering if I need to change that one too. Guess I might as well.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#155
post #6

> - With a computer of 8,000 NOK (~ 1400 USD), you can do a few hundred million attempts per second. Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.

I'm not familiar with iterations, anybody care to clue me in? I would have thought salted sha-1 would be decent for password hashing, though not the most solid possible, but at least not laughable. Is that not the case?

It is not. Sha1 is designed to be fast. You want your password hash function to be slow, so that an attacker has to spend as much resources as possible to brute force it.

Of course, it does not mean you should take a slow implementation of a fast hash. You need a hash that, when implemented to be as fast as possible, still is pretty slow.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#156
post #62

Earlier quoted context omitted.

This isn't really the issue. The real issue is that MD5 (though these hashes are SHA1, which has the same problem) are too easily computed; they are practically byte-forceable. I don't need a rainbow table to compute hashes when I can slam out millions in short order using a GPU. You have a good point about needing to know the salt, but getting the salt is generally easy because it's usually stored in the same place…

Let's forget about bcrypt for a second. What prevents developers from adding a large DB-wide salt (in addition to normal salt) to every password? Wouldn't that prevent bruteforce attacks regardless of the hashing algorithm?

Is there a significant time difference in computing the SHA1 hash of 40 bytes versus say, 128 bytes?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#157

"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain resp…

What do you recommend users do instead? Unfortunately there will probably always be websites storing passwords in unsecure ways. I mean I'd certainly rather not have to deal with the hassle (however small) of using LastPass, but as you said, that's the world we live in. Hoping for competence by the writers/maintainers of websites is also flawed computer security, is it not?

Re: 6.5 Million LinkedIn Password Hashes Leaked

#158
post #58

What riddles me though, is how come 6.5 million? LinkedIn has what, 150M users? Did they not post the entire load (and are in fact sitting on _all_ the hashes?) Is the dump an old backup or breach from when they had fewer accounts? Is it just one DB partition / file that's been lost, an archive?

Given that these hashes are not salted, running a 'uniq' on the list of all users' password hashes would probably already cut it by half, if not more. Then you eliminate all the easy ones from wordlists, and post the remains on the internet for people with excess computing power to bruteforce.

They are already unique and sorted.

sort -u combo_not.txt | wc -l 6458020

wc -l combo_not.txt 6458020

Re: 6.5 Million LinkedIn Password Hashes Leaked

#159
post #137
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?

I've always wondered this about services like lastpass. What stops being hacked / keyloggered and them exfiltrating all your long, complex passwords?

I use 1Password, rather than lastpass. On that system, your password file is stored locally by default, so their isn't a centralized password store to attack. If you do syncing of passwords between machines, you keep an encrypted password file in your dropbox account.

Re: 6.5 Million LinkedIn Password Hashes Leaked

#160

"We were curious what would happen to our share price if our company did something incredibly stupid" The above comment might seem incredibly harsh, but really, there's no good excuse for a site this prominent to not have a salted, secure password hashing system. Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login. The only way I could regain resp…

Surely just hashing the username|password would massively reduce the effectiveness of leaks like this? Sure, a hacker would know what the "salt" is, but since it now varies between users you would expend the same amount of effort breaking one person's login as you previously would spend breaking everyones (on average). (Not recommending it, just wondering if my reasoning is correct.)

It would make it a lot easier for LinkedIn to identify whose hashes were leaked because with a salt, all passwords would be unique. It would also make rainbow tables useless.

But in this day and age, the bigger problem is how fast you can compute the hashes, salt or no. With GPUs you can calculate a few hundred million(depending on the hashing algorithm) per second, making the algorithm used the real vulnerability.

Best practice involves increasing the calculation time of you're algorithm. Theoretically, you could just rehash y few thousand times in a loop, throwing in a salt here and there, but practically, you should just use bcrypt or scrypt.

Post reply on HN