193 comments

[ 3.2 ms ] story [ 254 ms ] thread
You should add a note on the page that lets people know that checking a password takes a minute or two.

EDIT: Actually never mind, seems like it's much faster now.

Yeah. We got hit pretty hard. It doesn't actually take a minute or two, unless you're doing a few hundred at the same time. Fixing. (-:
Can you confirm you're not logging/recording the hashed passwords?
We can tell you we're not, but that doesn't actually confirm anything. (We're really not, though.)

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.

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.)

(comment deleted)
You're confusing "not on the list" with "not in the hacker's possession".
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).

Don't all the hashes listed have "c3dxxxxx" at the end. They to me, at a glance, look like a partial.

Head:

    00000fac2ec84586f9f5221a05c0e9acc3d2e670
    0000022c7caab3ac515777b611af73afc3d2ee50
    deb46f052152cfed79e3b96f51e52b82c3d2ee8e
    00000dc7cc04ea056cc8162a4cbd65aec3d2f0eb
    00000a2c4f4b579fc778e4910518a48ec3d2f111
    b3344eaec4585720ca23b338e58449e4c3d2f628
    674db9e37ace89b77401fa2bfe456144c3d2f708
Tail:

    00000e585039977da2b9c4f28fc418b8c3d2d599
    a0cad23ffd750e306bd7be8cc695d2e6c3d2d67b
    d338c29d3918574f256fc0be597d2ee0c3d2d891
    00000ad7316592e01ce0aab1cc4339b1c3d2de0d
    00000c682336158bfcd57edfe4fab7acc3d2de28
    00000d77a7b62838c5f721b30e6ee8ecc3d2deb9
    00000def8fc887cd8e910823e98ae509c3d2dedc
No, just a bunch at the top and at the bottom. Just 1570 out of the 6 million. (I did: grep 'c3d.....$' SHA1.txt |wc -l)

It's not clear to me how the file was sorted. Anyone have any ideas?

Exactly, because the hacker only posted the passwords he neede d help with.
My autogenerated password was not on the list. It was generated back in late 2010.
My password of vhuwirbqr83fh83f was also not on the list
One suggestion: make the input box have a type of 'password'. I was only a bit put-off by seeing my plaintext password staring me in the face!
Probably a good thing since it makes you think twice about submitting your plain-text password to an unknown entity.
I think its safer to test yourself than randomly typing your password in on websites =)
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.
'password' was actually in use - go figure.
So was mypassword and others. Oh well.
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?
I think it'd be best to provide people with a simple way to generate their hash with a well-known tool they already trust - eg, an openssl command.
For the record, on a Mac, save your password in a text file called password, without a return at the end of the line. Then:

openssl dgst -sha1 password

will give you the hash you need. Mine has been leaked but not cracked, according to this site :-(.

Or...

   echo -n "password" | openssl dgst -sha1
Not like they couldn't save it as a variable if they wanted. That's just what you see in the UI.
Now there's a great idea! Provide your password to some random site purporting to check if your password's been compromised.
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.
Again, you can check the source. It's a single page for a reason ;-). There's no trickery hidden in there.
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.
Which is why you use different passwords on different sites.
Maybe no trickery hidden in there now, but that could change any time. Or sometimes. Or depending on IP, browser or OS.
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…
What would be good is to have the 'checking request' return a json (or just a short info) and not a whole html
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.
If the hole that let them in hasn't been closed yet, changing the password will make that password vulnerable, right?
Just change your password before checking. You should've had already, anyway.
My password is 'password1' and it's on that list... Yikes.
You guys have no sense of humor.
hunter2
(comment deleted)
correct horse battery staple.
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

Your post reminded me of that.

In other news I have a startup on credit card security

Just submit your credit card number, CVV2 and expiration date and it'll check if it has been stolen over the internet for you

Oh, I think I know you. You're that Nigerian prince I keep getting emails from, right?
Will you be directing the form submission page to a static HTML page reading "Yes"?
If you don't particularly trust the included click.js script, you can generate your password's SHA-1 via python fairly easily

   python -c 'import hashlib; print hashlib.sha1("PaSSw0rd").hexdigest()'
or easier and shorter:

   printf PaSSw0rd | sha1sum
Or call shasum or sha1sum and input your password on stdin so your shell history doesn't contain your password in plain text.
Just pop a space at the beginning and it won't go into shell history.
It does for me

  >  echo test
  test
  > history
  ...
  6730   echo test
  6731  history
Set this in your .bashrc

  HISTCONTROL=ignorespace
Or even better, though unrelated to this topic... Also get it to ignore duplicates that come next to each other.

  HISTCONTROL=ignoredups:ignorespace
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.
it will still be in ps output for a short while...
Ultra paranoid. I like the way you think.

    python -c 'import hashlib; from getpass import getpass; s = hashlib.sha1(); s.update(getpass()); print s.hexdigest()'
how do you get rid of the carriage return as last char that way?
Use Ctrl-d to end input without hitting return and you shouldn't get a newline.
bash, at least, only handles Ctrl-d on its own line.
If you're not on a new line, you can type Ctrl-d twice.
What if my password contains % characters?
Yeah, note that this doesn't work with all password combinations. I just use the Python version above

  python -c 'import hashlib; print hashlib.sha1("reALpassWORD12%12").hexdigest()'
and then:

  history -d $((HISTCMD-2))
to delete the last entry in the bash history.
Add a `from getpass import getpass` in there, replace your password with `getpass()`, and you'll be set :)
http://www.inutile.ens.fr/estatis/password-security-checker/

(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.)

The Terms and Conditions are hilarious:

c. You agree to pay $ 100,000 for your use of the Estatis Free Password Security Checker if we ever ask for it.

"All States shall be entitled to lay submarine cables and pipelines on the bed of the high seas."

oh dear.

That's the Geneva convention. It's right after a chapter of Frankenstein.
Is that a Masonic Chapter? Did that happen before or after they started the alamo?
Bonus points for those who submit, read what it presented then proceeded to test another password!
They got me a second time with "Test another password?"
They have a bug. Type a " character and it gets encoded with a backslash in the output.
This is fixed. Thanks :-).
I assumed this website was a joke. I'm surprised it isn'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.'

