> Sony, Adobe and their ilk could learn a lot from this company.
And unfortunately they won’t listen…
I'm totally with you, and I suspect we may see a more technical explanation of the event in the coming days.
That said, this is a tough situation for Valve. They have many sorts of users, many of them who have no idea what MD5 hashing is or why it would be awful to use. You're already delivering bad news, so it may be wise not to make nontechnical users feel further discomfort at confronting terminology they don't understand.
In this, I feel like Valve has banked enough credibility for me to trust for the moment that they can evaluate their security and say "Oh, fuck, this will be cracked and it's only a matter of time," and then communicate that in clear terms in their message.
Edit: I should clarify - there certainly are examples of bcrypt being used, and I know there are tools available. But pick several random websites that have forums or user accounts and the number actually using it will be very small. That has been my experience once exposed to the code/infrastructure anyway.
https://code.djangoproject.com/ticket/15367
edit Let me also add... this is for auth/password hashing, not data encryption. To any people reading this: if you don't understand the difference, and you are responsible for writing web applications, then please read up on it.
The data that Valve was storing (CC info) needs to be encrypted and I'm assuming that data then needs to be unencryptable. They have to store the key because they have to be able to recover the plain text. With password hashing, you will never need to be able to recover the password.
https://github.com/mozilla/playdoh
It's what we use at Mozilla as the basis for most of our Django-based stuff, and gets you bcrypt password hashing -- even on older Django releases -- for free, along with some other niceties that probably need to find their way upstream soon :)
has_secure_password
Clarification: has_secure_password does NOT mean you choose between secure or non-secure password, it just mean "I want a password on this model, and better make it secure guys!"
> He says passwords were "hashed and salted." This could be anything from the naïve MD5(pass+salt) to the more secure bcrypt or PBKDF2. Now, I have every reason to believe that Valve is smart enough to not use methods like the first, but information is always welcome in a scenario like this.
Do these details actually matter to you, a technically savvy user? If they told you they used bcrypt or PBKDF2 for their password hashed and salted passwords would you think to yourself: "oh well, in that case I don't need to change my password" or are you going to take the few moments and change you password anyway? I'd probably just change my password.
For even less savvy users, they're getting technical details that they don't really care about now. Depending on where those details are in the message they might miss important bits of useful information.
I suppose if they said it was MD5(salt:pass) and you used the same password for steam and something else you might have reason to be concerned, but probably not unless they are targeting you specifically.
That said, I think any company should provide a link to a blog that does dig into the important technical details for people that want to know. And keep updating it as new information is found.
You'd be surprised.
The Steam Community is (or was when I checked, about a month ago) vulnerable to CSRF everywhere. Valve might hold their own when it comes to games, but I'm not too confident when it comes to the web development side of things.
When you assume that the attackers would have, or could get, at least one account which they know the password for, then if the hashing scheme is something they'll be able to crack en masse, then they are probably going to be able to figure out what the hashing scheme is, from their known plaintext.
As an example, here is an attack you may not have considered. If you wanted to make an authentication system, you would want to compare a password with a stored password (or hash). Most people would do a byte by byte comparison of the passwords (or hashes). The problem is, a byte by byte comparison takes longer for a correct password (even if you use hashes), as the incorrect answer exits on the first compare failure. This is called a timing attack, and is an example of a side channel. Most people wouldn't even know that such an attack existed. This is why you want to use a known algorithm, because the people who wrote them know these kinds of attacks. So if people know your secure algorithm, they shouldn't be able to exploit that knowledge.
Here are two links posted here recently, which show these concepts very well. The third is an hour talk about cryptography in general, and I highly recommend it.
http://carlos.bueno.org/2011/10/timing.html
http://syhw.posterous.com/two-amusing-side-channel-attacks
http://fosslc.org/drupal/content/everything-you-need-know-ab...
The passwords are hashed and salted using this:
md5(md5(password + user_salt)) md5(md5(password) + user_salt)Just re-checked... the line is this:
md5(md5($vbulletin->GPC['password']) . $vbulletin->userinfo['salt']))
That Steam forums requires a separate registration shows that there is unlikely to be any integration between Steam and the forum software.
However their point is that if you used the same username and password on both the Steam forums and Steam itself (with likely the same username) then by virtue of Steam forums being compromised, your main account should be considered compromised.
Because while some people have apparently received an e-mail they certainly are not contacting all their customers.
Even though Sony didn't quite apologise, they tried to squash legal action through contract changes(?) and offering a free game download(?) as a form of settlement.
Sorry but real mensch in tech never has its database compromised.
It's nice to imagine but that's not really how the world works. Perfection is impossible after any system reaches a certain level of complexity. The technical security implementation might have been airtight, but then a human factor compromised things in the end. Tough to say. Nonetheless, "be perfect" is not a reasonable strategy – or expectation.
> Valve should have improved its security after such an incident.
You've typed words here without really saying anything. Improved it how? Who's to say they didn't? Until and unless Valve gives us a post-mortem, we'll have no idea what the cause of the breach is. Nonetheless, it may include factors they never thought to consider.
Once you can perform a select statement, extracting data becomes pretty easy.
Sorry, but this is more than an inconvenience. It's a violation of user privacy that Valve didn't prevent.
I thought that the response from Newell was right on until that point. Left me with a bad taste in my mouth.
The message communicates exactly what happened in clear terms that don't try to cover anyone's ass. They explain which data was compromised and the potential implications. No double-talk. This could be an email you got from a friend or colleague.
The message conveys Valve's hope that the credit cards are secure but makes clear that users should be nonetheless vigilant about watching for suspicious activity. Just in case.
The message is signed by the head honcho of the company. Not some communications or PR weasel. It's in your inbox, not on some obscure blog.
Finally, it closes with:
"I am truly sorry this happened, and I apologize for the inconvenience."
Accepting responsibility, acknowledging that it's a fuckup, and showing some empathy for the fact that this completely sucks for their customers.
Sony, Adobe and their ilk could learn a lot from this company.