For fucks sake
Can I put forward the motion that anyone caught not salting their passwords in the 21st century be put against a wall and shot?
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 …
Can I put forward the motion that anyone caught not salting their passwords in the 21st century be put against a wall and shot?
that is all I wanted to say. Proceed.
So when will people learn not to join thisnetworking site, which they only join to fluff up their own egos by faking half the stuff they say they have done!
You mean like every windows user in the world?
MS still didn't implement a salted hash in windows, and to make matters worse you don't even need to crack the pass (google for "pass the hash")...
I'm just happy to know they are hashing the passwords and not storing them as plain text as has been the case in a number of other leaks.
Paris, a number of leaks.
as a freelance consultant, I've got quite a lot of work through connections made on linkedin... so I use it to fluff my bank balance and reduce my mortgage. Go back to playing Gears of War or whatever it is you do when your not fiddling/trolling....
Don't you need some sort of tool to decipher the passwords in their current state anyway?
It's not like Joe Public could just open a text file and find out ?
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.
I use something like BCrypt when hashing passwords using any slow algorithm, esp. at the beginning of the logon process exposes the system to a simple DoS (cpu).
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:
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.
Interestingly mine isn't there, and I haven't changed it for years (it's a low security one). Maybe it's not the whole dump.
Well, if the file was at that link, it isn't any more. At least, it wasn't just now when I went to pull it up via that URL that was posted. The site now says the file isn't there anymore.
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.
> It doesn't contain hashes for any simple words like "password" and "linkedin".
Please double-check. I downloaded the file and both those are in there, as are abc123 123123 hello1 and so on.
can they tell me what it is please...
Buggered if I can remember!
Use different passwords for different websites.
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.
I sure am tired of people saying 'weary' when they mean 'wary'!
Morale of the story? Good God.
Yup, mine's in there, but it was a terrible password.
Would it be safe to assume that 6.5 million is the entire LinkedIn user list?
there's no user names in the file right?
so it's just 6.5m hashed passwords. this doesn't seem like a huge deal to me.
You don't know if the source has a different file with both the e-mail address and passwords in.
Just because they didn't publish them doesn't mean they didn't get them. It's clearly a database dump.
Hey everybody! I have a list with one million words! It's called a Dictionary! Now if I could only find a list of usernames to go with it I'll be minted!
I've commented on 'this' story already.
And before that I made the same comment. ...And previously to that the same again. ...And much, much before that my comment was also the same.
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.
If only there were some way of LinkedIn to contact the users affected and get them to change their passwords. Maybe they should have stored a valid email address for each user. Or implemented their own private messaging system.
This just a ruse by LinkedIn to get you to visit their website again when you change your password.
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.
Yeah. Reminds me of when Monster.com got hacked. I had an email account used solely for Monster, never ever got spam. After the hack, so much spam I cancelled the email.
LinkedIn users can expect the same I suppose.
I've alerted my sysadmin (me) so any increase in spam to that address and..
It's already blacklisted because I got sick of the spam LinkedIn sends itself despite me asking them not to.
If the passwords are unsalted and there are no user ids, then what use is it? All you can tell from using it is X number of people have "fred" as their password, Y number of people have "beer" and so on. It doesn't say who those people are.
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...)
Look at the "Received:" headers. None of those many emails purporting to be from LinkedIn, Facebook, Twitter, Verizon, American Express, etc., are anything more than phishing spam.
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.
They are simply hoping you will pay for a premium subscription, so you can send InMail to people you don't know.
About a month ago I started getting spam email on my linkedin email address. I have never used this email address anywhere except for linkedin.
The same here! So *someone* has gotten hold of a list of email addresses from somewhere... when I reported it to LI they just played dumb of course :-\
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.
Some joker just published an sha-1 of the Oxford English....
I suspect we will never know. Change your passwords.