League of Legends database compromised, passwords hashed without salt

http://euw.leagueoflegends.com/news/league-legends-account-security-alert

by Strom • 14 years ago

93 104 14 years ago

euw.leagueoflegends.com

kirinan• 14 years ago

It says encrypted not hashed, these are not the same thing. Encryption uses keys and without the keys you can't get the value without a huge brute force effort. Hash without salt can be broken trivially. It'd bad either way but encrypted is way better than leaked hash.

sp332• 14 years ago

Later it says "We compared encrypted password hashes" so they are probably hashed.

cldrope• 14 years ago

That is an admission, otherwise this act would be futile.

"We think someone stole animals from our pet shop, so we compared the empty cages to filled ones to figure out..."

teamonkey2• 14 years ago

I was going to ask: is there actually any benefit salting a password that will be encrypted?

DanielRibeiro• 14 years ago

It is really kind-of very good practice to salt passwords. We've talked a bit about this recently here on HN:

http://queue.acm.org/detail.cfm?id=2254400

http://news.ycombinator.com/item?id=4082746

drivebyacct213• 14 years ago

Despite the other reply you got (which was my original 'lol'), no, there isn't an advantage to salting a password that is going to be encrypted with symmetrical encryption. I mean, what would that even mean?

Encrypt("salt"+"password", key) = ENCRYPTED_DATA

Decrypt(ENCRYPTED_DATA, key) = "salt"+"password"

Smerity• 14 years ago

I believe they mean hashed (as pointed out later in the article) but if it was encryption I'd disagree pretty strongly with the assertion it's safer than straight hashing.

If you don't need the original password, hashing should be used, not encryption. Hashing means there is no issue of key management as is the case with the encryption system. If those keys are mishandled then it's trivial to recover all the plaintext passwords.

Decryption would be difficult without the keys, but it's likely that (a) they have keys stored somewhere insecure or (b) they'd perform the encryption with a single key for all passwords. For (b), this means you simply had to have a valid account and you'd have a plaintext-ciphertext pair to bruteforce. Once that single key is extracted you'd have access to all the other passwords as well.

hackinthebochs• 14 years ago

Come on now, this is a PR release. Most users aren't going to know what "hashed" means, but most people do know what encrypted means. There's nothing to be deduced from their using the word encrypted.

Flam• 14 years ago

Just be sure you don't use your LoL password on any other game/email. The hackers will very likely test the info against your email and diablo 3.

eswangren• 14 years ago

Well, to be pedantic, there's no such thing as a "diablo 3" password, only a battle.net password. A WoW account is more lucrative.

dmak2• 14 years ago

Your weakest link is the website with the weakest security. Now they will try your password on your other accounts.

astrodust3• 14 years ago

Is there a good authentication system that doesn't involve storing passwords, hashed passwords, or encrypted passwords in the master database?

tantalor• 14 years ago

http://en.wikipedia.org/wiki/Federated_identity

chc5• 14 years ago

Federated identity doesn't replace passwords, it just punts the whole process of authentication to a third party. That third party will still need to authenticate the user somehow, which brings us right back where we started.

pcwalton• 14 years ago

There's Secure Remote Password, which stores a non-reversible verifier instead: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Apparently it's quite tricky to implement properly though.

astrodust3• 14 years ago

It's also quite tricky to explain to your investors and your customers that your password database was stolen.

Maybe some day there will be "Security as a Service" where someone helps you do this properly.

uvdiv• 14 years ago

