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
6.5 Million LinkedIn Password Hashes Leaked
151–160 of 547 posts
Re: 6.5 Million LinkedIn Password Hashes Leaked
#152Am 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?
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.)
Re: 6.5 Million LinkedIn Password Hashes Leaked
#154Re: 6.5 Million LinkedIn Password Hashes Leaked
#155> - 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?
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
#156Earlier 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?
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…
Re: 6.5 Million LinkedIn Password Hashes Leaked
#158What 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.
sort -u combo_not.txt | wc -l 6458020
wc -l combo_not.txt 6458020
Re: 6.5 Million LinkedIn Password Hashes Leaked
#159Earlier 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?
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.)
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.