Hackers expose 6.5 MILLION 'LinkedIn passwords' LinkedIn has said it is looking into a file that reportedly contains the mildly obscured passwords of around 6.5 million of its users. A list containing the SHA1 hashed but unsalted passwords, purportedly of users of the business social network, has been posted on a Russian Dropbox-alike website. Some LinkedIn users have …
Right here. If the speed claims are true, it wouldn't even take a noticeable amount of time to brute-force all 6.5M hashes in the list. Sure, you need to be vaguely clever and equipped with a shit-hot GPU to use it, but there's no shortage of people with those two qualities...LinkedIn users, right now might be a real good time to change your password.
You can't decipher them, but you can hash a password and compare it against the stored value to see if it's the same.
So if you've pregenerated the SHA-1 hashes of several million words (known as a rainbow table), identifying which of those passwords are in the list is trivial. That's why salting is important - it adds a small amount of random noise to each string, so you can't just compare the hashed values - it makes cracking much slower.
But not hugely slower, especially since you have to store the salt somewhere (or generate it somehow, presumably running some function on the user/pass combination and hope that when you're breached your salt generation logic isn't filched too).
Rainbow tables, whilst useful, are not the poster child they used to be - there is so much processing power around these days that, given the hash, you can quite quickly test millions of candidates per second on a fairly standard GPU.
SHA-n, MD5, etc. are built for hashing large streams of data quickly - great for ensuring that it hasn't been tampered with, but hopeless when it comes to storing passwords because their inherent speed is a disadvantage. As a general rule, I use something like BCrypt when hashing passwords - this allows you to slow down the hashing function using a factor, which makes generation of rainbow tables/brute forcing a very slow exercise. The down side is that it also slows down validation slightly, but speed vs. security is always a tradeoff and I'd rather it takes a few seconds longer to log me on to a system if it also makes it harder to brute force my password should security be compromised.
Generally the salt is stored as the first few letters of the password (UNIX did that back in the day when passwords were still in /etc/passwd, and from memory MySQL does the same).
I think the main difference is the approach changes: with enough salt, for each password you're attacking you have to work your way through your dictionary, SHA-1ing each word with the salt and comparing. Even with a GPU, for a million word dictionary thats (say) 8MB you have to SHA-1 and that's just for one password.
Without salt, you have a precalculated and lexically sorted list of precalculated hashes. Sort your password list and iterate through both lists running comparisons. In a matter of seconds you've busted every password that's in the dictionary.
I agree with a properly designed system doing hashes in parallel you can get some crazy speed, and I sure agree on something other than one iteration of SHA-1 or MD5. But you're still many orders of magnitude slower than without salt.
As we've seen - you can brute-force your way through a small password space (let's just say "8 characters" to keep it simple) fairly quickly ("days"). Rainbow tables allow you to brute-force a larger space ("12 characters") over a length of time ("months") and store the results for future use.
Having a decent-sized per-password salt (of say 16 random printable characters) therefore pushes the password space way beyond the reach of rainbow tables. (It also means that each password needs to be tackled individually, rather than generating a hash and seeing which ones match).
However, such a salted password, if intrinsically weak, is still vulnerable to the dictionary attack (e.g. test for 'pa$$word', 'qwerty12345', etc) and brute-forcing (e.g. it's only 8 characters long, all lower-case).
That's why you need a second site-wide salt that is not stored in the database. Database compromises seem to happen all too frequently, but source code doesn't seem to leak so often.
Dom 3: "That's why you need a second site-wide salt that is not stored in the database. Database compromises seem to happen all too frequently, but source code doesn't seem to leak so often."
While this would help, for sites like LinkedIn which are very open about setting up accounts the attacker could have already set up an account and so be able to derive the site-wide auxiliary salt. Basing the auxiliary salt on a hash of the user name and password (and a constant) might help a little.
A higher cost mechanism could use checks from multiple sites to authenticate (presumably with tolerance if one site is determined to be down at the moment or perhaps a secondary, more secure but more cumbersome authentication method).
If a high-profile site cannot be bothered with using salts, there is not much hope for widespread use of more sophisticated authentication.
It's possible it's a duplicate of someone else's as I don't care enough about LinkedIn to use a super hardcore password but I found 1 instance of it in that file.
BTW Don't know if I'm allowed to post this but the file is located at:
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhObEEH5u5PKPlp+muGtgOEptAS4=
That's the link to the .txt file with the hashed passwords.
Open your unix terminal to get your own hash of your password (replace your_password):
echo -n your_password | shasum | cut -c6-40
Open your favorite text editor (I recommend TextWrangler if you're on Mac OS X) and do a search for that hash.
It doesn't contain hashes for any simple words like "password" and "linkedin".
So either ALL linkedin users are good little security experts - or this is only the list of ones that they didn't immediately crack with rainbow tables.
Since 6.5M is only a fraction of linkedin's 160M users - it could be that an awful lot of them are using the same password
My old password was in there. And by "old" I mean one of the 2 or 3 I used to use absolutely everywhere before the idiots over at Gawker Media got pwned. I doubt anyone else had this particular password.
Luckily the Gawker leak was my "don't use the same password everywhere no matter how good you think it is" moment, so I've already made sure I don't have to hunt down all my assorted accounts for a password change, ever again.
Use different passwords for different websites.
And:
Be weary when linking social media passwords to access other (semi-important) websites.
I know it sounds cliche but I'm posting it anyway because I've been there too where I basically used the same (or slightly changed) password for lots of websites. But really; with all the current (IMO excellent) password agents around (even regular stuff such as OneNote can suffice) there should be no need for that anymore.
It takes a little bit of extra effort, but if something does go wrong then the damage is always limited.
And as for accessing contents from other places: don't you have a phone with an app for that which can also remember your password for you ?
>And as for accessing contents from other places: don't you have a phone with an app for that which can also remember your password for you ?
And if you lose the phone?
There's two problems there. First is the questionable idea of storing all your passwords in one location protected by just one 'key'. Maybe not a huge deal but still a bit dodgy - once cracked they've got everything.
The second problem is that by not trusting your memory I think you are weakening it. At least that's my experience. I have found that if I trust my memory it does a lot better. I tend to think of it like a nervous child. If you demonstrate your trust in it you get better performance out of it. Actually that seems true of other things as well. I play golf and my best shots are those when I just let my body get on with it. The worst shots are always those when I second guess myself or try and consciously control the club.
"And as for accessing contents from other places: don't you have a phone with an app for that which can also remember your password for you ?"
Nope, I have a old 6310i.
Some of us prefer several hours talk time and a few weeks of standby from a phone, over seeing if someone has had pizza and a cup off coffee for dinner, or that the weather outside is currently raining.
OK, down-voters. Next time I'll avoid the sarcasm.
For those who didn't get it, the point was that there are so many break-ins of this kind that the news of them is becoming seriously repetitious--i.e.: there's a serious security problem out there in user-land.
I did put 'this' in inverted commas but that went over yuh heads too.
Sorry.
This post has been deleted by its author
Wouldn't building a 6.5M entry list of 'passwords' and claiming to have hacked them be worth it?
In any event, my password is 40+ randomly generated characters. (both old and new)
The downside is that I rely completely on my password manager.
I do wish people would get wise to this business model, which before LinkedIn was used by Plaxo, and by several others before that I am sure - the "give us all your contact information, and we will help you *manage* them (oh and by the way, we will use that as an excuse to spam them to get them to join us and give us all their contact info, and so on)".
I've received several bogus "LinkedIn Email Confirmation" emails just today (and since I am vehemently NOT on LinkedIn I know they are bogus), but it does make me wonder who is getting snookered by this.
I almost want to send an email out to all my contacts:
"If you receive ANY email claiming to be on my behalf, inviting you to join some social networking site, IT IS BOGUS - If I think you might want to join something I will email you directly, and make the pitch for it in my own words."
Hmm. I'll bet a service to send out those sorts of emails would be worth something to somebody.... (/me rushes off for VC funding...)
Trusting email headers isn't foolproof though. There's almost nothing in the headers that is verifiable and even email servers don't need to process them and most probably don't even bother. It's part of the 'charm' of SMTP.
Basically it's like a textual version of FTP. Server A contacts Server B and asks it to put some data into mailbox 'C'. Whether that data consists of valid SMTP headers and useful human text is fairly irrelevant really. I assume that a good server would check the syntax but that's probably about all it does. What matters is what the 'RCPT' command says and whether Server B trusts Server A.
I could send you an email with headers indicating that it was addressed to Michael Rodent, President Obama and seemed to come from Pope Benedict the 16th. I doubt whether your server or your client would bad an eyelid :)
Now that LinkedIn requires that I know a recipient's email address before I send an invite, it's become useless to me. If I already have their email, I have no use for LinkedIn. If LinkedIn won't let me contact them without it, it's just a source of unnecessary frustration.
This post has been deleted by its author
Worst case:
The file name is combo_not.txt, so it may just be a list of just the hashes that a simple dictionary attack could not solve. The cracker really has every detail from every account but didn't share it.
Best case:
Some joker just published an sha-1 of the Oxford English....
I suspect we will never know. Change your passwords.
... and a random 90% of people are finding their entry in there, then doesn't it suggest that teh figure of 160m Linked-in Users is bollocks.
Time to call in the SEC and question whether accurate information was provided for their float and whether this has aby bearing on the valuation attached to the comany and their share price.
The list is de-duped. So what that tells me is that LinkedIn's user base is not that creative; probably close to 1 million accounts could be using "asfd1234" as their password, and another 2 mil using "password".
Alternatively, this is just a sample to show that they did produce the hack. Haven't people said, on the various Annon hack articles, that releasing the user names and passwords is a Bad Thing? These guys are being considerate of the LI users, and not publicizing the full credentials.Just enough evidence to show that they got in and owned LI's database.
If you're worried just log into your account / settings using this link https://www.linkedin.com/settings/?trk=hb_acc or go to the top right hand corner and it's under your name :)
Then under your primary email address is password change and set a new one, heh presto fixed - move along :)
James
The Linked In Man
You make a valid point but spoil it by the tone. It is always a bit embarrassing when people who don't understand something describe it but at least Brid was highlighting the key failure in the procedure.
I wonder if not salting and encrypting passwords will soon be considered as negligent.
@Gordon Stewart - I was ready and primed to ctrl-v that very same quote and let fly a stream of "pithy" vitriol :) Good job I checked to see if anyone else had got there first!
I would add that hashing != encryption. Oh, and I didn't think your tone was particularly bad (not that you care, but just saying...)
But yes, salt *then* hash. Salting just makes the stored password change from "mypass" to "Z//GRmypass" etc. Hashing the salted password devalues everything but the most complete rainbow tables.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
