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.
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.
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…
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.
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.'
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.
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
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.
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.
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..
Tangencially related to some of the comments in this thread.
Amahi (my startup) started experiencing lots of spamming accounts a little while ago. We started using blacklists and some heuristics to detect the spammers. Then we logged the attempts.
Some interesting things emerge.
* The vast majority of them have "super123" as the password
* The vast majority use emails from china (163.com, qq.com, etc.)
* They try twice in a row if the first attempt fails
* They try regularly
The suspicion is that they then sell these accounts in bulk for later action. We have seen them have these accounts sitting idle, with occasional logins to check if they still work. Then later they pounce, posting spam links, etc.
The level of sophistication of all this is rather troublesome ...
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?
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).
"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.
Brilliant. Next time I want someone's password I'll create a page similar to this ("check if your password was leaked!") and pretend to spam my entire contact list while my target is really the only person receiving it.
No seriously, how in the world can we trust this website with our password? They don't even claim to keep your password a secret. For all we know this is a follow-up scam to extend the 6.5mil hacked hashes.
Having a very quick glance at the HTML source, it seems they hash it before it's sent to the site to check, but it easily might have been a scam. Or turn into one with a probability of 1 in 10, that still gets them many passwords while remaining to be trusted.
I wish I could down vote or delete this article. Regardless of the creator's intentions, there are a lot of non-techie people on HN (like one of my co-workers) who used this site to check their linkedin password. It reinforces fatal security habits.
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'm really enjoying testing completely silly passwords against the leaks.
'pooppants' is a confirmed hit. "World's Largest Professional Network". I like to imagine some suit with a cigar logging into look for new hires with that one.
If your hash is not on that list, it's bad news. There are indications that the hacker published only the hashes he needed help with. The others were more easily decoded.
It is helpful to have a unique password for each meaningful service you use. That way the black-hats can't compromise your other accounts using the same password.
My (previous) password was randomly generated, and it was on this list. Fortunately I had already changed it when I read about the breach earlier on Wednesday.
huh, I have a linked in account that I don't check often and my password was on that list. Luckily it was specific to linkedin. I don't believe this is just a small percentage of users. Oh and I never received an email like the blog states (http://blog.linkedin.com/2012/06/06/linkedin-member-password...)... odd...
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?
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.
Sorry, I don't mean to be harsh, but this concept is pretty much dead on arrival.
"Check if your hash is still private and secure by sending us your hash."
Well, even if the hash was secure, it isn't now!
(Unless you:
O get the whole database into the client
O ask the user to:
o reload the URL in PRIVATE browsing mode
o DISCONNECT from the network
o test the results with javascript
o close the whole browser
o reopen the browser
o finally, clear flash cookies (how do I even do that?)
o Only then reconnect to the network
All to prevent you from either reading the results afterward or, as regards instructions to disconnect from the network, somehow changing or making a mistake in the javascript, perhaps after we or others have verified and ok'd it.)
If the only answer to the objection against giving you the hash is that you don't ask for the username, you might as well ask for the password plaintext.
Sorry, the concept is pretty much dead on arrival.
Still, way to ship. (or 'nice shipping.' Should be our secret handshake :). Good luck on the next concept.
You should consider the password and hash that you test as already compromised and in the wild, thus making this app just a simple convenience for you and other linkedin users.