6.5 Million LinkedIn Password Hashes Leaked(translate.google.com)
translate.google.com
6.5 Million LinkedIn Password Hashes Leaked
http://translate.google.com/translate?hl=en&sl=no&tl=en&u=http://www.dagensit.no/article2411857.ece
511 comments
"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 respect for LinkedIn is if we find that these unsalted hashes were from users who never logged in to LinkedIn after the security upgrade. From the replies of other HN users who have found their password hashes in the leaked list, this doesn't seem to be the case though.
I can understand database leaks. Bad things happen. Not being prepared for such an event however is where I draw the line. These leaks impact users far beyond just the site at fault.
It's not enough to say users should use LastPass. They don't, and that's the world we live in, for better or worse. If computer security doesn't take into account problematic users, then it's flawed computer security.
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 respect for LinkedIn is if we find that these unsalted hashes were from users who never logged in to LinkedIn after the security upgrade. From the replies of other HN users who have found their password hashes in the leaked list, this doesn't seem to be the case though.
I can understand database leaks. Bad things happen. Not being prepared for such an event however is where I draw the line. These leaks impact users far beyond just the site at fault.
It's not enough to say users should use LastPass. They don't, and that's the world we live in, for better or worse. If computer security doesn't take into account problematic users, then it's flawed computer security.
They just tweeted this: https://twitter.com/LinkedIn/status/210356987576324096 - "Our team is currently looking into reports of stolen passwords. Stay tuned for more."
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.
Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.
> - 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.
Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.
I've just downloaded the database linked and it only contains the hashed passwords, not the account usernames / e-mail addresses.
I wonder if someone has the account details to match up otherwise you've no idea which password belongs to who, and you'd hope that LinkedIn would have lockout functionality.
I wonder if someone has the account details to match up otherwise you've no idea which password belongs to who, and you'd hope that LinkedIn would have lockout functionality.
Other sources are starting to report this as well:
http://blogs.computerworlduk.com/unscrewing-security/2012/06...
http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-lin...
http://blogs.computerworlduk.com/unscrewing-security/2012/06...
http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-lin...
Good Guy Startup Founder would cross reference this password list with their own password system and force those that match to reauthenticate and change their passwords.
This wouldn't be difficult to do and your users would appreciate it.
This wouldn't be difficult to do and your users would appreciate it.
Database is available here https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...
(Source: twitter, haven't looked at it myself)
(Source: twitter, haven't looked at it myself)
I wonder, what if this list wasn't leaked from LinkedIn databases, but rather from some third-party service using the "enter your password" anti-pattern? A flaky service like that would likely not be very good at safely storing passwords.
Unfortunately, LinkedIn keeping mum on the subject makes it easy to speculate that it was actually coming from them. Otherwise it'd be easy to deny (and even spin: "How dare you! We never store unsalted hashes, we follow state-of-the-art practices here!!"). Also, their security track record is... embarrassing as it is.
Unfortunately, LinkedIn keeping mum on the subject makes it easy to speculate that it was actually coming from them. Otherwise it'd be easy to deny (and even spin: "How dare you! We never store unsalted hashes, we follow state-of-the-art practices here!!"). Also, their security track record is... embarrassing as it is.
I wonder how many LinkedIn users use the same passwords for all their accounts. The article talks about identity theft and "confidential contacts" but I think the real danger is that people tend to use the same password everywhere. It's their other accounts that might have real value.
EDIT - As I think about it, e-mail accounts would be especially valuable as most of your other sites could be compromised using the "recover my password via e-mail" feature if the hacker could read the resulting mail.
EDIT - As I think about it, e-mail accounts would be especially valuable as most of your other sites could be compromised using the "recover my password via e-mail" feature if the hacker could read the resulting mail.
Whatever manager it was that tasked some junior programmer (particularly one that didn't know that unsalted SHA1 is a terrible idea) with implementing the password system at LinkedIn needs to be fired. Making the programming mistake means that you don't know much about web security, and while not a great thing, that's forgivable; putting someone that's utterly unqualified for code with security implications on such an important task is not. Nor is letting the code get deployed without having someone that knows what to look for review it. Nor is letting such a bad decision remain live for...what is it now, almost 10 years?
But let's not stop there. There are probably a dozen other people at the company whose job it is to avoid blunders like this, all the way up to the top technical staff. After all, LinkedIn is not, and has not been for some time now, some tiny underfunded startup. It's a goddamn public company, and even before that it was a super-team Silicon Valley darling that was getting money thrown at it since even before tech became cool to invest in again, and it's been valued at over a billion dollars for almost five years now. There is absolutely no excuse for this, they should have been doing regular security audits for years, and no audit worth its salt would miss something this simple. I absolutely refuse to believe that this problem was unknown, that nobody ever commented or filed a bug report about this code - no, this was deprioritized, because it wasn't considered a high enough value problem. And now it's bitten them in the ass and become a problem, probably because some other security vulnerability was similarly deprioritized instead of fixed.
I expect this from some shady Bitcoin market that a high school kid runs off of a server in his bedroom. I do not expect this type of amateurism from a 10 billion dollar company with hundreds of engineers, many of whom have specifically looked over that code, some of whom have probably complained about it, and all of whom should know better than to let it fester...
But let's not stop there. There are probably a dozen other people at the company whose job it is to avoid blunders like this, all the way up to the top technical staff. After all, LinkedIn is not, and has not been for some time now, some tiny underfunded startup. It's a goddamn public company, and even before that it was a super-team Silicon Valley darling that was getting money thrown at it since even before tech became cool to invest in again, and it's been valued at over a billion dollars for almost five years now. There is absolutely no excuse for this, they should have been doing regular security audits for years, and no audit worth its salt would miss something this simple. I absolutely refuse to believe that this problem was unknown, that nobody ever commented or filed a bug report about this code - no, this was deprioritized, because it wasn't considered a high enough value problem. And now it's bitten them in the ass and become a problem, probably because some other security vulnerability was similarly deprioritized instead of fixed.
I expect this from some shady Bitcoin market that a high school kid runs off of a server in his bedroom. I do not expect this type of amateurism from a 10 billion dollar company with hundreds of engineers, many of whom have specifically looked over that code, some of whom have probably complained about it, and all of whom should know better than to let it fester...
Cracking the passwords from the hashes is not just fast, it's ridiculously fast. I can't believe a site like LinkedIn stores their passwords this way in 2012.
guesses: 11516 time: 0:00:21:36 0.00% (3) c/s: 27126G trying: aptewwod - aptewws1
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?
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?
There should be a huge banner on linked in urging users to change their passwords in my opinion.
Here are a couple links to the file:
http://www.mediafire.com/?n307hutksjstow3 (RAR)
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO... (ZIP)
http://www.mediafire.com/?n307hutksjstow3 (RAR)
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO... (ZIP)
Um, pardon the obvious question, but does someone have a direct link to the hash file?
Maybe they read this SO thread?
http://stackoverflow.com/questions/2019279/what-is-the-recom...
http://stackoverflow.com/questions/2019279/what-is-the-recom...
My old password was in the password file, and it was flagged as cracked.
If you're a Windows user and you want to check if your password is in the file.
If you're a Windows user and you want to check if your password is in the file.
(1) download the passwords file from http://www.mediafire.com/?n307hutksjstow3
(2) the download is a RAR file, so you'll need to have WinRAR installed to extract it.
(3) to get the sha1 version of your password, go to duckduckgo.com and type:
sha1 yourpassword
(4) copy the result, except for the first 6 or so characters
(5) open a DOS command prompt (WindowsKey+R and type CMD)
(6) type (quotes required where indicated): find "sha1hash" sha1.txt
(note: to paste to the command prompt is right-click)
The sha1 hash of the password 'password' is: 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
Remove first six characters: e4c9b93f3f0682250b6cf8331b7ee68fd8
enter at command prompt: find "e4c9b93f3f0682250b6cf8331b7ee68fd8" sha1.txt
result:
---------- SHA1.TXT
000001e4c9b93f3f0682250b6cf8331b7ee68fd8The SHA1 of my LinkedIn password naturally starts with "00000". I wonder if that would have thwarted the original cracking attempt.
I'm almost disappointed that mine was not in the list.
I'm almost disappointed that mine was not in the list.
I can confirm that my password was in there. I have changed it. My password was "98mnja6z" which hashes to 6475590bc1407aa98c8b022230292cce3d8528b3. I used this for no other sites, so I'm not concerned about it leaking.
It is inexcusable that LinkedIn hasn't alerted their users yet.
It is inexcusable that LinkedIn hasn't alerted their users yet.
I'm starting to think it might be wise, if you intend to reuse your password on multiple sites, to salt it yourself. By using a form like "<site name><user name><reused password", you protect yourself from rainbow tables without making your username harder to remember.
And yes, yes, I know you shouldn't be reusing your password across different sites, or using a dictionary word anyway. And teenagers also shouldn't be drinking, doing drugs and having sex. It doesn't help anything to pretend that people are going to behave optimally.
Of course, the preposterous restrictions that websites put on passwords, like maximum password length, will make this idea harder to put into practice.
And yes, yes, I know you shouldn't be reusing your password across different sites, or using a dictionary word anyway. And teenagers also shouldn't be drinking, doing drugs and having sex. It doesn't help anything to pretend that people are going to behave optimally.
Of course, the preposterous restrictions that websites put on passwords, like maximum password length, will make this idea harder to put into practice.
Given they haven't confirmed they've found and closed the leak, is it wise for everyone to be changing their passwords already?
This makes me wonder. I've been relying on Django's built in user authentication lately. Does anyone know if that's pretty safe? Is it doing the right thing for hashing passwords?
You can generate your own SHA1 for your password and check if it's existing in the txt file.
http://jssha.sourceforge.net/
http://jssha.sourceforge.net/
I literally created my LinkedIn account only 2 days ago. And my password was in the list and cracked. Thankfully I don't use it for anything else.
Obviously the list was filtered to eliminate duplicates. It contains only what the hackers wanted it to contain. So, why does nobody mentions that it is HIGHLY LIKELY that the user names associated with the passwords (which are actually mainly e-mail addresses for LinkedIn) are also in the possession of the hackers.
So, if I would be the hacker - strip usernames, strip duplicate hashes, post list of unique hashes to let others do the CPU intensive cracking, retrieve cracked passwords, match with usernames (e-mail address), check same password on other accounts (first on the e-mail account, then google the e-mail address on forums or try on the services that interests me and say "forgot password, send it again to this e-mail address - thank you telling me that this e-mail has indeed an account with you..."), monetize somehow the data.
As a user that implies - IMMEDIATELY change your password for the e-mail address used to login at LinkedIn (if it was the same password); verify if settings of this e-mail account have changed (like an additional unknown address added to allow retrieval of the password, DUH),
try to remember where you use the same address either as login or to recover credentials, try to remember where you used the same password, google you e-mail address to help you remember; change passwords; consider abandoning the e-mail address if it is not your primary one,...
Also - did the amount of SPAM that you receive on the e-mail address used to login at LinkedIn suddenly increased, while SPAM remained constant on a similar mail account not connected to LinkedIn ? Maybe someone just sold your e-mail address, so the LinkedIn break may affect you even if the password is not in the list.
Bottom line is - LinkedIn approach appears to be: We have no proof that this particular account was hacked since password hash is not in the list - let's not overreact and let'sassume it is not hacked even if we don't have a clue what was actually hacked. I'm not to judge if it is the best approach for the business, but sure as hell I don't like this approach as a user.
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.
I wrote a short article about this kind of stuff - if it's really my data, then let me use my lock on it : http://ragmondocom.appspot.com/2012/03/My-Stuff-My-Lock
Then I get to choose what strength lock I put on it.
Then I get to choose what strength lock I put on it.
I know a lot of companies just keep your account including your password in there database while you removed your account.
Can I be sure my account was totally removed when I removed my LinkedIn account? Because the "please change your password as soon as possible" won't help me much.
Can I be sure my account was totally removed when I removed my LinkedIn account? Because the "please change your password as soon as possible" won't help me much.
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 set to 0 is.
Same story for 'secret':
And for 'linkedin':
2. There are 2,936,840 hashes that do not start with 00000 that can be attacked with JtR.
3. The implication of #1 is that if checking for your password and you have a simple password then you need to check for the truncated hash.
4. This may well actually be from LinkedIn. Using the partial hashes (above) I find the hashes for passwords linkedin, LinkedIn, L1nked1n, l1nked1n, L1nk3d1n, l1nk3d1n, linkedinsecret, linkedinpassword, ...
5. The file does not contain duplicates. LinkedIn claims a user base of 161m. This file contains 6.4m unique password hashes. That's 25 users per hash. Given the large amount of password reuse and poor password choices it is not improbable that this is the complete password file. Evidence against that thesis is that password of one person that I've asked is not in the list.