Cryptographic hashes are "non-reversible" too. But they're both vulnerable to offline dictionary attacks if the attacker obtains the host's secrets -- which I think is what `astroduck' was really asking about, leaked server databases like this news story.

(I don't see how there's any possible protocol that behaves otherwise: if Alice is capable of proving she possesses a secret to Bob through a protocol, then Bob can always discover Alice's secret by playing that protocol with himself, enumerating every possible secret until the protocol succeeds. And so can anyone who knows everything that Bob knows about Alice's secret.)

The SRP paper doesn't say much about this except that brute-force dictionary attacks are "expensive". I don't think they make specific claims about computational hardness like scrypt. The paper was written in 1997.

"An attacker who captures the host's password file cannot directly compromise user-to-host authentication and gain access to the host without an expensive dictionary search."

http://srp.stanford.edu/ndss.html

nnnnnnnn2• 14 years ago

Yes. A great, practical and scalable example is found in ssh: http://en.wikipedia.org/wiki/Secure_Shell#Key_management I'll try to explain how it works in non-technical terms (so please don't nitpick as I'm glossing over details)

User generates a public and private keypair. The public key is given to the remote site (such as LoL or Linkedin), but the public key is not secret -- it is public. You can post it on your blog, whatever. You can use it for multiple accounts without concern.

The public key allows one to encrypt some data, but the public key cannot decrypt the data.

The private key can decrypt the data.

When the user wishes to log in the remote site, using the public key, encrypts a random string and sends it to the user. If the user manages to successfully decrypt this random string and send it back then the remote site can infer that the user holds the private key -- because only the private key can perform the decryption.

The private key is never sent to a remote party. Only meaningless random strings are communicated over the wire.

The (significant) drawback to this method is that the user will have to have the private key with them in order to perform the authentication. But perhaps mobile devices will solve that problem for us.

astrodust3• 14 years ago

I would love to see an ssh-like key exchange built into browsers. You add your key to the site, GitHub style, and then you use that for auth. No more nonsense with OAuth or "remember my password" or the remote site having your password just because they grabbed the DB. It's just a useless public key to them.

pbreit• 14 years ago

No. Simple passwords properly stored and monitored provide the best balance between user experience and security.

TimJRobinson• 14 years ago

All these sites have to do is store the passwords using bcrypt and with salts and they're pretty much uncrackable (as far as we know).

The reason they're uncrackable is because when using bcrypt it takes a second or more to generate a hash for a password (compared to 0.000001 seconds for md5) meaning if they want to try and brute force the password or build a rainbow table it'll take them years instead of seconds to crack each password.

There's no need to remote password storage, they just need to learn more about password security.

larrik• 14 years ago

European servers only, according to their release.

mrleinad• 14 years ago

That sounds like a really proffessional letter to their users. Brief, honest, precise, and they clearly state what their action items to prevent this from ever happening again will be. I like it a lot.

smoyer2• 14 years ago

Is "info" acceptable in professional business communications now? I don't mind that it's friendly and informal, but I also wouldn't call it professional.

chc5• 14 years ago

Looks like it's only the EU databases that were compromised, so if you have an NA account like I imagine most people here here would, no need to panic (though changing your password anyway won't hurt anybody).

thaumaturgy3• 14 years ago

We can't actually tell much about their password storage mechanism from that post. For one, they mention "encrypted hashes", which might mean encryption, might mean hashes, or might mean both; for two, they don't describe how they determined which users had weak passwords. If they were using some kind of reversible encryption scheme, it's possible that they ran that function against their database and determined common passwords that way.

I'll give them the benefit of the doubt, unlikely as it may be, because if they were in fact doing something as stupid as SHA1 or MD5 or ROT13, and they still opened their post with "Keeping player information secure is very important to Riot", then somebody needs to be strangled as an example to other mealy-mouths.

I also take issue with telling your users what kind of passwords to use. If you're storing passwords correctly, and if you're blocking brute force attempts, it almost doesn't matter what password your users are using. (Almost: somebody could still try "password" on an account and get lucky if it's one of the 10,000 accounts with that password.)

drivebyacct213• 14 years ago

No. God, I hope we don't find out they're use symmetric encryption. Do I need to explain why that's a stupid idea?

In case I do: 1) The site doesn't need my password in plaintext. 2) If the server is compromised, the attackers don't just have salted or unsalted hashes THEY HAVE FULL PLAINTEXT PASSWORDS (unless it's some weird case where they have DB but not FS access).

No, either way, they're wrong.

(Sigh, I'm sorry for the snippiness, I'm just tired of coming into everyone of these threads with people who earnestly try to regurgitate what they heard from the last thread about this and manage to give bad advice or implications.)

thaumaturgy3• 14 years ago

No, you didn't need to explain that. (I hear ya though.)

Yes, they are probably wrong. However, unlike the recent LinkedIn leak, at the moment we know almost nothing about how they were storing passwords. (Although, according to a thread on their forums, they did leave a user's previous and current passwords both simultaneously active -- not a good sign.)

I think that HN didn't used to so readily confuse speculation and facts.

jemfinch• 14 years ago

"We compared encrypted password hashes and discovered that 11 passwords were shared by over 10,000 players each."

You can't do that with salt. That's half the point of salting.

thaumaturgy3• 14 years ago

Of course you can. It's just more computationally expensive.

I realize that it's super unlikely that that's what they did, but that doesn't change the fact that at the moment all we know about their password storage system comes from a badly worded PR piece.

confluence• 14 years ago

Is it just me or have the number of announcements on HN about password leaks gone up in the last few weeks?

I think availability bias is kicking in, with each additional announcement, more links about announcements are posted (for karma) or more sites feel like they can announce, under the cover of larger leaks, that they themselves have been compromised.

Probably just me.

[1] http://en.wikipedia.org/wiki/Availability_heuristic

mistercow• 14 years ago

It seems to me that there have been a few more lately than usual. I'm all for it though; the only way sites are going to start treating passwords responsibly is if they're embarrassed into doing it.

duaneb• 14 years ago

I'm OK with that. Hash leaks are big news.

jsprinkles• 14 years ago

Not just the last few weeks, the last few days. I was already drawing that conclusion before this disclosure, and internally speculating that the same group or person might be responsible.

IsTom• 14 years ago

I haven't seen what was the weakness exploited in all these attacks -- perhaps it's a common vulnerability that was discovered by a group of bad guys.

SoftwareMaven2• 14 years ago

I'm nearly positive the US code salted the hashes (it's been a long time since I was in that code :). I say US code because (again, memory is dim) I think they had a partnership with a company in the EU and that (might have) included authentication.

The platform guys at Riot were the sharpest group of engineers I've worked with. Smart and able to get stuff done without bike shedding. They did stuff right.

cpeterso• 14 years ago

Why would the US and EU installations have different code or database schemas?

arkem2• 14 years ago

Due to the strange syndication/franchise model that Riot has used in the past when setting up in regions other than North America.

If I remember correctly the franchisee gets source access and can write their own game lobby code if they like.

K2h• 14 years ago

I forgot what bike shed was. It is focusing on trivial things

http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality

yesyes• 14 years ago

http://bikeshed.org

mrb6• 14 years ago

It is possible to tell the passwords were unsalted because: "We compared encrypted password hashes and discovered that 11 passwords were shared by over 10,000 players each" and one of the points of salting is to make impossible to identify identical passwords from the hashes.

arkem2• 14 years ago

Parent is talking about the League of Legends North American region which does not necessarily share its authentication code base with the European regions which were the ones compromised.

chc5• 14 years ago

Not really. You get that with per-password salting, but having a single salt for your whole database is not uncommon. Since the main point of salting AFAIK is to ward off rainbow tables, it's better than nothing.

EDIT: As noted in the comments, the way I put this originally was kind of flip and misleading and I apologize for creating confusion. My point was that I've seen a number of places do it that way, so just throwing at at your problems doesn't necessarily fix everything.

drivebyacct213• 14 years ago

You left out an 'un' in front of salted. Or you're wrong. I'm hoping you just mistyped. [edit :)]

3143• 14 years ago

Really? They always seemed quite incompetent to me. Upgrades frequently took 3 to 4 times as long as planned. Unscheduled downtimes happened at least once a week. Matchmaking took forever even when servers were busy, and when asked about it on the forums, the developers described their matchmaking algorithm as one that ran in n!! time on the numbers of players looking for a game.

dawkins• 14 years ago

Ante one knows how they got access to the database?

TwiztidK• 14 years ago

I don't understand why this keeps happening. When someone designs the user/password model for a website or software do they serious not even consider properly encrypting the passwords? This is not rocket science, implementing a relatively secure password hashing setup takes a minimal amount of work. Hell, adding a salt is an extra field in the database, an extra line of code when creating a user and an extra "+salt" when computing the hash.

I honestly think they spend more time coming up with ridiculous password requirements than actually encrypting the passwords. Possible dialog:

Dev 1: The passwords must have at least one symbol, one number, no dictionary words, and it can't be longer than 15 characters.

Dev 2: That'll be pretty secure, which hashing functions should we use? And should we salt it?

Dev 1: I think MD5 should be secure enough and salts are just overkill.

drivebyacct213• 14 years ago

Your post would be more convincing if you didn't inaccurately refer to this as "encryption".

mfjordvald• 14 years ago

Technically hashing is one-way encryption, so while ambiguous it's not exactly completely wrong.

drivebyacct213• 14 years ago

Good god, this topic is discussed to death and yet there are spreading very inaccurate, insecure crap in this thread. I think everyone needs to stop giving advice and speculating about what is "good" and defer to a security expert or a set of codified best practices. I just don't understand how some people seem to understand salting, hashes or encryption but not enough to understand why unique-per-user salts are important, why asymmetric and symmetric encryption differ or why encryption has nothing to do with this style of password storage. If you don't understand these things, stop giving security advice in these threads.

drivebyacct213• 14 years ago

To whomever downvoted me, I've seen people suggest on this thread or ones in the last 24 hours that:

- symmetric encryption is appropriate for sites' storing passwords

- md5 is okay

- site-wide salts are just as secure as user specific salts

and more. Some of these were suggested by people that have far, far more karma than me. Some were suggested by people that had had this explained to them in previous threads and then took it upon themselves to mis-convey this information back. I don't have a pony in this race as I use different strong passwords per-site and I don't have user data to worry about. I just cringe everytime I see potential hackers reading this misinformation or hackers potentially with data who don't understand their risk or blindspots. I only mean the best, even if I come off exasperated.

smoyer2• 14 years ago

Don't forget the guy that salted his own passwords - googlepassword, linkedinpassword, yahoopassword (yeah ... he probably has a Yahoo account).

rrreese• 14 years ago

I sense a lot of misinformation in the comments, do you know of a site or book that covers the best practices that we should be using?

Karunamon2• 14 years ago

>but not enough to understand why unique-per-user salts are important

I don't think that's been covered in this thread. If the main point of salting is to make rainbow tables ineffective, a single DB-wide hash still does that. Presumably if a hacker gets a copy of your entire database, they still don't have a copy of your hashing function with that salt. So then they're reduced to brute force.

Something else that I just thought of is, if you're salting per user, where does that salt get stored? A secondary database?

..And then come to find out it's been discussed down thread. Oops.

tzs• 14 years ago

Any competent security architect will assume that if the bad guy gets a copy of the entire password database he also gets a copy of the entire codebase, all design documents, installation instructions, and operations manuals, and designs the system to be secure against that.

gcr• 14 years ago

LinkedIn, LastFM, League of Legends... What is with this disturbing trend of websites beginning with L being cracked all in the same week?

newobj• 14 years ago

Well obviously the bad guys are just going through the phone book one by one.

Karunamon2• 14 years ago

Well we haven't had a good Microsoft service hack for a while. Microsoft Xbox Live next?

molmalo• 14 years ago

Maybe a competence between groups, with one of the rules being "the domain must start with L" :) OR maybe just a coincidence...

keymone• 14 years ago

every beginner scripting kiddie now knows to at least salt their hashes

who is working for riot then? seriously who?

gcb• 14 years ago

What's not compromised this week?

Anything special happening? Is it Friday 13 and stoner dot something again? Heck even the kitchen computer at my grandmas house may have been target this week... Hopefully that one had salt. Tum dum tiss.

mingpan• 14 years ago

Keep in mind that the target audience of this post is a largely nontechnical user base. These days, average people are getting a general idea of the meaning of "encrypt" due to the prevalence of, e.g. SSL in e-commerce, but not necessarily the meaning of "hash". Thus, it's not uncommon that places will intentionally misuse these words in order to reach a nontechnical audience.

facorreia• 14 years ago

To me, it adds insult to injury when companies that fail to take the most basic, well-known measures to protect their login databases always tell us how much they value the security of user information.

That would only be acceptable if the next words were, "and therefore we have fired the CTO and all programmers involved".

Freestyler_3• 14 years ago

If they got my account info... not a big deal. all my high priority pass' have unique passes managed by keepass.

League of Legends database compromised, passwords hashed without salt

Related Stories