6.5 Million LinkedIn Password Hashes Leaked

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.

jere8• 14 years ago

Me. Admittedly, it's stupid as hell, but has generally been too much of a pain to do anything else (for things outside of banking, email). I've started to get serious about KeePass lately, but I bet a significant percentage of users take the lazy approach.

esbwhat2• 14 years ago

just use a couple of shitty passwords for sites you don't care about, and remember the other ones.

E.g. my hacker news account would probably be relatively unproblematic to compromise. If that were to happen, I'd just make a new one though.

smoyer3• 14 years ago

Full disclosure: I reuse passwords on "low-value" accounts too ... I am NOT innocent either.

kmfrk2• 14 years ago

Having to type in my Apple password on iOS once every few hours inevitably means I have to use something memorizable and quick to type. There are certain trade-offs with different passwords.

Zirro4• 14 years ago

I've developed a system (kept only in my head) where every password I use is based off on the name of the service. This means that with just one of my passwords, you're most likely not getting anywhere. With two, you have a bigger chance of figuring out the differences and thus the system, but it works fine for me at the moment.

mdemare2• 14 years ago

My linkedin password is an easy one. Then I checked 1password to see how many other sites I use that password on.

74 sites... including gmail, openid, facebook, skype, amazon, dropbox, reddit and this site.

navs• 14 years ago

I generally use the same password for what I feel are non-critical sites like LinkedIn, twitter and Facebook. Another password for testing new services/apps etc. As a rule any site that may contain my credit card data or sensitive information I use a separate password. I feel this is the best compromise to having complex passwords for each account.

ojilles• 14 years ago

I used this in the past as well. But then started thinking about what non-critical is. As a "internet professional", even my Facebook account being compromised would be negative impact on my image; on LinkedIN doubly so due to it's professional character. So I basically decided that I'm not going to distinguish at all (sliding slope) and just have randomly generated passwords for all sites (not for my Mac though, too much hassle/attack vectors are different).

Safe >> Sorry

EDIT: Just checked, and my randomly generated password is in the leaked list of hashed passwords. I'm not using that same password anywhere else, so the source MUST be LinkedIN through whatever means (or it's some Mac/PC based attack vector, and these folks only leaked LinkedIN accounts which sounds very implausible).

chli3• 14 years ago

The forum they are talking about apparently (found using google)

http://forum.insidepro.com/viewtopic.php?p=96122&sid=133...

smoyer3• 14 years ago

The Hacker News effect seems to have taken the forums off-line. If you need a quick DDOS and don't have a botnet handy, just post the link here!

joelhaasnoot5• 14 years ago

Might also be the fact it's all over twitter.

chli3• 14 years ago

https://www.dropbox.com/s/dsiuavbbzt8cy7g/forum.insidepro.co...

A saved copy of my local cache...

madethemcry• 14 years ago

I just looked into the file (combo_not.txt). There are only hashes. Who decided that the hashes posted in the forum are related to linkedin in any way ? Thank you.

jackalope2• 14 years ago

Those paranoid tinfoil-hat wearing lunatics that generate absurdly long unique random passwords for every site are wringing their hands with glee because they found the hash of their LinkedIn password in the file. You're welcome.

judofyr• 14 years ago

> - With a computer of 8,000 NOK (~ 1400 USD), you can do a few hundred million attempts per second.

Are you kidding me? LinkedIn stored their passwords using (salted) SHA1 using no iterations? Jesus.

avar• 14 years ago

To expand on that, to store passwords don't just use salt+sha1, or try to do your own nested sha1, just use bcrypt: http://en.wikipedia.org/wiki/Bcrypt

chrisaycock• 14 years ago

Better still, use scrypt. HN's very own @cperciva wrote it.

http://www.tarsnap.com/scrypt.html

It requires a lot more memory to brute-force it, thereby defeating any speed gains from parallelism.

romaniv8• 14 years ago

I wonder, why do people saying "just use bcrypt" never, ever bother to elaborate on what benefits it has, and which of them are relevant to the subject of the conversation? Believing in some function without understanding implications of its use does very little for real security.

stef25• 14 years ago

Could you explain what you mean with "nested sha1" - hashing it twice? How is this safer than sha1 + a good salt?

ams61102• 14 years ago

If you use the ASP.NET Membership that's what you get, unless you do something custom.

Edit: they are salted though.

jakejake3• 14 years ago

I'm not familiar with iterations, anybody care to clue me in? I would have thought salted sha-1 would be decent for password hashing, though not the most solid possible, but at least not laughable. Is that not the case?

Anderkent3• 14 years ago

It is not. Sha1 is designed to be fast. You want your password hash function to be slow, so that an attacker has to spend as much resources as possible to brute force it.

Of course, it does not mean you should take a slow implementation of a fast hash. You need a hash that, when implemented to be as fast as possible, still is pretty slow.

salmanapk• 14 years ago

No they didn't salt them either haha!

smiler• 14 years ago

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.

jere8• 14 years ago

Agreed. That seems rather useless. How would that happen anyway? The usernames stored in a different database/table from the hashes?

joelhaasnoot5• 14 years ago

They might need help cracking the hashes, keeping the usernames behind for their own exploits.

hoov• 14 years ago

LinkedIn allows you to sign in using any of your verified email addresses, so it seems likely that the usernames are at least stored in a different table.

snorkel• 14 years ago

... but still, a head wag at LinkedIn for using weak hashing, which I'm guessing means MD5.

DaveChild• 14 years ago

MD5 isn't the issue - it's the lack of salting. Without a salt, almost any hash can be cracked with a rainbow table. With a salt, you'd need to know the salt for each hash, and then generate a new rainbow table, in order to recover the original password.

madsr4• 14 years ago

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! :-)

mjschultz• 14 years ago

Doesn't this imply that LinkedIn doesn't salt the password prior to storing it. So then a good chunk of those passwords will be in a rainbow table.

mkjones4• 14 years ago

Interesting - I wasn't able to find the hashes of any passwords in the list. What list were you using?

philip12092• 14 years ago

As a more general question: why is it not an industry standard to salt with the username/email in addition to the random key? (i.e. Sha1($salt + $email + $password)). Even if the random salt were excluded, I would think that this is much more secure. Existing rainbow tables would not be anywhere near as helpful, and attempts to generate a rainbow table for a specific salted database would be ineffective because the salt changes on a per-user basis.

Scorpion• 14 years ago

Oddly, mine isn't in the leak despite the fact that I just logged in with it.

rbanffy• 14 years ago

You can use it for checking whether your password was leaked. You don't need usernames for that.

TomGullen• 14 years ago

Are the hashed passwords not salted?

kevindication2• 14 years ago

LinkedIn could easily match each hash to a user. Then they should lock each of those accounts and force them to change their password.

carbocation3• 14 years ago

Which should be done, but which doesn't help those users where it matters most; the real value of this database is that some people (~everyone) reuses passwords across sites.

mibbitier• 14 years ago

From the looks of it, the data dump may be all accounts - since there seems to be no salt, and many people use same passwords...

NatW• 14 years ago

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:

000000a94d47b9cb82ca8a3b492a51263b40a66e 000000a98a624314892af97c6f1a0635472eae38 000000a9ba60e7f13fcac444a5a791af7807a3a3 000000a97ea34e74a97a6d1ce08ebc68d3e9aab2 000000a9b4b2a3497aaa51e212ac9efdb00aaf4e

Anderkent3• 14 years ago

The pattern 000000a9 is just in presentation - I counted the occurrences of different bytes in that position (also misled by the apparent pattern, where many lines in a row would have the same 4th byte), and each possible value is present more or less equally often.

It seems like it's just sha1.

