Hacker News Reader

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.

And unfortunately they won’t listen…

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!

It's easy to re-crypt the password when you log in.

But how many accounts haven't had a login for a while?

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.

Any modern Rails app is very likely using bcrypt to store password hashes. It's baked into most of the popular auth frameworks.

It's actually now baked into rails itself. You can declare

    has_secure_password

in the model and you're away.

Why would you have to declare it?

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!"

It is extremely easy to use bcrypt. http://www.openwall.com/phpass/

Counterexample: I've recently been playing with http://brubeck.io/ and it uses bcrypt as the default: https://github.com/j2labs/brubeck/blob/master/brubeck/auth.p...

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 can't speak for many, but at least reddit (https://github.com/reddit/reddit/commit/a311805c8598232b14a4...), and Hipmunk do

Happened a bit too late for reddit, though :p

In a lame web service / trivia game I created for a distributed systems graduate class I used bcrypt. https://github.com/bgianfo/distributed-systems

PBKDF2 will be in Django 1.4:

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.

Also, if you're using Django, consider Playdoh:

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 :)

Very interesting stuff - thanks!

We see bcrypt and/or PBKDF2 regularly.

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.

Since it was just as easy as any other way I used bcrypt for my site. Seems common as of a year ago.

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

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.

> 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.

"hashed and salted" would already overwhelm those people's knowledge. I don't see any good reason why they should not tell their algorithm.

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.

Could the revelation of the encryption used give the attackers the hint they need to break it open?

No.

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.

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...

> 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.

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.

It's vBulletin 3.8.x

The passwords are hashed and salted using this:

    md5(md5(password + user_salt))

Most likely they have another authentication backend.

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.

Double MD5‼ To be extra secure‼

Running a hash function directly on a hash makes little sense. You probably meant:

    md5(md5(password) + user_salt)

[edit]I'm wrong, you're right[/edit]

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.

No offense to your Valve worship fest, but when can I start beating on them for not having notifying me at my registered e-mail address? How many days before I can expect that?

Because while some people have apparently received an e-mail they certainly are not contacting all their customers.

Where you registered on their forums? Or are you just a steam user? (The steam database has not be compromised as far as they are aware)

I'm on both and haven't had an e-mail - perhaps an overzealous spam filter, somewhere?

I think they only show it inside the Steam client. I didn't receive any email either but it did show up in the client as a normal notification.

Legally speaking, wouldn't Valve become liable due to a public apology that allows people to say it's Valve's fault when 'bad stuff' happens?

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.

I would say your customers can sue you regardless of what you say in an email or blog post. Using lawyers to hide from your customers seems less than optimal.

I've seen that worry expressed several times, but have never heard about a case where it actually made a difference. Does anyone have a cite? It sounds like FUD spread by a lawyer to drum up more work.

I absolutely agree. I would rather be told the bad news with all the facts than a sugar-coated "oh-we-were-hacked-but-its-not-our-fault-and-you-customers-are-screwed" response.

Valve handled it well but something like this shouldn't even happen in the first place. Valve saw what happened to PSN so Valve should have improved its security after such an incident. Since Valve holds people's CC numbers and passwords, they should have put in a lot more care to something so fundamental like security. Customer shouldn't have to check their bank statements at all.

Sorry but real mensch in tech never has its database compromised.

> 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.

I highly doubt Valve's database is more complex than Apple's or Amazon's database. You never hear about theirs being compromised to the same extent as Valve's.

But I imagine if Apple's or Amazon's databases were compromised, it would quite likely be to a similar extent.

Once you can perform a select statement, extracting data becomes pretty easy.

Given Apple's propensity to stomp on any negative publicity, they could have had a dozen similar issues and never disclosed them. Hardly a fair comparison.

That's one thing I'm slightly confused about. I always untick the 'store my credit card details to make future purchases easier' box - so were my card details in their database, or not?

It's a proper way content-wise but why didn't I get this announcement in my email? Was this sent within a Steam system? If so, it's not enough. I use only Steam now and then.

Good ol' American values

"I am truly sorry this happened, and I apologize for the inconvenience."

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.