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.
League of Legends database compromised, passwords hashed without salt
61–70 of 109 posts
Re: League of Legends database compromised, passwords hashed without salt
#62I 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".
Re: League of Legends database compromised, passwords hashed without salt
#63Earlier quoted context omitted.
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.
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.
"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.
Re: League of Legends database compromised, passwords hashed without salt
#64Earlier 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.
You left out an 'un' in front of salted. Or you're wrong. I'm hoping you just mistyped. [edit :)]
Oops. Fixed. Thanks.
Re: League of Legends database compromised, passwords hashed without salt
#65Earlier 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.
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.
Ok. That would make sense. The parent seemed to claim the leaked passwords were salted.
Re: League of Legends database compromised, passwords hashed without salt
#66Earlier 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.
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?
Re: League of Legends database compromised, passwords hashed without salt
#67LinkedIn, LastFM, League of Legends... What is with this disturbing trend of websites beginning with L being cracked all in the same week?
Re: League of Legends database compromised, passwords hashed without salt
#68LinkedIn, LastFM, League of Legends... What is with this disturbing trend of websites beginning with L being cracked all in the same week?
Well obviously the bad guys are just going through the phone book one by one.
Re: League of Legends database compromised, passwords hashed without salt
#69Earlier 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?
Technically yes, but don't use md5 for anything security-related ever. It's broken. http://www.mscs.dal.ca/~selinger/md5collision/ is just one example. (I also remember reading some years ago that md5s within md5s can make the resulting hash more vulnerable to certain attacks but I don't have any formal knowledge in cryptology to say for sure.) Use bcrypt/scrypt and you're automatically protected from both rainbow tables and brute force.
Re: League of Legends database compromised, passwords hashed without salt
#70Earlier 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…
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.