Lessons Learned From Cracking 2M LinkedIn Passwords 198
An anonymous reader writes "Qualys researcher Francois Pesce used open source password cracker John the Ripper to try to crack SHA-1 hashes of leaked LinkedIn passwords. He ran the John the Ripper default command on a small default password dictionary of less than 4,000 words. The program then switched to incremental mode based on statistical analysis of known password structures, which generated more probable passwords. The results? After 4 hours, approximately 900,000 passwords had been cracked. Francois then ran numerous iterations, incorporating older dictionaries to uncover less common passwords and ended up cracking a total of 2,000,000 passwords."
Do not use standard passwords (Score:5, Insightful)
Surely this is not news.
Re:Do not use standard passwords (Score:5, Interesting)
The problem is, even passwords that would have been considered "non-standard" 5 years ago is now easily crackable - according to GRC, a password I used 5 years ago consisting of ten characters, alpha numeric, mixed case and a symbol would take just an hour or so to crack. That was quite eye opening.
So what next?
Re:Do not use standard passwords (Score:5, Informative)
So what next?
Two factor authentication.
Re: (Score:3)
Well there's two ways here, online and offline cracking. I imagine LinkedIn has some kind of policy to stop people doing millions of authentication attempts online. If they get the PW from linkedin and can crack it offline then IMO linkedin's security has already failed. If you can get the passwords the hacker can probably get most anything else, so it's just damage control - don't reuse the password on anything you care about. In fact it's a bad idea anyway because you've no idea if someone with legal acce
Re:Do not use standard passwords (Score:5, Funny)
What an excellent opportunity! I just told everybody on my LinkedIn account what I *really* thought of them, waited an hour, and told them all my password was hacked. Good times, good times.
Re:Do not use standard passwords (Score:5, Funny)
Yeah, me too. I told my brother that stealing my girlfriend in the 8th grade was a shitty thing to do and he should stop getting drunk in bars. Then an hour later I told him my account was hacked and that wasn't me who wrote that.
Re: (Score:2)
Re:Do not use standard passwords (Score:4, Funny)
I heard he left her... (Score:4, Funny)
Re: (Score:2)
When you can down load the whole password file and brute it off line, its just a matter of time. Time to wait for tech to get better and time to press the big red go button to run the code on the bit of fast(n) tech.
So type in a password you couldn't possible recall and each and every time you want to go back to the site - request a new password. This ma
Re: (Score:3)
Mine defaults to even for sites that I'll never visit again I have as standard 26 character upper, lower and symbol passwords that I don't have to remember. All I need to know is the passphrase, something like "0nLy 1 Know Thi$ pA$$phrase!" or "mmm pizza". Makes no odds, you still get a 26 char PW that has Ul$ in it.
I know a lot of people don't use Firefox, but this really is a killer extension.
Re: (Score:2)
[blockquote]So what next?[/blockquote]So assume your password is going to be compromised eventually (the bigger the service, the greater that chance approaches 1), use a different, randomized password for each website, and rely on "forgot your password?" links for when your browser's cookie times out.
For most websites, the "forgot your password?" link + checking your email takes less time than trying to guess if that was a capital P or lowercase p in "p455w0rD".
Re: (Score:2)
trying to guess if that was a capital P or lowercase p in "p455w0rD".
As an aside, most capable crackers test for "leet" (7334) substitutions very early in their permutation rules. The word "password" is at the top of every dictionary file and is always included in the "top 100" password lists that crackers frequently expose to more detailed permutations.
This password is almost as weak as using a somewhat obscure dictionary word like "flagellate" or "dismember". (those words may or may not have been carefully chosen)
Re: (Score:2)
As an aside, that password was a joke. *woosh*
Re: (Score:2)
Re: (Score:2)
What next? You use 15 or 20 character passwords, or a passphrase of several words.
But for the server side, use key strengthening with something like bcrypt or scrypt.
If it takes 1 second on very fast hardware to hash a single password, then your attacker has to also spend a lot of time on each hash attempt.
scrypt was also designed with custom hardware attacks in mind (it uses lots of memory) so it is still slow and expensive even if the attacker has key derivation logic in an asic or fpga.
If it takes a tent
Re:Do not use standard passwords (Score:5, Insightful)
Salting doesn't stop brute force crackers like JtR, it only stops attackers from using a rainbow table and/or discovering that two people have the same password.
The real lesson here is just because your password database is hashed (with or without salt) doesn't mean you should let just whoever download the thing.
Re: (Score:2)
If they don't know your salt (code based) and you don't allow people to do multiple login attempts on your site, it does effectively stop brute force attacks at your passwords even if your salted hashes get out in the open. Still not the best idea to give out your database.
Re: (Score:2)
Re:Do not use standard passwords (Score:5, Informative)
If you have a salt in *code* (I presume a static one), I would wager it would be easy to discern. A salt is not supposed to be 'secret', it's just supposed to prevent easy identification of common passwords and a simplistic rainbow table attack.
Now if each client had a machine generated salt to append before transmit to server, that actually is servicable. Of course, the standard practice of complete obfuscation of the password through local algorithms is better.
Re: (Score:2)
If the salt used is not part of your password's hash, you're doing it wrong. Salts should be unique per user, not site-wide.
Re: (Score:2)
The salt I'm talking about is unique per user. The difference is the salt generating algorithm is in the code and not known.
Re:Do not use standard passwords (Score:4, Informative)
Salt: a random per user number (not an algorithm) used to foil attacks like rainbow tables.
Signature: an algorithm that authenticates a message (like a password).
Typically any secret algorithm is considered security by obfuscation.
So a "salt" generating algorithm would be an obfuscated pseudo-random number generator used in a non-standard way as non-cryptographically secure signature. Yeah, that's the ticket to good security ;^)
Re: (Score:3, Funny)
The real lesson here is just because your password database is hashed (with or without salt) doesn't mean you should let just whoever download the thing.
Genius. Pure genius. I hope the NSA snaps you right up. It's people like you with keen intellects that can come up with such a conclusion (that no one else has ever even considered) that will save this great nation of ours. Thank you. Thank you.
I'm going to go and change my setup so that my password databases aren't visible to the Internet anymore. It's just incredible. Are you the result of a Mensa genetic engineering experiment or something?
Re:Do not use standard passwords (Score:5, Informative)
Salting doesn't stop brute force crackers like JtR
Salting doesn't make brute force crackers impossible, but it makes brute force much, much less effective. If I have two million unsalted passwords, I just need to compute a hash for a dictionary word one time and then do two million string comparisons. If I have two million salted passwords, then I need to hash the dictionary word two million times. That is far, far more time consuming.
Re: (Score:2)
f I have two million salted passwords, then I need to hash the dictionary word two million times.
And if the salts were different on every password were secured separately from the password list, you'd have to try and deduce the salt first, two million times.
Re: (Score:2)
if the salts were different on every password
If it's not then it's not really a salt.
if the salts...were secured separately from the password list
That's not really feasible. Presumably if they have access to the passwords they also have access to the salts. In the end the legitimate application requires access to both, so if they've compromised the application they can probably get both.
Re:Do not use standard passwords (Score:5, Interesting)
That's not really feasible. Presumably if they have access to the passwords they also have access to the salts. In the end the legitimate application requires access to both, so if they've compromised the application they can probably get both.
It seems perfectly feasible to me.
1) A part of the salt is static and hidden in application code. This means even in the DB of salts is compromised, deduction of the missing piece is still required (as well as knowledge of its existence).
2) In a example setup there are three servers, the Application/Authentication server that is accepting login requests (Server A), the Database server hosting the DB of password hashes (Server B), and the Database server hosting the DB of the password salts (Server C).
3) The servers are configured so that Server A can communicate with the outside world and servers B and C. Server B can only communicate with Server A. Server C can only communicate with Server A.
In this setup the only server than can be remotely compromised is Server A which does not have direct access to either the list of hashes or the list of salts. In order to get this information an attacker would have to take control of Server A and query both databases, one record at-a-time. The search/index key in both databases would be the username, so the attacker would also need the complete list of usernames as well.
Now, I dreamed up this scenario in about 5-10 minutes. Please explain why it's unfeasible and assume security is high priority consideration.
Re: (Score:2)
A part of the salt is static and hidden in application code. This means even in the DB of salts is compromised, deduction of the missing piece is still required (as well as knowledge of its existence)..
This is already common practice and has nothing to do with what you're talking about. I will therefore ignore it :D
In a example setup there are three servers, the Application/Authentication server that is accepting login requests (Server A), the Database server hosting the DB of password hashes (Server B), and the Database server hosting the DB of the password salts (Server C).
It all comes down to cost. Having a dedicated database that just holds either the hash or the salt is definitely more secure, but you're paying a lot of money for something that only really protects against SQL injections. If they've already compromised server A or if it's an internal leak, then they'll still have access to both databases.
If properly stored with a strong hashing algorithm,
Re: (Score:2)
do two million string comparisons
Naw man, not even that. You could use a trie [wikipedia.org] and perform a single search across any number of strings in O(n) time relative to the length of the string with early bailout when the string you are attempting to match diverges from the set you are matching. You can even do some optimizations on your trie after it is built so that the leaves contain the unique "tails" of strings.
OR you could even use a hash table and do the lookup in amortized O(1) time
Very very fast indeed to match your gusses against a set of
Re:Do not use standard passwords (Score:4, Insightful)
Re: (Score:2)
Worse than that, without salts you can precompute the hashes (eg rainbow tables) and do subsequent attacks far more efficiently against anyone using the same hash type (and unsalted md5, sha-1 and ntlm are extremely common making it well worth the effort of generating tables)...
Tables can be (and often are) shared, thus distributing the required hashing power across a much larger pool of resources.
Re:Do not use standard passwords (Score:4, Informative)
Salting doesn't stop brute force crackers like JtR, it only stops attackers from using a rainbow table and/or discovering that two people have the same password.
Both of those latter things are significant risks. However, it also substantially slows down brute-force crackers when applied to large password lists.
If you apply a brute-force cracker to a list of, say, a million unsalted password hashes, then you need to only compute the hash of each potential password once and compare the result against all million hashes. With a reasonably good in-memory storage system for the hashes, nearly 100% of your time is spent computing hashes (and not in comparison or password generation). So, with unsalted passwords, cracking a million passwords is as fast as cracking one (but much more lucrative).
With salted passwords, you need to compute the hash of each potential password for each entry in the hash list (since they all, ostensibly, have different salts). So you need to compute a million hashes in order to check one possible password (for the whole list). That is a substantial slowdown. With salted passwords, you are essentially cracking every password in a list separately -- having a large list gives you zero speed benefits.
If a factor of a million slowdown doesn't seem like much, consider that many good password-based encryption system use key strengthening, where the password (and salt) are passed through many chained rounds of hashing. Roughly a million, on modern processors. The whole purpose of this is to slow down brute-force password cracking by increasing the cost of a guess. It's enough of a change that instead of being able to get through a very large keyspace in a reasonable time (with only one hash round), you're stuck only being able to crack very bad passwords (with a million hash rounds). That's a very significant difference.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
gpg (Score:5, Interesting)
gpg - --gen-rand 1 9 | gpg -cat > linkedin.asc
And presto, 72 bits of sweet entropy in your password which you don't even need to remember. It suffices to remember ONE password.
Need your linkedin password?
gpg linkedin.asc | xsel
(and type your one password).
Note that this way your linkedin password is never typed and never shows up on the screen.
Re: (Score:2)
By simply remembering the site name and a strong master password, one can generate a unique password for each site.
Re:gpg (Score:5, Informative)
http://hashapass.com/ [hashapass.com] have a bookmarklet. Not completely auto, you still need to write in a keyword for the site, but still.. Does a good job.
Re: (Score:2)
A similar (commercial) concept is available on Windows, Mac, iOS, and Android: 1Password. Browser plugins are included, and it works quite well.
Sadly, there is no LInux/BSD version - but there is a browser-based '1passwordanywhere' that makes it possible to use it with any web browser - I'm not sure exactly, but I'd wager it's javascript kept in the password database.
The datastore is supposedly fully-documented - nobody has written a native Linux client yet, but one can hope...
Value of a linkedin account (Score:3)
What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success. If you poison enough of the well, the whole data set becomes worthless so you can't threaten to modify data. Maybe they tried to extort money from linkedin inc and failed so they released purely by spite? Post IPO = the titanic has been struck by the iceberg and you've already gotten away, so it doesn't matter how fast the ship sinks, therefore no point in paying extortion fees?
Assuming only a fraction of accounts have been stolen and not the entire user list.... Why do people assume its only a tiny fraction and not the whole list of users? The same people who don't understand the concept of a "salt" must surely be correct when they say only a couple million records are out there. I would assume based on their heroic security performance to date, that ALL records are out there, we just only know about a couple.
Re:Value of a linkedin account (Score:5, Insightful)
It probably has little value, but the account name is an email address. Many people use the same account/pass combination for multiple sites, including perchance their paypal account. If they manage to pull a few million email/password combos from linkedin, I can guarantee you that some of those combinations will match paypal exactly.
Re: (Score:2)
Re: (Score:2, Informative)
Instead of faking facebook accounts, someone could steal a real linkedin account to do the same:
How spies used Facebook to steal Nato chiefs’ details
NATO'S most senior commander was at the centre of a major security alert when a series of his colleagues fell for a fake Facebook account opened in his name - apparently by Chinese spies.
http://www.telegraph.co.uk/technology/9136029/How-spies-used-Facebook-to-steal-Nato-chiefs-details.html
Re: (Score:2)
What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero.
Because people have been known to reuse passwords on other sites that might have a non-zero value.
Re: (Score:2)
A very easy way to profit is to release the stolen account data waiting for the negative press to push the stock down.
Re: (Score:2)
What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success.
Many people, especially younger people, have a unique weak password. So if you've their login and their password, chances are you can also access their Facebook account, their paypal account, their bank account, etc.
Re: (Score:2)
What is the value of a random persons stolen linkedin account... I'm trying to figure out how its not zero. I have a pretty devious mind but I can't think of any way to make money off this with a reasonable chance of success.
I'm trying to figure out the value of an active LinkedIn account. Seriously, does anyone know of anybody who got hired thanks to linkedin ?
Did he crack any random passphrases? (Score:5, Funny)
Like "correct horse battery staple"?
Think of the poor crackers. (Score:3)
"IfYouCanReadThisYou'reTooCloseToMyPrivats".
"PrivacyIsDeadDon'tYouAgree".
"YouWin,NowFckOff".
"BeingParanoidDoesn'tMeanNobodyIsReadingThis".
Re: (Score:2)
I've been running them through my own cracker (doing so helps me to find new patterns I can use to audit our passwords at work). Almost 3 million cracked so far. No "correct horse battery staple", but getting there.
I'd still go with at least a 10 character computer-generated random password with a mix of all character types.
Length Password
40 1234567890123456789012345678901234567890
24 sociological imagination
24 linkedinlinkedinlinkedin
23 newlinkedinpassword1234
22 harekrishnaharekrishna
Re: (Score:3)
That one is not in the file. However CorrectHorseBatteryStaple hashes to a9cb82349d8c4f9aa4ba3210fadde81049300d0b, which is in the leaked list of hashes. That means either:
And if the hypothesis about the first five characters in the file having been overwritten on those entries that were cracked already is true, this means this one was not
Real lesson -- make guessing expensive! (Score:4, Insightful)
The predictable whining (and obligatory xkcd rebut) will be to make passwds "stronger", because open hashes or fast guessing is acceptable provider security.
I call BS! More "blaming the victim". Any secadmin/netadmin who has hashes available or allows unthrottled passwd guessing is INCOMPETANT. Staff are paid for professional-level knowledge so users do not need to be concerned.
The work itself is very nice, MD5 hashes can be cracked quickly in massive parallel on GPU hardware. This only matters after the hashes have already been stolen.
Practical security should be more systemic -- the cost of a wrong guess is more than a nanosecond of GPU. There are at least network delays, and in many cases lockouts. The latter make random guessing too costly/slow, especially progressive systems that allow 5 wrongs immediately, 10 in an hour, 20 in a day, and lock hard (manual intervention) above that.
My father had one of the early ATM cards but had me operate the machinery. It had an 8 digit assigned PIN, but dropped quickly to 4 when it was realized the 8 were hard to remember, and swallowing the card after 3 wrong guesses was more than adequate.
Re:Real lesson -- make guessing expensive! (Score:4, Insightful)
What the hell are you talking about?? The problem wasn't the hashing - SHA1 is perfectly strong - it was the lack of salting, which makes attacks like this one possible. And "unthrottled passwd guessing" might be "incompetant" but preventing it doesn't do you a lick of good if you're testing against a list you downloaded.
Yeah, they screwed up. They shouldn't have allowed the password hashes to be compromised, and they should've salted the hashes so they would be essentially worthless if compromised, but that doesn't negate the value of a strong password.
Re: (Score:3)
While the issue was clearly not the hash algorithm here, it should be noted that SHA-1 is now effectively broken [schneier.com] - you can get collisions in less time than using brute force.
It's still a perfectly usable hash algorithm, but it has been slowly phased out for SHA-2 (SHA-512) for some time now.
Re: (Score:2)
Well, yes... I was being hyperbolic about SHA-1. The reason JtR is making headway is because the hashes are unsalted, not because the hash has problems. But if I understand it, doesn't salting even help with a weak hash? Given the hash of the password, you can perhaps find a colliding cleartext (is that the name for the input string?) in faster-than-bruteforce time but if you don't know the salt it doesn't help you because you can't completely control the input.
Re: (Score:3)
While SHA1 is broken, I doubt it makes much difference here.
Per your link, you can find collisions in SHA1 with 2^69 hash operations per password.
The people doing the cracking here did CONSIDERABLY fewer operations per password than this.
Sure, everybody should be moving on, but the fundamental issue here is that passwords that people can remember generally don't have enough entropy.
Re: (Score:2)
SHA-1, like MD5, is broken for digital signatures. When someone finds a way to reverse a hash back into a password, then it will be broken for passwords.
The only real argument against SHA-1 for passwords is that you can brute-force them rather quickly, but SHA-2 has the same problem. If this is an issue for you, use PBKDF2 or some similar algorithm.
Re: (Score:2)
As another reply commented, SHA1 is not "perfectly strong". And yes, salting is an easy assist to hash security. And yes, strong passwords have value, the problem is the human cost. Don't you evaluate user costs?
Unprofessionalism (in IT and elsewhere) transfers costs from the incompetent to users/customers. Of course some costs have to be transferred. But they have a cost-benefit including user costs. Even competent management [rare] will have trouble catching mistransfers because the diffuse user commu
Re: (Score:3)
Yes, but modern GPUs can compute SHA-1 hashes of various passwords at enormously fast rates. Even if they used per-user salts, it's likely that they would also be acquired during the original compromise: with the salts being known, the attacker could run through the various password possibilities at a high rate of speed.
Using just a plain hashing algorithm, even one like SHA-512, for password security is a bad idea as those hashes are designed (in part) for speed. Using something like PBKDF2 with a high num
Re: (Score:2)
Yes, but modern GPUs can compute SHA-1 hashes of various passwords at enormously fast rates. Even if they used per-user salts, it's likely that they would also be acquired during the original compromise: with the salts being known, the attacker could run through the various password possibilities at a high rate of speed.
Yeah, just TWO MILLION times slower.
Re: (Score:2)
Re: (Score:2)
And you mispeled "incompetant".
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I haven't heard much of online cracking being an issue because of what you said; one simply can't effectively attempt many passwords without causing a DoS.
"The work itself is very nice, MD5 hashes can be cracked quickly in massive parallel on GPU hardware. This only matters after the hashes have already been stolen." This part is true.
Locking dow
slashdot (Score:5, Funny)
own up, who used the password slashdot - 0000003627a75d6c96a3d965247584a78779bc3d
Opportunity! (Score:2, Funny)
Send me your password and I will verify that
-No one else is using it
-It is safe
BONUS: If you send me your credit card information I will tell if you if it's lucky!
THANKS,
"HAPPY DUDE"
742 EVERGREEN TERRACE
"Rules" ? (Score:2)
Let me admit upfront, I've never explored the world of password cracking. However part of the article doesn't make sense to me. He mentions password based on rules. However he listed the rules and it seemed really strange.
pwdlink from pwlink with the rule "insert d in 3rd position"
pwd4link from pwdlink with the rule "insert 4 in 4th position"
pwd4linked from pwd4link with the rule "append ed"
pw4linked from pwd4linked with the rule "remove 3rd char"
pw4linkedin from pw4linked with the rule "append in"
mpw4l
Re: (Score:3)
I'm not an expert, but basically you want to generate a large search dictionary. You start with a small one (like the english dictionary), and then apply rules to generate more words to search. The kinds of rules you listed are typical, and you start applying them individually, and in combination. So, if you have 1000 words, and 10 rules you apply individually, you end up with 10k words. If you allow permutations of 10 rules then you have 1k*10^10 or something like that (depending on the rules order may
Re: (Score:2)
If all you need is one chances are you just need the word "Password".
FTFY
Real lesson: some web devs should be out of a job (Score:2)
Without offline cracking, password weaknesses aren't very exploitable (even the most inept server will shut you down after a couple hundred attempts at brute-forcing your way through an online login).
People like to harp on those "idiots" who pick weak passwords that can be cracked with a rainbow table, but unlike the moron web devs who still fail to salt their password DB in 2012, yo
Re: (Score:2, Insightful)
Why is it the devs who get the short end of the stick in most 'xyz should be fired!' comments in this topic?
I've worked at several places (in QA) where the devs were perfectly aware that there were security weaknesses (usually a result of some small system that organically grew into some big web service - but never was designed to be a big web service) - but until something is on fire (read: bad press), management tends to not prioritize highly needed refactoring (lets not argue over what to call it) over n
two factor authentication (Score:3)
SMS to phone
coming to a computer near you, for everything
SMS to phone. (Score:2)
I barely trust most web-service providers with an email address that can be closed/blocked/changed with little cost or effort. Satan will skate before I start giving out my mobile number!
Re: (Score:3)
then you aren't doing any banking or using Craigslist
I don't use facebook but I believe they are doing phone authentication now too.
It's coming for all sites, I'm sorry. It's good for security, I believe.
Re: (Score:2)
Facebook might be doing phone authentication, but they're not forcing it (yet), and I sure wouldn't trust FB with my phone #.
Re: (Score:2)
Satan will skate before I start giving out my mobile number!
I do believe they have roller-derby in hell... so I guess zentigger will be sharing his or her mobile number soon!
On a serious note... I thought that was a clever euphemism for "when hell freezes over".
Re: (Score:2)
satan does skate:
http://en.wikipedia.org/wiki/Tonya_Harding [wikipedia.org]
Re: (Score:2)
SMS to phone
coming to a computer near you, for everything
I have a wireless service that doesn't seem to work with anyone's SMS notification system, and I assume my provider's not the only one like this.
Re: (Score:2)
I strongly dislike SMS two factor, as smartphones are just as easy to get trojans/loggers on as PC's. Keyfobs work better, but then there's the possibility of the source+keystore being stolen. But at the end of the day both are more viable options than a simple password. Most people have cellphones, I don't but for anything important I already have a fob for it.
no to fobs (Score:2)
1. it's hassle for the company. you have to send to the customer, deal with customer service inquires for new ones/ lost ones, etc. it's now a logistics headache
2. it's a hassle for the customer. i have one for banking, and i'm always misplacing it, not having it when i need it, etc. just one more thing to keep track of in my life i don't want to. and a different fob for every important relationship? I have to carry around a jangle of fobs? Or leave them someplace and I can only do my banking there? No than
Some more important questions (Score:4, Insightful)
We all know that people tend to choose weak passwords, this is not really newsworthy. Ever since the database was leaked, many people, including professionals, have performed various analyses of cracked passwords. This is fine, but I think there are more important things we need to know right now:
1) When exactly was the database leaked? It seems that it's been floating around the internet for some time before it hit the news last week.
2) What the attack vector was?
3) What security measures have been taken by LinkedIn to ensure this will not happen again?
And perhaps one more: is there a relation between LinkedIn, eHarmony and last.fm database leaks? Did the same person/group do this?
isolation 101 (Score:2)
This is a nice piece of work where he uses incremental modifications of existing password templates to show that password "seasoning" with a few stray twiddles such as s/o/0/ or s/$/! isn't worth much.
linkedin is the only social network I've signed up for, and I visit less than twice a year. Don't think I used a strong password, but I do know I used a password totally unrelated to any other password on any other active account.
Sure beats being the guy with the password lsw4facebook or lsw4citibank on sites
Sites that don't suck (Score:2)
There are only a handful of sites that I frequent that actually allow for useful passwords (ie. longer than 30 characters). Most are "between 4 and 12" or something idiotic.
As long as the people designing sites are inept and stupid, passwords will continue to be shit.
Re: (Score:3)
Unless you can derive the username from the password. But heh, what are the odds of that happening? *rolls eyes*
Re:YAY the cracked the passwords (Score:4, Informative)
... It is only useless if you have a criminal intent.
For those of us who do not actually want to abuse this leak, but instead learn from it, this is a great source of data!
It shows just how *****ingly clueless most people are when it comes to creating a password.
It shows how getting a bit smarter makes your password harder to crack, but still vulnerable to dictionary+statistical attacks.
It shows how 100% random is probably the way to go for anything of value.
Re: (Score:2)
Who is "they"? The public at large has access to the password file but not the account names. However, there's really no telling what the original hacker has. For security purposes, we assume the worst, and that is that someone has both the account names and a password file for which almost a third of the passwords have proven easily cracked.
Re: (Score:2)
Except the guy who released the hashes most probably does have the usernames as well.
Re: (Score:2)
You don't have the account names bounded to each password. There's a pretty good chance whoever got that information has both pieces of the list.
Re: (Score:2)
Somewhere a relation of password hashes to user names must be stored so that the system can check passwords; so the information exists. I think we have to assume who ever it was who crack the site in the first place has that information. They simply opted not to make it public for any number of reasons (few good for anyone with an account).
So its more like they have 2M keys, to specific houses and are jingling them in front of you just to prove it.
Re:Check your password (Score:5, Informative)
www.leakedin.org/
Nobody should use this site, period.
You seriously expect people to go to an arbitrary site and enter their password, knowing that the hashes have been leaked alongside account information?
In the kindest possible world this may be seen as a service, but the skeptic in everyone should hear very loud alarm bells. This site could easily log all of the passwords that are entered for "testing", use them to solve the harder-to-brute-force hashes, and deliver to the site operator the resulting account information and plaintext password!
Even if you had the best intentions posting that link, and even if the site actually is completely innocuous, one should never encourage any user to enter their password into a random third-party site. Please take it down immediately.
Re:Check your password (Score:4, Insightful)
As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server.
You make a fair point, but this is Slashdot, we're not supposed to be "users" here.
Re:Check your password (Score:4, Insightful)
In this case, you have all the tools to satisfy your inner skeptic: the source is right there, if you don't trust yourself to read it, it's trivial enough to examine all communication the page does. As the site says, the passwords are hashed on the client, and nothing but the hash is ever sent to the server. You make a fair point, but this is Slashdot, we're not supposed to be "users" here.
You also make a fair point, and I'll admit I didn't catch that and replied hastily in light of that.
There are, however, a lot of known website tricks that can get around this (e.g., collaborating iframes, etc.) as well as server-side tricks (e.g., serve a malicious page every nth visitor). A full client-side audit will prove any given instance harmless, and I suspect the site likely will pass all such tests, but I still think the encouraged trust of a one-factor authentication credential to a third-party site is in bad security taste, especially as the link propagates outside of the "expert" community to relatives and friends who will likely not have the know-how to perform such auditing.
Thank you for pointing that out!
Re: (Score:2)
It may also be the case that the posted source has nothing to do with the actions of the site. I mean, maybe they're being really friendly and helpful, but maybe the evildoers are just smart enough to instill a false sense of security by giving you some otherwise valid source, that isn't doing what they're trying to accomplish at all.
The bit about watching what the site does with Firebug or other browser tools or network monitors, will really reveal their nefarious nature...
Re: (Score:2)
I agree that not giving your passwords to such sites is a sound policy, but I also think it's good to actually check out if and how they could screw you, rather than just assume they can (by some dark magic).
Re: (Score:2)
I've seen sites that just post the plaintext password. Maybe it's not the best thing to do, but at least you know what not to change your new password to.
Re: (Score:2)
1. Changed my LinkedIn password
2. Went to the site, entered a fake, almost certainly unique password. Result?
"Looks like your password was not leaked. Hooray!"
3. Entered my old password -- a password now not used on any account. Result?
Your password was leaked and cracked. Sorry, friend.
Re: (Score:2)
Re: (Score:3)
You realize that the concern many computer security people here have is that your password hash is available in the open. And you want to freely type it into another website? I don't care how much you trust this site. Don't do this.