Live data from Hacker News

League of Legends database compromised, passwords hashed without salt

euw.leagueoflegends.com

41–50 of 109 posts

Re: League of Legends database compromised, passwords hashed without salt

#41

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.

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

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.

Re: League of Legends database compromised, passwords hashed without salt

#42
post #32

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.

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.

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.

Re: League of Legends database compromised, passwords hashed without salt

#43
post #30

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.

I forgot what bike shed was. It is focusing on trivial things http://en.wikipedia.org/wiki/Parkinsons_Law_of_Triviality

http://bikeshed.org

Re: League of Legends database compromised, passwords hashed without salt

#44
post #41

Earlier quoted context omitted.

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

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.

Exactly this. They did the same thing with Ten Cent in China, I believe.

Re: League of Legends database compromised, passwords hashed without salt

#45

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 comm…

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

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.

Re: League of Legends database compromised, passwords hashed without salt

#46

Earlier quoted context omitted.

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

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"

Thanks. I'm no security expert but I couldn't see how it would make a difference.

Re: League of Legends database compromised, passwords hashed without salt

#47
post #42
post #32

Earlier quoted context omitted.

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.

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 th…

A single salt for the whole DB is not salting. It is no different than a (custom) hash function, which does not prevent identifying identical passwords, and which does not prevent rainbow table cracking.

Re: League of Legends database compromised, passwords hashed without salt

#48

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

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

Re: League of Legends database compromised, passwords hashed without salt

#49

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 comm…

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…

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.

Re: League of Legends database compromised, passwords hashed without salt

#50

Earlier quoted context omitted.

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"

Thanks. I'm no security expert but I couldn't see how it would make a difference.

Sure, to help illustrate it further: (don't use SHA1, I'm using it to avoid a discussion of why you wouldn't manually use a salt with bcrypt)

user1: SHA1("salt123"+"puppydog11") = SOME_HASH

user2: SHA1("salt456"+"puppydog11") = SOME_DIFF_HASH

This way, even for the same password, there are different salts, and thus different hashes. No one can run a rainbow attack unless they've generated rainbow tables for that salt (frankly, it would be possible, but useless to generate a rainbow table for a specific salt)

Post reply on HN