EDIT: however, 3.5 million hashes start with 5 zeroes, which is way too many for just coincidence. Possibly they used multiple hash functions?

ominous• 14 years ago

Found this on reddit: http://www.reddit.com/r/netsec/comments/unubl/if_it_turns_ou...

My password it not in there, but some people have already reported finding theirs.

jameswyse2• 14 years ago

Does anyone know what encryption scheme LinkedIn uses?

lhnz• 14 years ago

You don't mean encryption. Passwords should be hashed.

kristofferR2• 14 years ago

Hashing scheme, not encryption scheme.

Anyway, they use Unsalted SHA-1, a really weak option.

jameswyse2• 14 years ago

Indeed yeah, I meant hashing.

I only build tiny websites compared to linkedin and even I take the time to use a proper hashing scheme with a salt. Shame on you, LinkedIn.

StavrosK2• 14 years ago

Can we please start using BrowserID or some other standard so we can secure that one provider and do away with all this? I'd like it if we could authenticate with Google using 2-factor authentication and be less worried about my password getting hacked.

scrrr• 14 years ago

A single point of failure sounds dangerous. People should just avoid using the same password for different websites. (That's what KeePass is for..) Perhaps a clever extension / browser feature could ensure that. (e.g. "Warning: You are probably using the same password for facebook.com")

pilif• 14 years ago

By centralizing authentication, you make that central provider an even bigger target and you risk losing access to other services as you lose your main account (Google is known to sometimes terminate accounts with no way of recurse).

Finally, when that central provider gets hacked, all your dependent services are now also compromised.

And as we know from the CloudFlare story over the weekend, not even Google with their 2 factor authentication is devoid of issues.

No. Centralizing your login to one third-party as as bad as the current practice of reusing your password for every service you have an account with. The only way that is reasonably safe is to use different random credentials for every service and store these credentials somewhere under your (and only your) control (i.e. a password manager or a piece of paper)

joeyh• 14 years ago

Browserid is not a centralized authentication protocol. Although currently all implementations I know of rely on browserid.org, this is not required by its design.

There's also the fully decentralized openid, you know. I'd 100% rather be able to use openid for sites like Linkedin and this one than rely on every site implementing sane password management.

unimpressive• 14 years ago

Why can't we just use good old PGP?

There is no reason why we should centralize password management and put the world's authentication into one giant pinata for black hats to take a swing at.

drivebyacct25• 14 years ago

Wow. Not only is every single reply to StavrosK completely wrong about how BrowserID works, they're actually doubly wrong. Not only is it NOT centralized, it also can be used with:

- 2 factor auth

- asymmetric encryption (aka, a challenge/response ala PGP)

- whatever security mechanism you want, frankly. It's up to the browserid provider.

StavrosK2• 14 years ago

My rationale is that it's much easier to secure one provider (the attack surface is much smaller), and you can also run one yourself, making you responsible for all your authentication needs.

OpenID was great in that you could choose any provider you wanted, and nobody could attack them all (not that they'd have to). It just seems like a good solution to use someone whose only job is to provide secure authentication.

sparknlaunch2• 14 years ago

When Twitter recently had accounts and passwords leaked, many were attached to spam accounts or duplicate records. Most had obvious passwords (like 1234).

Are these legitimate active accounts? Can you do anything with the hashed passwords alone?

ecaron• 14 years ago

In fairness to Twitter, it was never actually known if the accounts/passwords came from Twitter.com (proper) or (more likely) leaked from some 3rd-party Twitter-integrating app that had pre-OAuth integration.

tocomment3• 14 years ago

This makes me wonder. I've been relying on Django's built in user authentication lately. Does anyone know if that's pretty safe? Is it doing the right thing for hashing passwords?

Glowbox• 14 years ago

Disclaimer: I am not a cryptographic expert.

https://docs.djangoproject.com/en/dev/topics/auth/

Django by default uses the PBKDF2 algorithm, which is better than nothing/md5/no salt sha1.

I'd use bcrypt or scrypt by default, better be safe than sorry.

masklinn• 14 years ago

> which is better than nothing/md5/no salt sha1.

It's also better than salted sha1 since it performs multiple iteration rounds leading to (configurable) higher computational complexity.

ams61102• 14 years ago

PBKDF2 is way better than salted hashes. It's right there with bcrypt and scrypt on the "good choices" list.

leif4• 14 years ago

Pbkdf2 is extremely good. Without deeper analysis (or a feature comparison) I'd be hesitant to say that bcrypt or scrypt are better.

tptacek13• 14 years ago

Django has chosen a fine default and for the next several years it's probably unnecessary to second-guess it. Over time, GPU and (more importantly) FPGA-assisted hash cracking may or may not become more common, at which point you'd want to transition to something like scrypt.

You could literally flip a coin to decide between bcrypt and PBKDF2 and it wouldn't matter which side came up.

nyellin• 14 years ago

I'm not an authority on this, but django_bcrypt is generally considered a best-practice in the Django community. Scrypt may replace that in the future, once implementations are widely available and battle-tested.

lemonad• 14 years ago

Yes, and to make Django even more safe, a number of improvements have been made over the last year (e.g. https://code.djangoproject.com/ticket/15367).

tintin• 14 years ago

I know a lot of companies just keep your account including your password in there database while you removed your account.

Can I be sure my account was totally removed when I removed my LinkedIn account? Because the "please change your password as soon as possible" won't help me much.

finnw2• 14 years ago

As long as:

1. They do not have a mechanism to resurrect your account and 2. You do not use the same password elsewhere

then it should not matter.

jurre• 14 years ago

There should be a huge banner on linked in urging users to change their passwords in my opinion.

bgilroy26• 14 years ago

Even more important to change password on other sites if you use the same email/password combo there

moondowner• 14 years ago

You can generate your own SHA1 for your password and check if it's existing in the txt file.

http://jssha.sourceforge.net/

pjscott4• 14 years ago

Or, if you don't trust random web sites, we can turn this into the next fizzbuzz:

    $ python -c 'import hashlib; print hashlib.sha1("hunter2").hexdigest()'

This will print the SHA1 hash of "hunter2".

madsr4• 14 years ago

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?

revelation• 14 years ago

Given that these hashes are not salted, running a 'uniq' on the list of all users' password hashes would probably already cut it by half, if not more. Then you eliminate all the easy ones from wordlists, and post the remains on the internet for people with excess computing power to bruteforce.

leif4• 14 years ago

My password shouldn't be easy, and wasn't in the list.

16s5• 14 years ago

They are already unique and sorted.

sort -u combo_not.txt | wc -l 6458020

wc -l combo_not.txt 6458020

seiji• 14 years ago

Ways I've seen this play out before:

• Someone got in to one user database, but not all of them.

• Someone got into the complete user database, but were found out during the intrusion and cut off.

• Someone found a sharded DB dump or backup.

• Someone found/stole/virus'd a dev laptop with DB dumps.

• Someone sat on the network for a while and grabbed app server -> DB traffic.

Replace "Someone" with "russians," "brazilians," or "something behind tor" for more accurate portrayals.

Zirro4• 14 years ago

They just tweeted this: https://twitter.com/LinkedIn/status/210356987576324096 - "Our team is currently looking into reports of stolen passwords. Stay tuned for more."

Aqua_Geek• 14 years ago

And a follow-up: "Our team continues to investigate, but at this time, we're still unable to confirm that any security breach has occurred. Stay tuned here."

https://twitter.com/LinkedIn/status/210390233076875264

Splines2• 14 years ago

If people are finding their unique password's hashes in the database, that's pretty damning evidence that a security breach has occurred.

tazzy531• 14 years ago

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.

philip12092• 14 years ago

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.

jere8• 14 years ago

How would one cross-reference this list unless you're storing the plain text passwords?

ryusage• 14 years ago

The released passwords are hashed with SHA1. Assuming you use the same algorithm and linkedin does not use a salt (they probably do), then you could just compare the hashes.

rplnt• 14 years ago

Maybe he was implying that they and Good Guys Startupers use hashes from raw passwords. I hope that is not true.

edit: From reading comments bellow I learned that LinkedIn indeed didn't salt.

LinXitoW2• 14 years ago

you'd compare the hashes in your database with those from the file. The users with a hash contained in the file would be notified.

Because the passwords aren't salted(stupid), you might get multiple hits for the same hash(for example, for the good old "1234" password), meaning you might end up contacting more users than actually affected. Better safe than sorry.

toyg6• 14 years ago

You'd do it at login time. User enters user/pwd -> hash with unsalted sha-1, check if in list -> if yes, alert to change / if no, proceed with normal hashing.

veemjeem5• 14 years ago

Easy, just convert all the hashes into passwords using a rainbow table. Should only take a few seconds to convert all 6.5M passwords -- O(n) operation here. Then run all the passwords through each user's password algorithm, this is a O(n^2) operation. Essentially you're making 6.5M password attempts for each of your users. It could be slightly faster because I'm sure there are quite a few duplicates in 6.5M passwords.

iamstef• 14 years ago

A cross-reference is only feasible in very bad situations: - no-salt or same-salt and same hashing - trivial/common passwords (password1 etc) - password(hashed/unhashed) and email are paired.

A cross-reference could be accomplished for all known cracked linkedin passwords, but this would be no different then you running a dictionary attack of known passwords against your own users... This seems very bad. Enforcing strong but sane password strength rules should mitigate this need.

Cross reference only has value if both the hash and email pairs are leaked.

The bitcoin leak fell into one of these very bad situations: - [<email>, <hash>] where leaked together - poor hashing (just sha1, no salt if memory serves) - unfortunate number of people reuse passwords

rmc• 14 years ago

You can do this if you, like LinkedIn, store SHA1 unsalted passwords. You just look for matches.

slig4• 14 years ago

Google once forced a password reset for emails/passwords that leaked from a bitcoin forum.

kristofferR2• 14 years ago

That's easy to do it you have the email addresses, but impossible to do if you only have the SHA-1 hash, as in this case (unless you're also using unsalted SHA-1 hashes, which is a much bigger issue by itself).

jcfrei• 14 years ago

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.

aqme28• 14 years ago

Better Guy Startup Founder would be using salted hashes anyway and wouldn't even be able to run a cross-reference.

nnnnnnnn• 14 years ago

It's possible to test this when your user re-authenticates, assuming you're not using a challenge-response authentication mechanism (as sadly most sites do not).

john-n• 14 years ago

Interestingly, linkedin did just that whe the gawker list was leaked (iirc).

philfreo3• 14 years ago

Funny, LinkedIn was one of the few services that made me do this after the Gawker fiasco

swombat3• 14 years ago

Am I glad that I use LastPass and have a different, 12-character password for every service?

Why, yes, yes, I am. I've now changed my LinkedIn password, too, just in case.

jgrahamc5• 14 years ago

I'm even happier I don't have a LinkedIn account.

lemming• 14 years ago

I've been tempted to delete mine several times recently. Looks like now is the moment.

Zirro4• 14 years ago

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?

16s5• 14 years ago

Use open-source tools such as SHA1-Pass. The passwords it generates can be recreated with openssl and any other standard crypto library.

Edit: I wrote SHA1-Pass, so I'm biased, but I know what you mean about having trust issues with closed-source password tools. That's one of the reasons I wrote it.

Torn• 14 years ago

I've always wondered this about services like lastpass.

What stops being hacked / keyloggered and them exfiltrating all your long, complex passwords?

joelhaasnoot5• 14 years ago

KeePass works well too - open source, offline solution that has an "Autotype" function. I actually only run into passwords that are a pain on mobile devices. Now that my Android phone has no keyboard but tons of power, that's becoming more and more significant.

brown9-22• 14 years ago

I think it's a risk with a solution like this, but much less of a risk of having to remember all these passwords myself (a practice which tends to devolve to re-using passwords).

LogicX2• 14 years ago

This is why I use 1password and not LastPass - the encrypted password file is stored locally - optionally in Dropbox, which is what enables moble and remote (http online through Dropbox) to work.

Works excellently!

philfreo3• 14 years ago

Then use 1Password - it's much nicer designed and you don't have to trust their servers too much

drivebyacct25• 14 years ago

It saddens me that every, single, time this topic comes up, HackerNews, of all places, displays an immense lack of knowledge of current password storage applications, how they work and what value they bring.

I think it's really humorous that people feel safe putting an encrypted file in something like Dropbox, but don't trust LastPass (who are doing the exact same thing, everything is local, client side encryption). Especially when you're missing out on all of the benefits of browser integration.

Please, take a whole 3 minutes and do a tiny bit of research. Your future self will thank you when people like swombat and myself get to laugh at LinkedIn, change our passwords and never think about it again.

LogicX2• 14 years ago

I think the difference you're missing is that LastPass offers the OnlineVault option.

I much prefer the security of being in control of my file, and having its online option controlled by someone else (Dropbox); and logging into Dropbox to then see my passwords 'online' on the go.

If Lastpass.com is compromised, the attacker can MitM compromise my credentials. If 1Password.com is compromised, that is not the case. (Yes, if Dropbox is compromised, they could capture my dropbox credentials, but it would be more difficult for them to then capture my 1password credentials)

Ref: LastPass Online Vault: http://helpdesk.lastpass.com/full.php 1Password Anywhere: http://help.agile.ws/1Password3/1passwordanywhere.html Services I use, and why: http://www.mikeschroll.com/blog/2011/12/07/services-i-use-an...

someone_welsh• 14 years ago

I apologise for my immense lack of knowledge of current password storage applications (i'm not a programmer and come here for the other stuff), but what is the benefit of these services (lastpass etc)? This is a genuine question.

It seems to me that instead of having several passwords in my head (i can remember random long strings of characters pretty well, and have a heirachy of randomness/longness depending on what I care about), I only have to remember one. But if that one's compromised, aren't all the rest then available?

Reminds me of the bit in hitchhikers guide to the galaxy (life the universe and everything i think) where passwords and biometrics etc had become really difficult and secure, so a datacube thing was created to store them all. Which was then found by a character before hilarity ensued.

thanks

K2h• 14 years ago

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.

ragmondo• 14 years ago

I wrote a short article about this kind of stuff - if it's really my data, then let me use my lock on it : http://ragmondocom.appspot.com/2012/03/My-Stuff-My-Lock

Then I get to choose what strength lock I put on it.

cheald• 14 years ago

First rule of software design: users are lazy. Second rule of software design: users are stupid.

"Use your own lock" is fine for us Übergeeks, but for the vast majority of the populace, they just want the provider to put a system in place so they don't have to worry about it.

Smerity6• 14 years ago

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

pixelcort• 14 years ago

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.

Cushman2• 14 years ago

That could be a good transition strategy if you're worried about being compromised before all your users have logged in again, but you would still want to move them over to using just the new system when they do. It probably would be fine, but when it comes to crypto you don't take chances when you don't have to.

peteretep2• 14 years ago

Yep. Here is a treatment of that: https://gist.github.com/1051238

Jabbles• 14 years ago

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

ricardobeat3• 14 years ago

Please don't downvote posts like the parent. It's a legitimate comment, asking a question, if you have something to say please reply.

LinXitoW2• 14 years ago

It would make it a lot easier for LinkedIn to identify whose hashes were leaked because with a salt, all passwords would be unique. It would also make rainbow tables useless.

But in this day and age, the bigger problem is how fast you can compute the hashes, salt or no. With GPUs you can calculate a few hundred million(depending on the hashing algorithm) per second, making the algorithm used the real vulnerability.

Best practice involves increasing the calculation time of you're algorithm. Theoretically, you could just rehash y few thousand times in a loop, throwing in a salt here and there, but practically, you should just use bcrypt or scrypt.

Smerity6• 14 years ago

I hear this commonly, so it is a good idea to clear it up.

Usernames have lower entropy than a random salt and are predictable in many cases. People re-use usernames and some usernames are common. If your password system became common on the web, or if I knew the workings of your password system (i.e. open source / leaked codebase / Kerckhoffs's principle[1]), I could generate a rainbow table for either common or targeted users. This means I could generate a rainbow table for "Jabbles", gain access to your password and compromise your account before the website is likely even aware of a breach or has time to warn you. Salts only act to slow down, not prevent, compromising leaked password hashes (as you can always brute force which is quite practical with MD5/SHA1). Thus, using a username defeats one of the stated purposes of salting.

It's also said ad nauseam (with good reason) but rolling your own in security is a bad idea, especially when libraries exist that do exactly what you'd intend to do just as easily. Algorithms such as bcrypt and scrypt exist and are well vetted. bcrypt is easy to integrate with many languages and provides a trivial interface and sane defaults for iterations/rounds [brute force] and salts [rainbow table]. bcrypt can also handle increasing the security of your system over time as the metadata is stored as part of the hash.

tl;dr Using a username for salting means a targeted attack against a single or small number of users would be damn near impossible to stop as the second they have the password hashes they also have the passwords.

[1] http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

latortuga2• 14 years ago

In a password hashing scheme with a salt, you're supposed to consider everything except the cleartext to be public, for the purposes of analysis. The password should be unrecoverable even if the attacker knows the algorithm and any salts.

cschneid3• 14 years ago

Remember salts don't need to be secret to do their job. The goal is to change the algorithm slightly (by adding additional input) for each user. That means you can't mass-precompute (rainbow tables), and just look up what matches, you have to break each user individually.

Your reasoning about how salts work is correct.

There's also something called a pepper which is another additional bit of input data, that is only stored in the app code (fixed for entire app). So an attacker who only manages to get a database dump would need to guess yet another chunk of data (making it near impossible). So a well-seasoned hash would be SLOW_HASH(pepper+salt+password).

Security is all about layers. Each layer protects a bit more, or prevents things from being easy for the attacker.

Edit: Don't do this yourself. Know it for the theory part - but then just use a well-vetted library to do it.

Cushman2• 14 years ago

It's true that that would be an improvement, however we try to avoid discussing things like that seriously because of the risk that someone new to the game will actually try to do it. The easy answer is to use an out-of-the-box secure password strategy, anything else is adolescent.

ricardobeat3• 14 years ago

We've just checked everyone's passwords around the office. One of them was in the list, and he has accessed the site the past month.

tg3• 14 years ago

Could be that he shared a password with another account that hasn't? Wishful thinking most likely.

jcdavis• 14 years ago

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?

Smerity6• 14 years ago

Hoping for competence is indeed flawed from both sides. I would hope users use distinct, random passwords for each site they visit and that developers store those passwords in a safe secure way. I also assume both sides won't listen to logic however :)

The reason I'm annoyed with this particularly is that larger sites are more likely targets due simply to their size. Larger sites generally have the developer resources to provide a good solution to the problem from their end but commonly don't.

This makes them look bad and means their users are left in more danger than before. No-one wins.

seats• 14 years ago

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

nohat• 14 years ago

Perhaps the worst part is that they either didn't know about the breach (likely), or didn't tell anyone (hopefully not).

slig4• 14 years ago

Looks like they were too busy tuning their Spam All Your Friends (TM) "invitation" feature to bother with proper ways to store passwords.

marbletiles3• 14 years ago

Given they haven't confirmed they've found and closed the leak, is it wise for everyone to be changing their passwords already?

Aissen3• 14 years ago

Given many people have confirmed that their uniquely generated password is in the list, is it wise to wait any longer before changing your password ?

marbletiles3• 14 years ago

I guess you need to do both: change your password, but to something throwaway. Then when the hole is closed, change it again.

vecinu2• 14 years ago

I'm not sure what you're implying. How have they 'closed the leak'?

If you find your hash in the list, you should change your password. If you don't, you should change your password.

I use LastPass to manage my passwords so I just generated another random 20+ char password and forgot about it.

marbletiles3• 14 years ago

The point is that LinkedIn haven't even confirmed they know how the passwords were stolen (they haven't even confirmed they were stolen, yet).

In that case, when you change your password and feel all secure again, what's to say the hackers haven't just lifted your new hash as well?

miniatureape2• 14 years ago

I didn't see it in the post, but does anyone know if these were current passwords (as of this post)? I use a unique password for linked-in, but some number of months ago I used a password I shared with another site. Wondering if I need to change that one too. Guess I might as well.

madmaze3• 14 years ago

I confirmed mine is in the dump as well

mutagen• 14 years ago

Mine as well, unbroken (not prefixed with the 00000) in the original file.

fluidcruft• 14 years ago

Can anyone tell me where I can change my password on LinkedIn? I must be dense.

nodata• 14 years ago

https://www.linkedin.com/uas/change-password

It's buried under "your name" (top right) > settings > password > change (just below your e-mail, left side)

re_todd3• 14 years ago

Assuming LinkedIn used SHA1 unsalted passwords and will continue to do so, and many of us do not want to delete our LinkedIn accounts, what should be the minimum number of characters we should use in our new password? 15? 20? 100? (I know, 100 is probably higher than they allow)

re_todd3• 14 years ago

I just reset to a 22 character password, so I know that number of characters is allowable at least.

Aissen3• 14 years ago

If you want to check if your password is in there:

    read -s a
    zgrep $(echo -n "$a" | sha1sum | cut -d' ' -f1 | \
      sed -e 's/^...../00000/') combo_not.zip
    unset a

akavel• 14 years ago

According to jgrahamc's investigation, this will probably check if your password is there and is cracked already. To check if the hash is there, although uncracked yet, you should probably remove the sed call from pipeline.

Aissen3• 14 years ago

Oh. You're right, I missed that. New command line:

    read -s a; zgrep --color -E $(hash=$(echo -n "$a" | sha1sum | cut -d' ' -f1); echo -n "$hash|$(echo $hash | sed -e 's/^...../00000/')" ) combo_not.zip ; unset a

jgrahamc5• 14 years ago

Some observations on this file:

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.

dpritchett4• 14 years ago

For the security novices amongst us: I had no idea how to do this so I figured out a quick python script to test it:

    >>> from hashlib import sha1
    >>> def check_pass(plaintext, offset=5):
    	hashed = sha1(plaintext).hexdigest()
    	return (hashed, '0' * offset + hashed[offset:])

    >>> check_pass("linkedin")
    ('7728240c80b6bfd450849405e8500d6d207783b6',
     '0000040c80b6bfd450849405e8500d6d207783b6')

Edit: I'm pretty sure JtR refers to this: http://en.wikipedia.org/wiki/John_the_Ripper

peterwwillis3• 14 years ago

Obligatory perl one-liner:

  perl -MDigest::SHA -le '$h = substr( Digest::SHA::sha1_hex($ARGV[0]) , 5 ); open F, "<combo_not.txt"; do { print "found $_" if grep(/$h/, $_) } while (<F>)' password

(for people without shells)

d503• 14 years ago

If you're paranoid about shoulder-surfing you can use getpass to hide your password as you type it in.

    >>> import getpass
    >>> password = getpass.getpass('Password: ')

http://docs.python.org/library/getpass.html

mas1n• 14 years ago

A complete python script assuming you have hashes.txt in the same directory.

http://dpaste.com/756007/

eidorianu2• 14 years ago

Any password that I try works...

chli3• 14 years ago

If your password was 'linkedinsucks' then it sucks because they found it already !

jgrahamc5• 14 years ago

Correct!

  527688fa9f32bb8dab32d30807ca5c57a0b203b8 is not present
  000008fa9f32bb8dab32d30807ca5c57a0b203b8 is present

two1eight• 14 years ago

Also if it was "linkedin"

7728240c80b6bfd450849405e8500d6d207783b6 not present

0000040c80b6bfd450849405e8500d6d207783b6 present

or "facebook"

cbe648909034c0624c205fe219d3fbd10052c715 not present

000008909034c0624c205fe219d3fbd10052c715 present

or google

759730a97e4373f3a0ee12805db065e3a4a649a5 not present

000000a97e4373f3a0ee12805db065e3a4a649a5 present

madmaze3• 14 years ago

I disagree with #5, I had a few of my coworkers check their sha1 against the DB and most of them were not in the dump. I also checked for truncated hashed, none of which were found. I have the feeling this is a subset of the full database

madmaze3• 14 years ago

on another note,

my fairly complex alphanumeric+symbol password IS in the dump, though not prepended truncated with 0's and the other one I found, which my coworker admitted was too short and alpha only, was in the dump with prepended 0's.

This could validate the fact that the truncated hashes are actually already cracked.

barik• 14 years ago

I don't really see a purpose in hiding my password. So, as a counterpoint, my password is in the list. This is my LinkedIn password:

AxEWS9rg5V

This is the sha1:

caf28fcc9c3e4d88b830b8e5cc52c5b65d3db5f4

It is found in Line 3612910 of combo_not.txt. I believe the file is authentic.

ddlatham• 14 years ago

Another datum: the hash of my password (randomly generated 8 character mixed case alphanumeric) was in the file, without any overwritten 0's.

leot• 14 years ago

Mine is there.

(email me if you need proof)

daurnimator2• 14 years ago

My linkedin password of at least 3 years was not in the dump. So it must be a partial...

yesbabyyes• 14 years ago

My password is in the dump. I use the Forget Passwords Chrome extension [1], which is based on pwdhash.com, and generate site-specific passwords based on a master password -- i.e. my password is only used on LinkedIn and it's unlikely that I share it with someone else.

I think I have changed to this password during the last year.

jen_h2• 14 years ago

So I have a funny wild theory...remember back when the Gawker database was compromised? And LinkedIn forced a password reset for users who (according to what I read) used email addresses that matched the Gawker leak?

What if they also (or actually) compared password hashes from their database to the ones released in the Gawker breach? In that case, they likely wouldn't have pulled data straight from the database but actually might have pulled passes from the db, output to text files, cut the text files up to parcel out for processing via Hadoop or something? And somehow one of those text files got loose somehow...or someone MiTMed the actual process (I'd vote for a floating text file just because it's been so long; the Gawker breach was in December 2010).

thaumaturgy3• 14 years ago

Hmm. My truncated password (for my now-deleted account) is not in the list of hashes -- so it's not just a uniq'd full DB. Also, the original forum thread where the file was first posted only managed to break around 600,491 passwords before it went offline ... so 3,521,180 broken passwords could mean that the original hacker has had access to some LinkedIn accounts for more than just a few minutes today.

iand• 14 years ago

Same here. My password is not in the list and I've had a LinkedIn account since 2003. I probably changed my password about 18 months ago. Neither that nor the previous one are on the list.

OlavHN• 14 years ago

I've had the same password on linkedin for as long as I remember and neither the full hash nor the zero prefix edited was found in the dump.

Simple line used in OS X terminal:

grep -e "`echo -n "your pass" | openssl sha1`" combo_not.txt

jen_h2• 14 years ago

May want to grab the last characters as the cracked passes have 00000 at the beginning:

i=`echo -n 'mypass' |openssl sha1 |echo ${i:14}`; grep $i combo_not.txt

This yielded success on some known passwords and a bunch of obvious passwords. Not mine, but I assume this dump is a list of the passwords they've cracked so far (i.e., even if your password isn't on this list - change it).

riffraff• 14 years ago

fwiw, this could also be an elaborate hoax, given this facts.

E.g. a list of simple password + combinations of the above simple password+"linkedin" variations.

blantonl• 14 years ago

I have a very unique strong password on LinkedIn, and it is on the list. Given that, this is no hoax.

Yoms2• 14 years ago

My complex unique password is also on this list (full hash no 5 0's). So nope, not a hoax. Unbelievable/insulting they didn't even bother to salt.

eidorianu2• 14 years ago

I agree, I've tried several passwords and they match. If you're a Math person, please shed some light on the chances that this list covers the full space.

shill2• 14 years ago

I have found hashes of linkedout, recruiter, recru1ter, googlerecruiter, toprecruiter, superrecruiter, humanresources and hiring.

If it is a hoax, it is a very elaborate hoax.

pbhjpbhj2• 14 years ago

Perhaps it's a DDoS on MediaFire! /joke

shill2• 14 years ago

I have found one case where both types are present.

grep `echo -n l1nked0ut | shasum | cut -c6-40` combo_not.txt

    000000afef5f2ba94b104126d04db1837f423816 
    e7bf10afef5f2ba94b104126d04db1837f423816

akkartik5• 14 years ago

How many hashes are present in both stripped and unstripped form?

  $ cat combo_not.txt |cut -c7-40 |sort |dups |wc -l
  670781

That's ~10% of the total.

lt• 14 years ago

Another data point:

I changed my linkedin password about three weeks ago. The old one is in the list (already 00000-ed), the new one isn't.

rfugger2• 14 years ago

My (very unique) password hash is in the list, although unbroken so far.

mehrshad• 14 years ago

Don't know if this adds anything, but both my old password (created eight years ago) and current password (changed six months ago) were on the list. Both were very unique - 20 characters mixed.

Need to get better at changing my PWs every three months. It's really not that hard, just a matter of discipline.

ghshephard• 14 years ago

I don't know if I have the correct file: http://www.mediafire.com/?n307hutksjstow3

mbf041:Downloads shephard$ wc -l SHA1.txt 6143150 SHA1.txt

My password hash which was last rotated July 5, 2011

   .,7^R8Cl}g1}Ze6f

Was _not_ found in the file (with/without 00000). I have, of course, changed it today. Strangely enough, the previous password is also not in the list.

stordoff• 14 years ago

My password also doesn't appear to be in the list, so I doubt it is the complete/current file. I used this python to check, in case anyone else wants to use it:

    from hashlib import sha1
    f = "combo_not.txt"
    hashes = [x[0:40] for x in open(f)] # [0:40] to stripe off \n

    # From another comment
    def check_pass(plaintext, offset=5):
        hashed = sha1(plaintext).hexdigest()
        return (hashed, '0' * offset + hashed[offset:])

    print check_pass("linkedin")[0] in hashes # -> False
    print check_pass("linkedin")[1] in hashes # -> True (sanity check)

    myHash, myHashBroken = check_pass("plaintextoflinkedinpassword")
    print myHash in hashes # -> False
    print myHashBroken in hashes # -> False

michh• 14 years ago

> Evidence against that thesis is that password of one person that I've asked is not in the list.

Mine isn't in it.

bandris• 14 years ago

Neither is mine.

endtime• 14 years ago

Good posted, upvoted. One clarification:

> That's 25 users per hash

Password choices are probably Zipf-distributed, so averages don't make a ton of sense.

dredmorbius8• 14 years ago

It does if you're trying to estimate the size of the corpus based on the number of users.

The arithmetic mean is specifically the value you'd want. n users times m users/password == total passwords (unduplicated) in the LinkedIn database.

Zipf distribution would suggest that the pattern of reuse among passwords isn't normal, and that the median and mode are probably higher than the arithmetic mean.

joshz• 14 years ago

Mine was not in the list. It's also possible this isn't the entire file. I was also able to recover 225129 other passwords with a wordfile and some Python based on truncated and full hashes.

perinteger• 14 years ago

Got a link to the file? I haven't been able to dig one up

Estragon• 14 years ago

So where is the list? I'd like to see whether I'm on it.

royce2• 14 years ago

A stock JtR 1.7.9-jumbo5, using the default rules, is finding quite a few of the non-zeroed ones pretty quickly. This surprises me; I would have expected them to have run the list through the JtR mill before passing it on to others.

diminoten• 14 years ago

The list of cracked hashes is almost certainly not complete, one can conclude from this fact.

pruby• 14 years ago

The hash of my password, set when I joined on October 10 2011, appears not to be in the list. Changed it anyway.

A1kmm• 14 years ago

Likewise, my password (MybXy836YCza), which wasn't used anywhere except my LinkedIn account created 29-Jan-2012, and has been stored securely at my end, wasn't on the list (either as a full SHA1 sum, or as part of the SHA1).

As you probably guessed from the fact that I posted my old password, I changed it just in case the list that was shared is only a partial list of what was obtained.

pythonophilic• 14 years ago

Nice observation dude, Can u please share the password file I dont have it anywhere. Thanks

jrabone• 14 years ago

There's an English-language article (rather than a translation) at http://www.bbc.co.uk/news/technology-18338956

steve8918• 14 years ago

Has any legitimate sources confirmed that the usernames were also stolen along with these hashes? Or were only the hashes stolen?

Could this just be an elaborate hoax where someone generated 6.5M SHA1 hashes and said that they hacked linkedin? Maybe someone shorted LNKD and then leaked this, hoping for a monetary gain?

slig4• 14 years ago

Someone in this thread stated that his non-common password is hashed on the list so, very unlikely.

aparadja• 14 years ago

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.

  guesses: 11516  time: 0:00:21:36 0.00% (3)  c/s: 27126G  trying: aptewwod - aptewws1

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.

instakill• 14 years ago

Why is there no notification on their website?

bstar77• 14 years ago

I have an ignorant question... when a SHA1 encrypted password is cracked, can the hackers actually identify what the unencrypted password is?

I'm guessing no since SHA1 uses a hashing algorithm and only a brute force approach would potentially work...

cschneid3• 14 years ago

"Cracking" in this sense is brute forcing. SHA1 is fast, and people use bad passwords. The combination means that you can run through lots and lots of bad passwords very quickly. I checked my linked in password I have stored in 1password, and it is 20+ chars with special characters and numbers. That won't be "cracked" in any meaningful sense, so I don't even worry about it.

You are correct that there's currently no way to go from a hash to a value that hashes to it in SHA1 (AFAIK, IANYNSA [I am not your NSA]).

akrasia• 14 years ago

I'm not an expert in the field but from what I know, SHA1 is a one way function. When an encrypted password is cracked, YES, the hackers know that specific password. They brute forced it by guessing the password, running it through SHA1, and comparing the output to the hash. If they are the same, then they guessed the right password.

They do not know any other passwords and if "salt" was used, they would have to brute force each password. I think salt wasn't used in this case so once they crack someone's password, they know every other user who used the same password. So if you and I used the same password, and they brute forced yours already, they will know that I have the same password.

cjdavis• 14 years ago

It seems we will never get rid of bad programming like this. I hit the 'forgot my password' link on the T-Mobile website yesterday and the pop-up requested my T-Mobile phone number. Ten seconds later I received an SMS with my actual password in it.

toyg6• 14 years ago

The good thing is: every time this happens to a high-profile site, storing sensitive data, more people get more acquainted with the concepts of "you really should not use a simple password" and "you really should not use the same password across all sites". I know it works for me: this was the last straw that forced me to abandon a good ol' password I've been using since 1998. From now on I'll just rely on password managers (currently DataVault, but I know people who swear by LastPass).

toyg6• 14 years ago

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.

singlow• 14 years ago

Of course, now their password change script is broken/overloaded.

sopooneo• 14 years ago

How on earth were they not salting? There are so many open source auth systems now that get all the basics right. Someone who works at a big company like this and has any insight, please comment. How is this even possible in these days?

pjscott4• 14 years ago

There's still an unbelievable amount of ignorance out there about how to properly store hashed passwords. There are countless articles explaining that you need to hash the passwords, and telling you how to use md5("salt" + password), and then the blog comments are full of helpful people saying that you should use SHA256, or "no u also gots to add pepper", or exhorting the author to use a large unique salt from /dev/random (not /dev/urandom, it's not random enough) and then encrypt the salts in the database with 2048-bit RSA. I sometimes google around for these articles when I want some morbid fascination -- it's the intellectual equivalent of those YouTube videos where one car crashes into another, and then a third car crashes into the wreckage, and then another car tries to ramp over it and fails, and then everything explodes, and then the people staggering out of the destroyed cars start shouting bad advice about hash functions.

