7 ms·
League of Legends database compromised, passwords hashed without salt
- astrodust 14y agoIs there a good authentication system that doesn't involve storing passwords, hashed passwords, or encrypted passwords in the master database?
- tantalor 14y agohttp://en.wikipedia.org/wiki/Federated_identity http://en.wikipedia.org/wiki/Federated_identity
- chc 14y agoFederated 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.
- dbecker 14y agoBut it allows the passwords to be stored by someone who specializes in security. It'd be nice if everyone who runs a non-trivial website stayed was a security expert, but we're also busy with other aspects of the site.
- pcwalton 14y agoThere's Secure Remote Password, which stores a non-reversible verifier instead: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol Apparently it's quite tricky to implement properly though.
- astrodust 14y agoIt'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.
- timtadh 14y agoI believe @tptacek will gladly accept your money for this service. As will Cigital.
- drivebyacct2 14y ago"Security as a Service" that does what? Teaches you how to store data securely, explain to investors that user data was stolen or an outsourced password verification utility. The first can be done if people would bother to learn and completely understand what they're doing (this thread and the corrections I've had to make seems to prove that people think they know what they're doing when they don't). The second, have fun with. The third is already solved. oAuth, OpenID, Facebook Connect, Twitter, BrowserID, etc.
- uvdiv 14y agoCryptographic 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 http://srp.stanford.edu/ndss.html
- nnnnnnnn 14y agoYes. A great, practical and scalable example is found in ssh: http://en.wikipedia.org/wiki/Secure_Shell#Key_management 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.
- astrodust 14y agoI 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.
- Zash 14y agoSSL Client certificate authentication has existed in browsers for a long time. Browsers even have built in key generation, but noone uses it. Probably because the UI is not very good. Mozillas new BrowserID scheme is pretty similar to this too.
- nnnnnnnn 14y agoPKI as implemented by SSL Certs is needlessly complicated, which is a big part of why no one has adopted it for end user authentication. Compare what I described above to the mess described here: http://en.wikipedia.org/wiki/Public-key_infrastructure http://en.wikipedia.org/wiki/Public-key_infrastructure A decentralized key system as ssh provides is much more appropriate for end users.
- pbreit 14y agoNo. Simple passwords properly stored and monitored provide the best balance between user experience and security.
- TimJRobinson 14y agoAll 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.
- kirinan 14y agoIt 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 14y agoLater it says "We compared encrypted password hashes" so they are probably hashed.
- cldrope 14y agoThat 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..."
- teamonkey 14y agoI was going to ask: is there actually any benefit salting a password that will be encrypted?
- DanielRibeiro 14y agoIt 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://queue.acm.org/detail.cfm?id=2254400 http://news.ycombinator.com/item?id=4082746 http://news.ycombinator.com/item?id=4082746
- drivebyacct2 14y agoDespite 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"
- 14y ago
- Flam 14y agoJust 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.
- larrik 14y agoEuropean servers only, according to their release.
- mrleinad 14y agoThat 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.
- smoyer 14y agoIs "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.
- chc 14y agoLooks 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).
- thaumaturgy 14y agoWe 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.)
- BiWinning 14y agoSo if SHA1 or MD5 or ROT13 is stupid, what is not stupid?
- drivebyacct2 14y agoNo. 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.)
- thaumaturgy 14y agoNo, 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.
- confluence 14y agoIs 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 http://en.wikipedia.org/wiki/Availability_heuristic
- mistercow 14y agoIt 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 14y agoI'm OK with that. Hash leaks are big news.
- jsprinkles 14y agoNot 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 14y agoI 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.
- SoftwareMaven 14y agoI'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 14y agoWhy would the US and EU installations have different code or database schemas?
- arkem 14y agoDue 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.
- SoftwareMaven 14y agoExactly this. They did the same thing with Ten Cent in China, I believe.
- tetha 14y agowhich is a terrible decision for users that registered before EU exists, just in case you have similar buisness plans.
- K2h 14y agoI forgot what bike shed was. It is focusing on trivial things http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality
- yesyes 14y agohttp://bikeshed.org http://bikeshed.org
- Jebus 14y agoAnother reason to play Dota 2
- dawkins 14y agoAnte one knows how they got access to the database?
- TwiztidK 14y agoI 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.
- drivebyacct2 14y agoYour post would be more convincing if you didn't inaccurately refer to this as "encryption".
- mfjordvald 14y agoTechnically hashing is one-way encryption, so while ambiguous it's not exactly completely wrong.
- drivebyacct2 14y agoGood 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.
- drivebyacct2 14y agoTo 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.
- smoyer 14y agoDon't forget the guy that salted his own passwords - googlepassword, linkedinpassword, yahoopassword (yeah ... he probably has a Yahoo account).
- tetha 14y agoHow is this bad? I mean sure, if you can get access to one password, you will be able to predict passwords for other websites, however, these SALT + WEBSITE-passwords tend to end up very, very long, which makes it very hard to break. Afterall, every single password you listed there is at least 13 characters long.
- gcr 14y agoLinkedIn, LastFM, League of Legends... What is with this disturbing trend of websites beginning with L being cracked all in the same week?
- newobj 14y agoWell obviously the bad guys are just going through the phone book one by one.
- Karunamon 14y agoWell we haven't had a good Microsoft service hack for a while. Microsoft Xbox Live next?
- molmalo 14y agoMaybe a competence between groups, with one of the rules being "the domain must start with L" :) OR maybe just a coincidence...
- keymone 14y agoevery beginner scripting kiddie now knows to at least salt their hashes who is working for riot then? seriously who?
- gcb 14y agoWhat'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 14y agoKeep 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 14y agoTo 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 14y agoIf they got my account info... not a big deal. all my high priority pass' have unique passes managed by keepass.