> Sony, Adobe and their ilk could learn a lot from this company.
And unfortunately they won’t listen…
> 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.
has_secure_password
in the model and you're away.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!"
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 :)
> 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))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.
md5(md5(password) + user_salt)Just re-checked... the line is this:
md5(md5($vbulletin->GPC['password']) . $vbulletin->userinfo['salt']))
I got confused by the last bracket closing an outer conditional.