kamaal• 14 years ago

Can somebody recommend good reading material/book on how to handle passwords/encryption for practical everyday applications.

fhars• 14 years ago

http://codahale.com/how-to-safely-store-a-password/

alyandon• 14 years ago

Just adding my two cents worth. This file looks legit as I have a long, complex password on linkedin and the sha1 hash for it is present in the dump.

yashchandra2• 14 years ago

is this confirmed to be real or a hoax ?

flux_w42• 14 years ago

And here is the (partially) decrypted version with 163267 passwords: http://www.mediafire.com/?bq8bd5iojp50zci

hughw• 14 years ago

Even after securing our own passwords, we are all still vulnerable to attacks where the attackers simulate members of our networks to discover private information like our connections, job history, etc.

dredmorbius8• 14 years ago

Um, pardon the obvious question, but does someone have a direct link to the hash file?

rfugger2• 14 years ago

From a slashdot comment:

https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO...

dredmorbius8• 14 years ago

Thanks.

For anyone trying: it's not a direct link, but a download page (JS required) which lets you d/l "combo_not.zip". Which has 6458020 lines of "00000"-prefixed hashes, apparently sorted.

dredmorbius8• 14 years ago

I can confirm that my long-lived randomly generated single-use 12-character password hash is in the file, but not 00000-prefixed (apparently not broken).

