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.
5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 is not present
000001e4c9b93f3f0682250b6cf8331b7ee68fd8 is present
Same story for 'secret':
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4 is not present
00000a1ba31ecd1ae84f75caaa474f3a663f05f4 is present
And for 'linkedin':
7728240c80b6bfd450849405e8500d6d207783b6 is not present
0000040c80b6bfd450849405e8500d6d207783b6 is present
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.
"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.
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.)
Regarding requiring users to log in; wouldn't it be better to run their current hash through another password hashing scheme (while we're at it bcrypt, scrypt, PBKDF, etc)? Then, the next time they log in, verify them by running their password through the old algorithm, and the result through the new one.
>> Even if they started with an unsalted password system, users can be migrated to the newer more secure system on next login.
In thinking about this, I wonder if in that scenario you'd even have to wait until next login. You could just use the weak hash as the input to your salted hash function and keep a flag of whether or not you need to 'pre-hash' the password before using your v2.0 salted hash. As users log in you could replace slowly replace the double hashed entries with single salted hash versions and flip the flag.
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?
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'm worried in a few years LastPass could become a target, and now instead of someone having a password that 'could' be shared among your multiple accounts, you have now given the complete keys to the city by listing all of your logons great and small in a central repository.
This central repository then becomes a very appealing target.
I say this as a LastPass user, as I think it is the best of the current offerings, but I'm uncertain how to shield this huge central list. I wish it had multiple logon PW so that you could at least segment the risk and reduce the time the high PW is used to when you really need it.
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.
Keep in mind that whoever leaked the hashes is probably keeping the usernames / emails for themselves. The forum in question doesn't allow posting of user-identifiable information according to the forum guidelines.
The leaked hashes seems to be SHA-1. I've also confirmed that the hash of my own (semi-complex) LinkedIn password is in the list.
Accidentally this is the same password as I had for HN and that I've now changed (phew! THAT'd been bad! :-)
To get a sense of it, I downloaded it from a link here. Below is the structure of the first few lines. Caveat: it's garbage/useless data below -- I intentionally changed around the actual numbers to give a sense of the structure, only:
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.
i agree, but think about the backlash this would create amongst the userbase. the majority of the users will probably never even realize / read that their passwords have been stolen and thus linkedin probably does best in keeping a low profile about this (and start from now on using a better encryption). this is obviously not in the interest of the users, but it is in the interest of linkedin.
Or, they could take the Zappos route and just force everybody to reset their passwords. This route would make adopting a different (e.g. salted) password system quite straightforward.
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.
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.
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...
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.
That's plain old john the ripper running on the cheapest 13" 2010 mbp. John is not even using the GPU, and non-trivial 8-character passwords are scrolling by in my terminal, too fast to read.
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?
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.
(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)
Example:
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
000001e4c9b93f3f0682250b6cf8331b7ee68fd8
[+] [-] jgrahamc|14 years ago|reply
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.
[+] [-] Smerity|14 years ago|reply
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.
[+] [-] Jabbles|14 years ago|reply
(Not recommending it, just wondering if my reasoning is correct.)
[+] [-] ricardobeat|14 years ago|reply
[+] [-] pixelcort|14 years ago|reply
[+] [-] seats|14 years ago|reply
In thinking about this, I wonder if in that scenario you'd even have to wait until next login. You could just use the weak hash as the input to your salted hash function and keep a flag of whether or not you need to 'pre-hash' the password before using your v2.0 salted hash. As users log in you could replace slowly replace the double hashed entries with single salted hash versions and flip the flag.
[+] [-] jcdavis|14 years ago|reply
[+] [-] nohat|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] Zirro|14 years ago|reply
[+] [-] swombat|14 years ago|reply
Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.
[+] [-] Zirro|14 years ago|reply
[+] [-] jgrahamc|14 years ago|reply
[+] [-] K2h|14 years ago|reply
This central repository then becomes a very appealing target.
I say this as a LastPass user, as I think it is the best of the current offerings, but I'm uncertain how to shield this huge central list. I wish it had multiple logon PW so that you could at least segment the risk and reduce the time the high PW is used to when you really need it.
[+] [-] judofyr|14 years ago|reply
Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.
[+] [-] smiler|14 years ago|reply
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.
[+] [-] madsr|14 years ago|reply
The leaked hashes seems to be SHA-1. I've also confirmed that the hash of my own (semi-complex) LinkedIn password is in the list. Accidentally this is the same password as I had for HN and that I've now changed (phew! THAT'd been bad! :-)
[+] [-] kevindication|14 years ago|reply
[+] [-] rbanffy|14 years ago|reply
[+] [-] NatW|14 years ago|reply
000000a94d47b9cb82ca8a3b492a51263b40a66e 000000a98a624314892af97c6f1a0635472eae38 000000a9ba60e7f13fcac444a5a791af7807a3a3 000000a97ea34e74a97a6d1ce08ebc68d3e9aab2 000000a9b4b2a3497aaa51e212ac9efdb00aaf4e
[+] [-] ominous|14 years ago|reply
My password it not in there, but some people have already reported finding theirs.
[+] [-] jere|14 years ago|reply
[+] [-] snorkel|14 years ago|reply
[+] [-] jnorthrop|14 years ago|reply
http://blogs.computerworlduk.com/unscrewing-security/2012/06...
http://thenextweb.com/socialmedia/2012/06/06/bad-day-for-lin...
[+] [-] tazzy531|14 years ago|reply
This wouldn't be difficult to do and your users would appreciate it.
[+] [-] aqme28|14 years ago|reply
[+] [-] slig|14 years ago|reply
[+] [-] jere|14 years ago|reply
[+] [-] jcfrei|14 years ago|reply
[+] [-] philfreo|14 years ago|reply
[+] [-] john-n|14 years ago|reply
[+] [-] philip1209|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] joelhaasnoot|14 years ago|reply
(Source: twitter, haven't looked at it myself)
[+] [-] sneak|14 years ago|reply
[+] [-] mkjones|14 years ago|reply
[+] [-] toyg|14 years ago|reply
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.
[+] [-] smoyer|14 years ago|reply
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.
[+] [-] bermanoid|14 years ago|reply
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...
[+] [-] aparadja|14 years ago|reply
[+] [-] madsr|14 years ago|reply
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?
[+] [-] jurre|14 years ago|reply
[+] [-] bgilroy26|14 years ago|reply
[+] [-] whit537|14 years ago|reply
http://www.mediafire.com/?n307hutksjstow3 (RAR)
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO... (ZIP)
[+] [-] dredmorbius|14 years ago|reply
[+] [-] rfugger|14 years ago|reply
https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...
[+] [-] tantalor|14 years ago|reply
http://stackoverflow.com/questions/2019279/what-is-the-recom...
[+] [-] Imagenuity|14 years ago|reply
If you're a Windows user and you want to check if your password is in the file.
Example:[+] [-] finnw|14 years ago|reply
I'm almost disappointed that mine was not in the list.