You are absolutely right, and I really appreciate this from Valve. There is only one thing that would have made it better: even more info. 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. There should be no reason to hide your cryptography method provided that it is secure.
> Sony, Adobe and their ilk could learn a lot from this company.
> There should be no reason to hide your cryptography method provided that it is secure.
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.
if they use a weak "hashing and salting" scheme they are more likely to get a mob with pitchforks at their gates than if they are left in the dark hoping it's bcrypt with 200 stretches.
The Use bcrypt rant comes up on HN a lot, but I've actually never seen a website that uses bcrypt or PBKDF2 in the real world. Hell, I rarely encounter developers or admins who even know what it is. I doubt it was more than md5+salt, but maybe.
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.
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.
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 :)
Because it adds a few attributes (like 'password') and methods (like 'authenticate') to your model, and you might not really want such things on every one of your models.
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!"
Wow, that's probably the first web framework I've seen that is more polished than the server it runs on top of; my experience with mongrel2 is that it's still a bit rough around the edges.
I administer a community news and public affairs site. Early this year, after reading about bcrypt on hacker news, I witched the site authentication to bcrypt from salted md4 hash. http://raisethehammer.org/blog/2084
The statement "I've actually never seen a website that uses bcrypt or PBKDF2 in the real world" doesn't discredit the "Use bcrypt[/PBKDF2]" argument, though.
I think you'll probably find a whole lot of examples if you use a dataset of websites, webapps, and desktop/server apps made in the last decade. I work in business and enterprise application development, from simple webapps to complex systems on massive servers and I've been using and evangelizing bcrypt use around my circle for quite some time. At this point, most of the people I've encountered that are in charge of systems needing some type of encryption for their user data use bcrypt. I think most of the decent developers around the world already know of the perils of using weak encryption algorithms.
The company I am with just moved from plaintext in-database password storage to using bcrypt with their latest product release, FWIW. It was either that or I left, heh.
My curiosity side agrees with you, but my practical side does not.
> 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.
Personally, I don't think I'm going to bother to change my password since it's a 64-character or so generated one for their site only and they don't have my credit card info. But I can see some reasons why I would care about the details of their encryption method. If it's MD5(pass+salt) then most people probably need to go change it, along with any other sites they're using that password at, and possibly mess up their evening a bit. If it's something silly but better like sha512(sha512(...(pass)...)) enough times such that it takes a good chunk of time for any password, or even better bcrypt, then most users can relax and change it when they can get around to it.
> Now, I have every reason to believe that Valve is smart enough to not use methods like the first
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.
The issue may be more complex. Steam has been around for awhile now -- there may be an Amazon.com like issue where new passwords are secure, but older passwords are using crypt or something!
I'd say its possible, but unlikely; and you'd hope its not a major factor in practice.
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.
In general, if you are depending on a secret cryptographic algorithm, then you are doing something wrong. Cryptographic algorithms are horribly complicated, with many attack vectors you need to know, and prevent. Chances are, someone writing their own code isn't going to make a secure system. By using a known, secure system, it doesn't actually matter if people know what it is. A known system has been tested, and deemed to be 'secure'. If knowing the name did mean they could exploit it, then it probably isn't a good system to be using in the first place.
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.
Not for Steam forums they don't, they're using vBulletin and it doesn't appear to be modified beyond the theme.
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.
> Sony, Adobe and their ilk could learn a lot from this company.
And unfortunately they won’t listen…