A more recent 20 character single-use randomly generated password was not, but the file doesn't comprise the full 6.5 million hashes noted in stories.

I've since changed both for rather longer randomly generated single-use passwords.

chrisacky• 14 years ago

I've come to the conclusion that this list is genuine. While some people have said that they could't find their passwords in the list, I think this only points to the most probable reason in that this is a part list.

Password: "needajob"

    Hash:    e41b635974babd5d6e7d6dc68e8b3d2fc39938b2
    Cracked: 0000035974babd5d6e7d6dc68e8b3d2fc39938b2

statictype• 14 years ago

I literally created my LinkedIn account only 2 days ago. And my password was in the list and cracked. Thankfully I don't use it for anything else.

drewfrank• 14 years ago

Is it unique enough that you can be sure it's your password, and not someone else's? I ask because the cracked passwords seem to be the simple/obvious ones that are likely to be used by multiple people. If it is strong/unique though, it would effectively confine the hack time to the last 2 days.

daurnimator2• 14 years ago

Could be a dupe password? Is your password quite strong?

yashchandra2• 14 years ago

I just changed my password. To test, I entered only letters and numbers all in lowercase. Linkedin accepts it even though the site says "should have upper case etc.".

niels_olson• 14 years ago

could some other folks who have this database repost it? The existing sources (yandex, the original .ru site) seem to be clobbered.

