Mine was not in the list. I had a non-dictionary password with letters and numbers, 8 characters, and it was at least several months old.
(If we can collect enough data points of whose passwords are on it or not, how old they are, and how complex the password was, we should be able to narrow down a potential date range for the list and the odds that the compromised list is full or partial.)
Not necessarily. There are two possibilities we can analyze:
1. "not on the list" means "not in the hacker's possession". In other words, the compromised list is partial.
2. "not on the list" means hacker already has cracked it and didn't post for help.
Learning more about the kinds of passwords not on the list could help us determine which scenario is more likely. (If lots of complex passwords are not on the list, that is evidence the compromised list is partial. If only simple passwords or passwords of a certain pattern are not on the list, that is evidence the compromised list is complete and passwords that were already cracked were not posted.)
As I understand it they zeroed out the start of the hashes they've already cracked (that's the speculation). I'm assuming that's being checked for server side?
According to LI they started salting at some point. Simple hashing obviously won't match in that case but I guess the crackers have the salts so they can do the leg work themselves.
Annoyingly LI say that they've invalidated passwords on compromised accounts but I can see that's not the case. My password hash is in the list (random 20 char pw) but they didn't deactivate my password (I've obviously changed it now).
You can provide your own hash, and a quick source check reveals that plaintext is being converted into a hash client-side, so only hashed data is being sent to the server.
Not necessarily a bad security practice. If you want a throwaway account for whatever reason, then why increase your cognitive load by coming up with a good password?
You can supply just your password hash if you want, and if you supply the raw password, it's hashed client-side via Javascript before being sent to the server. Test it out with firebug and a dummy password if you're not keen on wading through the source.
Still, hashes can be cracked, and an evil password-checking website can then associate the password with all of the other personally-identifiable data that browsers are known to leak. I don't think this particular site is being evil, but it would be wrong for a user to trust a site like this.
I mean server-side (can we check the source for that?). The server could crack the hash, and the server could use various pieces of data (ip address, http headers, etc) to try to figure out more about the password's owner.
True, that's completely possible. However, if this concerns you then you should probably not sign up for any account on any site, since they could be doing the very same thing with your actual password.
And even if there's no "trickery" from the hosting site, they're slurping in javascript from a 3rd party down the bottom (getclicky). That means they (or anybody who compromises them) could grab the cleartext passwords from the form before the inline javascript does it's sha1 hashing…
Even if you don't check the source code to verify that it's harmless, you should assume your password has been compromised and have already changed it anyway. This just lowers the cost of checking the list and could help us learn more about the compromise.
> users who have already changed their passwords or created a new account won’t have to worry, as they have recently begun hashing and salting their current password databases.
Years ago, 1996, we had a border router that we inherited and didnt have the password to, nor any way to get it. It was in production and we needed to get the password without killing the config.
David Sifry (founder of linuxcare) was my consultant on the issue - he was able to recover the password after some effort. I'll never forget what it was: Feet4monkey
That's a bash-ism that's controlled by the $HISTCONTROL environment variable, not universally-applicable advice. $HISTCONTROL set to "ignorespace" or "ignoreboth" may or may not be the default, depending on your distribution.
Yeah already replied below specifying that - I was under the impression that it's default to on in most distros, but don't actually have a clue which do/don't.
I saw a spam once that said "Is your husband's password compromised? Check it on this site ..." clearly trying to social engineer a spouse into 'doing a favor.'
How about submitting the hashes over https, at the very least somebody could be sniffing the traffic from your site and gathering the hash list for themselves..
"Your password was leaked and cracked. Sorry, friend."
Well that's lovely. Just changed my LinkedIn password so hopefully no one had a chance to take advantage of that. Luckily I very recently switched to a new password scheme so my other accounts should be secure too.
yipes - apparently that site sends up an unsalted sha1 of your password. If leaked unsalted sha1s are worth being worried about, then typing your password into this site is just as bad as the original leak
Like others have stated, you should assume your password hash was leaked anyway. Change it first, then put in the old password into this tool for curiosity's sake.
What is standard practice for a situation like if the users lost access to the email account they signed up with?
A large forum I post on was hacked recently and - after voluntarily shutting their site down for a month - they required password resets. If users did not have access to the email address they signed up with and couldn't otherwise verify their identity, they were not allowed to get their account back.
Unsurprisingly, post counts are down site-wide and the owners have reported a > 25% decrease in traffic.
You can ask for previous passwords, if there are any payments involved you can ask for the transaction ids, obviously if you have secret questions or verified mobile you can ask for that.
Of course all of those things can be used to gain access to the account by attacker, without actually knowing the password. See recent Cloudflare incident. Google will notify you about the recovery attempt, monitor for activity, and delay it for at least a week or so. So the attacker just have to wait till you go on offline vacation ;)
Really though, for something as low key as a forum you’re entirely justified to offer recovery only via email. The email providers already offer all those alternative recovery options. And of course you should prefer OpenID to avoid the issue altogether.
> Unsurprisingly, post counts are down site-wide and the owners have reported a > 25% decrease in traffic.
That’s because they took the site down for a month!
The problem isn't really your LinkedIn password ... I mean, someone could mess up your profile, send embarrassing messages and so on, but many many people will have used the same password for amazon, apple, paypal and other financial things, or used the same password for an email account which can be used to "recover" the password for one of those things.
The leading '(stdin)=' messes the pattern being fed to 'grep'.
Yes, I've read http://partmaps.org/era/unix/award.html#cat . The output of sha1sum already contains a trailing '-' which is something I wanted to feed into 'grep' using command substitution, so that 'grep' can now just accept the input stream from 'stdin'. Now, how do you feed the input to grep via 'stdin' if you don't want to use 'cat'?
If you look where we started ( http://news.ycombinator.com/item?id=4076559 ), I'm not trying to feed the regex pattern to grep via stdin, but I'm trying to feed the input stream to be searched for the pattern to grep via stdin.
I'm wondering about the legality of this. If you take an (assumed) stolen dump of sensitive data and turn it into a webservice, could you get in trouble?
I cut the hash database into 256 pieces based on the last two digits of hash so chunk is smaller than 1MB. To check one password it only downloads one piece. So hopefully it won't be that bad.
Assuming the split is computer-generated based on a parameter, why not use the last three digits and cut it into 4096 pieces, where each chunk is under 64KB? If your bandwidth bill is small it won't matter (ie: not worth the time involved) but if you get a bunch of traffic your cost is 1/16th of what it would have been. Also, to the user the site will be way more responsive as the download will happen quicker.
Oh.. Didn't know anyone already made this - i also made a tool, but it doesn't send your whole hash over the wire (only the last 4 chars). http://olemartin.org/linkedin-passwords/
Nice looking page for such fast work. What about letting 'advanced' users check the SHA1 of their password, so they don't enter their password at all but also don't have to track down the giant file?
That should work already - just use the other field and click the button. :-) There's no giant file though, i've split the giant file into ~65000 smaller ones that are more bandwidth friendly.
193 comments
[ 3.2 ms ] story [ 254 ms ] threadEDIT: Actually never mind, seems like it's much faster now.
To be safe, you should consider the SHA-1 hash of your LinkedIn password to be public, even if it's not one of these 6.5 million.
(If we can collect enough data points of whose passwords are on it or not, how old they are, and how complex the password was, we should be able to narrow down a potential date range for the list and the odds that the compromised list is full or partial.)
1. "not on the list" means "not in the hacker's possession". In other words, the compromised list is partial.
2. "not on the list" means hacker already has cracked it and didn't post for help.
Learning more about the kinds of passwords not on the list could help us determine which scenario is more likely. (If lots of complex passwords are not on the list, that is evidence the compromised list is partial. If only simple passwords or passwords of a certain pattern are not on the list, that is evidence the compromised list is complete and passwords that were already cracked were not posted.)
According to LI they started salting at some point. Simple hashing obviously won't match in that case but I guess the crackers have the salts so they can do the leg work themselves.
Annoyingly LI say that they've invalidated passwords on compromised accounts but I can see that's not the case. My password hash is in the list (random 20 char pw) but they didn't deactivate my password (I've obviously changed it now).
Head:
Tail:It's not clear to me how the file was sorted. Anyone have any ideas?
openssl dgst -sha1 password
will give you the hash you need. Mine has been leaked but not cracked, according to this site :-(.
> users who have already changed their passwords or created a new account won’t have to worry, as they have recently begun hashing and salting their current password databases.
http://techcrunch.com/2012/06/06/linkedin-speaks-some-of-tho...
David Sifry (founder of linuxcare) was my consultant on the issue - he was able to recover the password after some effort. I'll never forget what it was: Feet4monkey
Your post reminded me of that.
Just submit your credit card number, CVV2 and expiration date and it'll check if it has been stolen over the internet for you
(BTW, be sure to type some gibberish into the provided box and hit submit, so you can see why I think this is a very relevant link.)
c. You agree to pay $ 100,000 for your use of the Estatis Free Password Security Checker if we ever ask for it.
oh dear.
These people can be very very very evil.
Well that's lovely. Just changed my LinkedIn password so hopefully no one had a chance to take advantage of that. Luckily I very recently switched to a new password scheme so my other accounts should be secure too.
I've changed it anyway on linkedin.
Damnit, LinkedIn.
https://github.com/hungtruong/LinkedIn-Password-Checker
I wonder what kind of bonkers executive at LI decided it would not be a good idea to do a sweeping wipe of all passwords on their systems...
(note to LI: this isn't real code; don't use)Though I doubt any of the above will happen. Wouldn't want the user to be inconvenienced now would we?
A large forum I post on was hacked recently and - after voluntarily shutting their site down for a month - they required password resets. If users did not have access to the email address they signed up with and couldn't otherwise verify their identity, they were not allowed to get their account back.
Unsurprisingly, post counts are down site-wide and the owners have reported a > 25% decrease in traffic.
Of course all of those things can be used to gain access to the account by attacker, without actually knowing the password. See recent Cloudflare incident. Google will notify you about the recovery attempt, monitor for activity, and delay it for at least a week or so. So the attacker just have to wait till you go on offline vacation ;)
Really though, for something as low key as a forum you’re entirely justified to offer recovery only via email. The email providers already offer all those alternative recovery options. And of course you should prefer OpenID to avoid the issue altogether.
> Unsurprisingly, post counts are down site-wide and the owners have reported a > 25% decrease in traffic.
That’s because they took the site down for a month!
Though, think of how much easier it would be to social-engineer a target were you to have full access to their LI account.
Yes, I've read http://partmaps.org/era/unix/award.html#cat . The output of sha1sum already contains a trailing '-' which is something I wanted to feed into 'grep' using command substitution, so that 'grep' can now just accept the input stream from 'stdin'. Now, how do you feed the input to grep via 'stdin' if you don't want to use 'cat'?
https://github.com/rpicard/misc-perl/tree/master/linkedin-pa...
"Why don't you just tell me your password..."
http://crackedin.s3-website-us-east-1.amazonaws.com/
And it's hosted on S3 so it is faster :)
(easily downloadable == not the rapidshare of russia, something you could wget)
But I submitted the hash of my password and it's there so...
here: http://www.seedpeer.me/download/linkedin_hashes/ad1e93a1aee2...
Click download, copy the URL from your browser into wget/axel/download manager. I get a solid 1mb/s from media fire.
(However, could everyone please stop making random websites encouraging people to type in their passwords from third party sites!)
for example this tool says the word "test" hashes with the last 5 digits of 77136 where as leaked in translates the word "test" to fbbd3. hmmm