Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

League of Legends database compromised, passwords hashed without salt

euw.leagueoflegends.com

Post reply on HN
Print view View original

71–80 of 109 posts

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

#71

Post by drivebyacct2 »

bobobojer wrote: post #66
drivebyacct2 wrote: post #59

Earlier quoted context omitted.

What? So if I have access to that salt, I generate a new rainbow table and get a huge percent of your users. The point of salting is to make rainbow tables no more efficient than brute forcing. If each user has a unique salt, there's literally no benefit to generating a rainbow table.

Out of curousity - is it a salt if you do something like this: salty = md5(md5(pw) . pw . 'poniesaremagical' . md5(username));? It is per-user... how is it different than using a timestamp which will be as unique as username?

Yes, as long as you use some salt data that is unique per user (timestamp, random number/guid/whatever) (you have to store that obviously), then it's fine. The problem is acting as if a site-wide salt is an ok-thing. It's not.

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

#72

Post by mfjordvald »

drivebyacct2 wrote: post #62
TwiztidK wrote: post #60

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

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

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

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

#73

Post by deathmonkey »

thaumaturgy wrote: post #49
drivebyacct2 wrote: post #25

Earlier quoted context omitted.

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…

A lot of game companies don't get valid email addresses from most of their user baseso if they don't have a good email to authenticate a password reset, leaving the old password active sometimes is the only option to authenticate users for a password reset.

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

#74

Post by mrb »

FreakLegion wrote: post #70
mrb wrote: post #47

Earlier quoted context omitted.

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.

Preventing rainbow table attacks is exactly what a custom hash function would do. You can't precompute hashes if you don't know the hash function. But you're right that a single salt in conjunction with a known hash function generally provides little additional protection, although this depends on the size of the salt.

A good cryptographer assumes that a custom hash function does not prevent rainbow table attacks, because he should not assume the algorithm will remain secret (security by obscurity, yadi, yada).

The right way to prevent a rainbow table attack is to computationally prevent it via unique salts.

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

#76

Post by jrockway »

astrodust wrote: post #16
nnnnnnnn wrote: post #15

Earlier quoted context omitted.

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

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.

It's built in. Many companies use it internally.

In fact, I can't think of any VPN I've ever connected to that didn't require a machine certificate. Cisco VPNs I've used require it, as does my own personal VPN.

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

#77

Post by zhoutong »

drivebyacct2 wrote: post #59
chc wrote: post #42

Earlier quoted context omitted.

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…

What? So if I have access to that salt, I generate a new rainbow table and get a huge percent of your users. The point of salting is to make rainbow tables no more efficient than brute forcing. If each user has a unique salt, there's literally no benefit to generating a rainbow table.

Then the rainbow table can only be used with this specific site. This makes it no more efficient than brute forcing. You can store the hashes yes, but you can also include the cracked passwords in the dictionary and it takes only slightly more time to compute them even with unique salts.

Site-wide salting has almost the same security as per-user salt, as long as the salt is not leaked or cracked before the database is leaked for pre-computation.

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

#78

Post by xkcdfanboy »

mrb wrote: post #74
FreakLegion wrote: post #70

Earlier quoted context omitted.

Preventing rainbow table attacks is exactly what a custom hash function would do. You can't precompute hashes if you don't know the hash function. But you're right that a single salt in conjunction with a known hash function generally provides little additional protection, although this depends on the size of the salt.

A good cryptographer assumes that a custom hash function does not prevent rainbow table attacks, because he should not assume the algorithm will remain secret (security by obscurity, yadi, yada). The right way to prevent a rainbow table attack is to computationally prevent it via unique salts.

Yes but it's not like the random hacker has a 600 gig rainbow table for MD5('DATSALT' + PW). If you REALLY want to do the right thing when it comes to storing passwords, you need to use a hash algo that is computationally hard enough to brute force, it should take at least .5 sec on a good computer to compute. Every couple years, you should add another pass of the algorithm, ie. F(F(X)), to compensate for faster computers. By adding the extra pass, you won't need the original password to generate the new, revised, stronger custom hash algo. If you do this, in 10 years your passwords will still be secured. Also, salt your passwords with each a unique at least 100 random bytes, shouldn't need to be said.

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

#80

Post by drivebyacct2 »

zhoutong wrote: post #77
drivebyacct2 wrote: post #59

Earlier quoted context omitted.

What? So if I have access to that salt, I generate a new rainbow table and get a huge percent of your users. The point of salting is to make rainbow tables no more efficient than brute forcing. If each user has a unique salt, there's literally no benefit to generating a rainbow table.

Then the rainbow table can only be used with this specific site. This makes it no more efficient than brute forcing. You can store the hashes yes, but you can also include the cracked passwords in the dictionary and it takes only slightly more time to compute them even with unique salts. Site-wide salting has almost the same security as per-user salt, as long as the salt is not leaked or cracked before the database i…

>This makes it no more efficient than brute forcing.

Jesus, no. It absolutely does make it more efficient than brute forcing each password.

I compute one rainbow table that I can run against 10,000 users. Or I brute force 10,000 users' passwords because they have unique salts.

>_oh sweet jesus of irony, you're the guy that was wrapped up in Bitcoinica.

Post reply on HN