whit537• 14 years ago

Here are a couple links to the file:

http://www.mediafire.com/?n307hutksjstow3 (RAR)

https://disk.yandex.net/disk/public/?hash=pCAcIfV7wxXCL/YPhO... (ZIP)

tantalor• 14 years ago

Maybe they read this SO thread?

http://stackoverflow.com/questions/2019279/what-is-the-recom...

weichi• 14 years ago

If we can't trust SO for security questions, where do we go to get them answered?

finnw2• 14 years ago

The SHA1 of my LinkedIn password naturally starts with "00000". I wonder if that would have thwarted the original cracking attempt.

I'm almost disappointed that mine was not in the list.

mcculley• 14 years ago

I can confirm that my password was in there. I have changed it. My password was "98mnja6z" which hashes to 6475590bc1407aa98c8b022230292cce3d8528b3. I used this for no other sites, so I'm not concerned about it leaking.

It is inexcusable that LinkedIn hasn't alerted their users yet.

docubot• 14 years ago

Mine is also in there. It was also a randomly generated password used only on LinkedIn.

dewatson• 14 years ago

Did not find my password in the list in truncated or original form. Member since April 2010, did not change my password even once.

smattiso• 14 years ago

Sorry where is the list?

jqueryin• 14 years ago

On my own accord and not my employers, I'd like to invite developers to check out mojoLive as your career management tool. Our goals and vision are light years ahead of what LinkedIn has slowly become. Also, I dislike recruiters and spam.

