My take about the Sony EPIC FAIL

First of all let me be clear: it was an EPIC FAIL, anybody saying otherwise is pretty much deluded. On the other hand, even though I’m one of those users who have enough rights to be upset with Sony (I just renewed my Plus subscription a couple of weeks ago), I don’t feel like this is all like people pretend it to be. A lot of the sentiment you see out there seem to come from people who aren’t in that database at all, and that are just trying to take a shot at Sony, either because they hate all corporations alike, or because they still feel they should have kept Linux an option on the PS3s.. or even more likely because they would like for Sony to invest more in developing consoles but pretend not to pay for games.

Am I being cynical? Probably. But I also read enough posts over the last year or so that seem to pretend that each and every PS3 owner should have felt robbed of the opportunity or running Linux on their systems… and as a PS3 owner myself, I don’t really see what’s the point. Sure there were a couple of things that as a Linux enthusiast and hacker I would have liked to be able to do, but with the exception of the clustering efforts to crunch numbers (which seem to be a field nowadays in the hand of high-end graphics cards), the most useful thing I have seen done with Linux on a PlayStation 3 has been testing BluRay movies with Linux, like Steve “beandog” has posted on Planet Gentoo a long time ago.

But my take is more interested in putting into prospective what the EPIC FAIL was about. Definitely I don’t count a general intrusion an EPIC FAIL by itself: most systems out there are going one way or another to fail… of course, we don’t expect them to fail as badly as putting at risk this many users. But then again, my main reason to think that Sony misdesigned their whole network is a simple one: the intruders gathered the users’ passwords.

Given that I expect most people commenting or reading about this are non-technical gamers (and people who don’t play but, as I said above, want to feel smug about it), I don’t expect most of them to put this into context: “Obviously Sony knows my password! I tell it to them every time I connect!” — which for anybody who ever worked on securing web application is a very naïve statement.

When you design a secure login system you do not store the password, but rather a function (hash) of it; when the login request comes in, you take the received string, apply the same function to it, and compare the result with the one you stored. Bonus points for salting such hash so that the same password, on two different users’ records, would be saved differently. Which is why on good systems you have “Reset password” options, and not “Recover password” ones (and why I loathe those systems which do send me back my password).

The fact that Sony declared passwords and (interestingly) security questions as compromised, makes it apparently likely that they didn’t store the hashes, but rather the cleartext passwords. I’m not sure about this myself to be honest: it sounds very stupid for them to make such a puny mistake, but Occam’s Razor calls for the most obvious explanation and that is definitely it. A more complex (but still feasible) explanation is that the intrusion was a long-term one, and that the intruders were able to snoop the passwords between the user and the authentication chain, during the time they are left in cleartext, from the application’s point of view.

I’ll leave a point for discussion for those who have had to deal with credit cards handling: I know that there are security protocols that need to be followed to be given access to processing credit cards; is the “hash the passwords” one missing? If so it might be as much fault of the credit card companies as it is of Sony.

Speaking about long-term, I’m still not sure why everybody’s assume that the (apparent) DoS on Sony’s infrastructure was related to the intrusion. Most complainers seem also to ignore Sony’s statement about finding out only later on that the database was compromised up to this point. By experience, it sounds like oversimplifying the situation. Until further pointers, it cannot be entirely ruled out that the intrusion was an inside job, maybe happening for months or more by now, and that the DoS only served unintentionally as a method to catch the auditing guys’ eyes. Personally I’d believe that on the count that Sony is not telling you that your currently listed creditcard is compromised, but that any creditcard you used is compromised. Which is scarier.

So to add at least a bit of a point to this whole mess, I think that at least the commentators of Free Software area should stop trying to find faults in corporations who don’t share wholly their ideals, and should rather try showing users another viable way. Asking them to stay in the past decade is not viable, and yet if we keep bickering among themselves, that is definitely what’s going to happen. Anybody said “fragmentation”?

6 thoughts on “My take about the Sony EPIC FAIL

  1. I’m not sure that I agree with your conclusion here (although I haven’t read the actual statement from Sony).The reason is that the use of rainbow tables to crack passwords massively speeds up the retrieval of the passwords from the hashed passwords (compared to brute force) although clearly very strong passwords will survive.So if someone gets access to the actual stored hashes they will very likely be able to retrieve a significant fraction (60-80%?) of the actual passwords in combination with the other info such as email-adresses, etc. So I don’t see an other option for Sony than to communicate that passwords have been compromised independent of whether or not passwords have been stored as hashed or not.ps) I used to have a PS3 until it broke….I wouldn’t even remember which password I’ve used to be honest (or which info I exactly filled in). Not good….grrr

    Like

  2. At a minimum you don’t want to use a simple md5 or similar function applied to the password, you want to add something extra such as an application-dependent prefix or suffix… but if you even use salted hashes (where the salt changes with each user) you make the rainbow table approach pointless.

    Like

  3. I don’t see how the application-dependent prefix wouldn’t have helped as it is too easy to have a known password of an own account in this case. This would give a clear attack angle to retrieve the prefix by brute force as you know most of the characters already.However I fully agree that adding a changing element to each individual password would make the rainbow attack pointless. However I don’t remember seeing that applied to any of the open source forum engines for example. Probably still very rare beyond specialized high security systems?

    Like

  4. As far as I can see, Microsoft’s ASP.NET default login system uses per-user salted passwords. And PAM does that as well when using the shadow/md5/sha512 options.Yes, most likely forum engines need to be updated, which is one good lesson to learn in this case, I guess.

    Like

  5. Just my .02 on Linux on the PS3:Having a browser on that oversized display in the living room that sucks less.What my PS3 actually did while it still could.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s