These people can be very very very evil.

I like to social engineer my 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..
(comment deleted)
"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.
My autogenerated password was in the list, and not cracked.

I've changed it anyway on linkedin.

Same for me. "Your password was leaked, but it has not (yet) been cracked. Fingers crossed."

Damnit, LinkedIn.

The site should tell people to change their password anyway regardless of whether it's in the list or not.
We need a "wasmylinkedinpasswordleaked.com" with <h1>yes</h1> as the content.
haha, quite funny. I made it.
I don't think a Like button was in the original charter.
(comment deleted)
I quickly wrote a script to do this locally, not the most efficient, but I'm at work ;)

https://github.com/hungtruong/LinkedIn-Password-Checker

That works pretty well. And yes, my password is in there.
Thank you. Worked for me as well...

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...

    for user in users:
      force_pw_reset(user);

    def force_pw_reset(user):
      user.pw = rand;
      user.sendResetEmail();
(note to LI: this isn't real code; don't use)
Now just send phising emails with fake reset links to your targets at the same time. Password reset should be enforced at first login.
Ah yes, didn't consider that...you are correct--reset should be forced on login.

Though I doubt any of the above will happen. Wouldn't want the user to be inconvenienced now would we?

Wait till it gets more publicity.
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.
True, password re-use is a big problem.

Though, think of how much easier it would be to social-engineer a target were you to have full access to their LI account.

(comment deleted)
(comment deleted)

  $ cat combo_not.txt | grep `printf linkedintrouble | sha1sum`
  3ac85868a20c977661a12f770f0d116f87c74831
  $ cat combo_not.txt | grep `printf nathanlinkedin | sha1sum`
  a4d28368130ad555c77ec6a4dd18b8977ac0f589
  $ cat combo_not.txt | grep `printf mypassword | sha1sum`
  $ cat combo_not.txt | grep `printf yourpassword | sha1sum`
  $
printf linkedintrouble |openssl sha1|grep -f - combo_not.txt
This doesn't work, because:

  $ printf linkedintrouble | openssl sha1
  (stdin)= 3ac85868a20c977661a12f770f0d116f87c74831
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'?

BTW, the commands involving 'openssl' can be fixed in this manner.

  $ printf linkedintrouble | openssl sha1 | cut -c10- | grep -f - combo_not.txt 
  3ac85868a20c977661a12f770f0d116f87c74831
does your grep have an -f option?

   printf linkedintrouble |sha1sum |sed 's/ .*//' |grep -f - combo_not.txt
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.
(comment deleted)
I think its interesting to see what kind of passwords were in there. "password" was of course in there, "password1" was not, "password2" was....
Genius. LinkedIn needs more of you apparently.
There is a tracking service on the results page keep sending out everything you've just submited.
You could use the service to see if your new password was already hacked..
Somebody had the password test123. Lol. I'm going to go see what other crazy simple passwords people have used.
"binladen" was actualy used for a password at linkedin lol!
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?
Reminds me of the Seinfeld/MovieFone episode...

"Why don't you just tell me your password..."

I made something almost the same (including name!), except all check is done in browser:

http://crackedin.s3-website-us-east-1.amazonaws.com/

And it's hosted on S3 so it is faster :)

I just wanted the list in an easily downloadable format so I can check offline

(easily downloadable == not the rapidshare of russia, something you could wget)

But I submitted the hash of my password and it's there so...

(comment deleted)
www.mediafire.com/?n307hutksjstow3

Click download, copy the URL from your browser into wget/axel/download manager. I get a solid 1mb/s from media fire.

Interesting implementation, but won't this eat up a lot of bandwidth and cause a high S3 bill?
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.
Probably a noob question but... How does this account for any salt that may have been used?
It doesn't, LinkedIn didn't salt the passwords.
LinkedIn didn't use a salt. Hence the easier-than-it-should-have-been password crackfest.

(However, could everyone please stop making random websites encouraging people to type in their passwords from third party sites!)

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.
i observed it seems this tool and the leaked in one don't agree on the resulting hash value from the same word.

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

Thanks! I've changed it now. Seems i didn't catch the key event properly. :-)
(comment deleted)
(comment deleted)