http://mojolive.com

hangas• 14 years ago

My belief is that the hackers might get the username password combos, but they grouped the hashes to only have unique (sort -u ?) passwords hashes and therefore ease the process of dictionary cracking them as they do not have salts. The 00000 prefix might be an indication of this. I bet there is an automate script taking care of a dict attack and the file was released during execution.

zer012• 14 years ago

Anyone looking for the file to run these tests yourself -> http://clck.ru/d/jE6Mg-5X1ARpN

geekin• 14 years ago

Terribly sorry to ask this - but where did you guys get the file ?

jneal• 14 years ago

My password isn't in the file, and yes I checked for a 0'd version as well. My password is 9 characters of lower case, upper case, numbers, and a symbol. I'm wondering if this is incomplete, or fake. Either way...if it is a vulnerability I suppose LinkedIn hasn't fixed it yet, or at least I haven't heard mention of this - thus even changing your password won't help much if they can just re-download the database. Thus making a long, complex password is the best course of action.

mahyarm• 14 years ago

A password I used many months ago (maybe almost a year now?) was in the list, but the password I use currently for many months was not on the list interestingly enough. This list is possibly pretty old, which means it happened quite a while ago.

whileonebegin• 14 years ago

A company as large and popular as LinkedIn uses no salt? Surprise.

