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
101–109 of 109 posts
Re: League of Legends database compromised, passwords hashed without salt
#102Good 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 impo…
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…
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?
Re: League of Legends database compromised, passwords hashed without salt
#103Earlier 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?
It's not salty enough for my taste. What you've done is no different than:
H(H(Password) + Salt)
A simple change makes this comparison impossible:
salty = H(H(Password + Salt)
Always assume your salting method is public, even if you make attempts to keep it secret. And remember that your site isn't in isolation; your user and every site they interact with are also potentially weak links in the chain.
Note that the examples above are oversimplified. You should look to a better authority on how to properly store passwords. In a future leak, we'll be surprised that the sites involved only salted their passwords.
Re: League of Legends database compromised, passwords hashed without salt
#104Good 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 impo…
>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 j…
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.
Re: League of Legends database compromised, passwords hashed without salt
#105Earlier quoted context omitted.
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.
Oh, I got it. My brain wasn't working then.
Don't worry, I use per-user salts for all my web projects following all security best practices that I know.
Re: League of Legends database compromised, passwords hashed without salt
#106Is there a good authentication system that doesn't involve storing passwords, hashed passwords, or encrypted passwords in the master database?
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.
Re: League of Legends database compromised, passwords hashed without salt
#107Earlier 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.
which is a terrible decision for users that registered before EU exists, just in case you have similar buisness plans.
Re: League of Legends database compromised, passwords hashed without salt
#108Earlier quoted context omitted.
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…
Don't forget the guy that salted his own passwords - googlepassword, linkedinpassword, yahoopassword (yeah ... he probably has a Yahoo account).
How 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.
Re: League of Legends database compromised, passwords hashed without salt
#109Earlier 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…
normally salt is some random string unique for each user, but you have to store the salt of each user in database for authentication, if your database is hacked and they got both your hash and salt, it is really no difference between salt and no-salt