zenocon• 14 years ago

If this is legit, shouldn't LinkedIn be notifying users of the security breach?

sakai• 14 years ago

A question from the cryptographically uninitiated -- how (and how easily) can these hashes be linked to a user's account name/email?

mynegation• 14 years ago

My password hash was in the file and it was cracked. It was a combination of 8 upper and lower case letters, digits and special characters. This is the case where size does matter and apparently passwords like my old one can be broken on GPU in minutes or hours nowadays.

Quick sample from persons I polled: 2 password hashes were not in the file, 1 was there and cracked, 1 was there and not cracked yet.

As bad as it is, this can be a great case to raise the awareness of good password management.

mistercow• 14 years ago

I'm starting to think it might be wise, if you intend to reuse your password on multiple sites, to salt it yourself. By using a form like "<site name><user name><reused password", you protect yourself from rainbow tables without making your username harder to remember.

And yes, yes, I know you shouldn't be reusing your password across different sites, or using a dictionary word anyway. And teenagers also shouldn't be drinking, doing drugs and having sex. It doesn't help anything to pretend that people are going to behave optimally.

Of course, the preposterous restrictions that websites put on passwords, like maximum password length, will make this idea harder to put into practice.

jwegan• 14 years ago

I've been doing this myself and it has worked out pretty well so far. My password is in the list of passwords released, but is uncracked and I can rest assured knowing that I did not use the same password on any other website.

A couple things to keep in mind:

1) The salt you generate should be put at the front in case the website is silently truncating the password to a certain length

2) The salt can be something more complicated than site name. I mentally calculate a fixed length salt based on the site name

3) You may want to still keep two separate "base" passwords, one for high value sites (banks, email) and one for low value sites (everything else).

Imagenuity• 14 years ago

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

henkert• 14 years ago

00000fac2ec84586f9f5221a05c0e9acc3d2e670 0000022c7caab3ac515777b611af73afc3d2ee50 deb46f052152cfed79e3b96f51e52b82c3d2ee8e 00000dc7cc04ea056cc8162a4cbd65aec3d2f0eb 00000a2c4f4b579fc778e4910518a48ec3d2f111 b3344eaec4585720ca23b338e58449e4c3d2f628 674db9e37ace89b77401fa2bfe456144c3d2f708 37b5b1edf4f84a85d79d04d75fd8f8a1c3d2fbde 00000e56fae33ab04c81e727bf24bedbc3d2fc5a 0000058918701830b2cca174758f7af4c3d30432

ErikCorry• 14 years ago

Am I the only one who is too paranoid to decompress a file that I know was created by a black hat...

http://www.symantec.com/avcenter/security/Content/2005.12.21...

eddieplan9• 14 years ago

Quickly check if your password has been cracked:

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

It will not send your password over the wire. It won't even send the SHA1 hash over the wire.

KenCochrane• 14 years ago

Use http://leakedin.org to find out if your password was hacked.

lordlicorice• 14 years ago

`pass` is uncracked?

antithesis• 14 years ago

It's nice to see a page translated through Google on the front page. It's an indication that technology is breaking some barriers.

narrator• 14 years ago

So LinkedIn... Why are you not using bcrypt to has your passwords?

http://codahale.com/how-to-safely-store-a-password/

heliodor• 14 years ago

As much as I hate lawsuits, I'd love to see one or two major Internet companies sued in a class action lawsuit for negligence to serve as an example and a warning to the rest. This kind of behavior from a top tier internet presence is inexcusable!

Hethrir• 14 years ago

Torrent of database: http://www.seedpeer.me/details/4368981/linkedin-hashes.html

Magnet link: magnet:?xt=urn:btih:VUPJHINO4KAWLWVLEKKFWKJVF3DVDDDR

Torrent download: http://www.seedpeer.me/download/linkedin_hashes/ad1e93a1aee2...

Zopieux• 14 years ago

It seems there are some duplicates, considering cracked hashes beginning with 000000. For instance, I found:

  passforlinkedin
  00000610754c30b38d0c70b72b7e8210268cd9b7
  b3534610754c30b38d0c70b72b7e8210268cd9b7

sildani• 14 years ago

My LinkedIn's password hash (at the time, I changed it once news broke) was not listed. And it was a relatively weak password (8 characters, just lower case characters and numbers). I doubt this is LinkedIn's password dump.

Aimes• 14 years ago

My old password is not on the list. However, it seems like somebody tried to log on to windows live with the e-mail address and password I was registered on linkedin with. This is one of my oldest passwords from when I still only had one or two passwords.

I noticed this as window live kept sending another of my e-mail accounts a code needed to log in from an unrecognised computer.

Now it could all be a coincidence, but I wouldn't be surprised if there was a connection, as the e-mail address and the password were identical to the ones used on Linkedin. If that's the case there would be a more complete list with my password/hash as well as the associated e-mail address.

mc32• 14 years ago

I checked a few 6 char passwords (alphanum) some were not present. So they seem not to be bruteforcing them serially. Maybe just checking against other known tables.

localhost007• 14 years ago

Here is the original file... http://filevelocity.com/ixhk76jz07m5/SHA1.txt_1.rar

925601568310• 14 years ago

Putting people's personal details on the open web, giving anyone access, including malicious hackers... This design used by LinkedIn, as well as Facebook, was a bad idea from the beginning. Don't think they are not aware of the risks. How much spam and other annoyances do people get as a result? These companies are killing privacy just to make a quick buck. Maybe they'll be sued.

Direct link to SHA1 file on mediafire (117MB) to avoid javascript, captchas, popups, etc.

http://205.196.120.123/c2o80hrlhteg/n307hutksjstow3/SHA1.txt...

jonah• 14 years ago

Hmm, my (short alpha) password isn't in the list.

dhughes• 14 years ago

The worst is I can't remember what password I used but don't want to change it because I want to know if it's one I used somewhere else not just reset it.

16s5• 14 years ago

John the Ripper released a patch for this modified sha1 hash type today. So no need for any manual hacks. You may download the patch here:

http://openwall.info/wiki/john/patches

bmacs• 14 years ago

I just made an online too to check if your password is in the list: http://billsnitzer.com/linkedin/

jtchang• 14 years ago

Is it scary to anyone else that LinkedIn can't confirm yet if their security was compromised?

sturmeh• 14 years ago

If your hashed password is not in this list (trunucated or not) do not assume for a second that whoever leaked this list had to leak all their lists.

Also note that according to other users, some of these hashes are at least 3 weeks old, they've had this list for some time.

disclosure2• 14 years ago

http://pastebin.com/JmtNxcnB - 20k++ sample cracked passwords from LinkedIn hash dump released on June 6, 2012. They do appear legit and strong too. It's unfortunate that LinkedIn hashed them using unsalted SHA-1.

sparknlaunch2• 14 years ago

Worth noting that some passwords belong to the dating website eHarmony. The dating site had a password beach last year.

http://arstechnica.com/security/2012/06/8-million-leaked-pas...

http://www.theregister.co.uk/2011/02/11/eharmony_data_breach...

grannyg00se• 14 years ago

How does this benefit someone who is trying to access an account? There are no account names tied to these hashes. So even if you managed to find the clear text of each of these you would still be in a position where you have a list of over 6,000,000 passwords to work through in order to brute force your way in.

disclosure2• 14 years ago

Searchable DB is available at http://dazzlepod.com/linkedin/

Ecio784• 14 years ago

They have added a blog post with an update http://blog.linkedin.com/2012/06/06/linkedin-member-password...

Unfortunately they dont tell when they started salting the password and if they've found (and fixed) the hole that permitted the database leak!

bermanoid• 14 years ago

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

gizzlon• 14 years ago

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

Think you might be expecting too much from large companies =/

adarshu• 14 years ago

Shocking that they didn't even use the basic technique of using salts before hashing!

ctdh• 14 years ago

No sign of my password in there http://www.mediafire.com/?n307hutksjstow3, or my wife's. I checked both the full and the '00000' truncated hash for each. Neither of us had changed it for the last couple of years.

So I guess it is only a subset of all the linkedin passwords?

I have now changed my passwords anyway.

By the way, the press say both the username and password were hacked, has anyone seen the list of usernames? They also say 6.4m passwords were hacked but this file only has 6.14m.

alexvay• 14 years ago

So I changed my password through my PC yesterday, went to my Android client and, to my surprise, it is logged on the mobile!

It's been more than 12 hours, and the access token for the mobile client is still connected to my account, despite changing my password.

I would expect all tokens to be revoked on-password-change. Really disappointing.

I'll have to set up an SSL proxy later to dump the traffic from Android, see what is happening. Anyone compiled SSLDump for Android?

Gigel• 14 years ago

Obviously the list was filtered to eliminate duplicates. It contains only what the hackers wanted it to contain. So, why does nobody mentions that it is HIGHLY LIKELY that the user names associated with the passwords (which are actually mainly e-mail addresses for LinkedIn) are also in the possession of the hackers. So, if I would be the hacker - strip usernames, strip duplicate hashes, post list of unique hashes to let others do the CPU intensive cracking, retrieve cracked passwords, match with usernames (e-mail address), check same password on other accounts (first on the e-mail account, then google the e-mail address on forums or try on the services that interests me and say "forgot password, send it again to this e-mail address - thank you telling me that this e-mail has indeed an account with you..."), monetize somehow the data. As a user that implies - IMMEDIATELY change your password for the e-mail address used to login at LinkedIn (if it was the same password); verify if settings of this e-mail account have changed (like an additional unknown address added to allow retrieval of the password, DUH), try to remember where you use the same address either as login or to recover credentials, try to remember where you used the same password, google you e-mail address to help you remember; change passwords; consider abandoning the e-mail address if it is not your primary one,... Also - did the amount of SPAM that you receive on the e-mail address used to login at LinkedIn suddenly increased, while SPAM remained constant on a similar mail account not connected to LinkedIn ? Maybe someone just sold your e-mail address, so the LinkedIn break may affect you even if the password is not in the list. Bottom line is - LinkedIn approach appears to be: We have no proof that this particular account was hacked since password hash is not in the list - let's not overreact and let'sassume it is not hacked even if we don't have a clue what was actually hacked. I'm not to judge if it is the best approach for the business, but sure as hell I don't like this approach as a user.

ttul• 14 years ago

Guys, this all doesn't parse for me. My password on LinkedIn was 13 characters long, and included symbols (!@#$%^&&*()), numbers, and alphabet characters. A 13-character password like this would imply a search space of (26 + 26 + 10 + 20) ^ 13 = BIG. If a GPU can check 11 billion passwords per second, this implies that someone ran 2.4 x 10^7 GPUs for a month.

We're either looking at someone with a seriously ridiculous password cracking computer (i.e. ASIC-based -- not even FPGAs), a compromise for SHA-1 (very unlikely), or a keylogger/proxy/trojan/etc... I vote for keylogger.

If your password is in this database, I don't think it's because your password was brute-forced.

johnvey• 14 years ago

I cross-referenced the leaked hashes against hashes of the 10,000 most common passwords and found that 93% of the passwords at least 6 characters long appear in the leak.

http://www.johnvey.com/blog/2012/06/93-of-top-passwords-appe...

It's always surprising that people are so lackadaisical about their passwords. I've had people tell me their passwords in casual conversation multiple times, just for the sake of discussion.

joninashby• 14 years ago

I deleted my account over 6 months ago but my password hash (strong unique password) is in the file. Either (a) the file retains passwords of deleted accounts, (b) the file was stolen over 6 months ago and LinkedIn didn't know about it, or (c) the file was stolen over 6 months ago and LinkedIn DID know about it and were hoping it wouldn't show up online.

jpgouigoux• 14 years ago

A salt may not have been enough to protect the passwords : if it is not complex enough, the presence of common passwords like "password" or "123456" make a brute-force attack on the salt itself possible in some case. I have performed a benchmark on that point in particular, and was able to retrieve a salt in five days, without strong optimization. A bit long to give all the numbers and code here, so the ref is http://gouigoux.com/blog/?p=46

6.5 Million LinkedIn Password Hashes Leaked

Related Stories