-
Hey Guest. Check out your NeoGAF Wrapped 2025 results here!
Gabe Newell gives an update on last year's Steam Database Intrusion
- Thread starter Akia
- Start date
Littlegator
Banned
Assuming Valve did proper encryption, seems like there's nothing to worry about.
SteveWinwood
Member
At least they're doing this amd not just hoping everyone forgot about it.
I'm pretty sure they did. They got hacked and had their Half-Life 2 source code stolen years ago, I'm sure that they're paranoid about security ever since.
Also, the credit card I used for Steam purchases, including the Xmas sale, has since expired so I'm golden.
bigtroyjon
Member
They are required to by law.
What does this mean? I don't get it.
That homeless guy you see every day on the way to work? He's Gordon Freeman.
more steam coal
slidewinder
Banned
I think I deserve free "Sexy Clinkz" and "EXTRA Ginger Windrunner" skins for this lapse, Gabe.
It's worrying that he calls it a backup file, and not a backup database. If they just get an database with encrypted fields - it's pretty much useless without the salts. But if they also got access to the files and the code itself, then it's pretty easy to find the salts used for the encryption.
When in doubt consider that the salts are saved with the passwords. That's the only way it makes any sense in a live system.
And in a backup that is only kept, because you have to have the transaction data for business filings the password is not useful either, so why strip the salt but not the password? Makes no sense.
What I don't understand is how according to Gabe the usernames are not encrypted but the billing information address is.
The only way again to make sense of that is that multiple files have been accessed.
It's hard to really say without knowing more details, maybe it was just a routine mirror backup of a system which stored the live transaction data. Also, I'd get fired if I ever appended salts to the encrypted passwords, but unfortunately I know a lot of places do it. It's safer to have a single salt that rotates on a schedule than a completely random salt that is appended with each password, especially considering that the vast majority of hacks are sql injections and therefore limited to just the database data.
The usernames are probably used in various index tables to make accessing the account details quicker, storing them encrypted would be pretty.. well, horrible. Plus a username alone would be useless if the other details are encrypted properly
It has been best practices for years to do that. And has not even been universally adopted.
I haven't seen the single salt per timeframe thing yet, but I'm also not a programmer any more.
Is there an analysis how that compares to the regular salting (individual salts)?
It's not a time linked salt, but rather you have a server which just handles the salts and salt data - it has a limited API so you can throw at it a datestamp and an encrypted field and plain text field it'll give you a TRUE or FALSE if they match, the salt server will store a history of the salts it's used, it normally rotates every day or so. The salt and user records therefore never meet, or are ever even physically connected to each other in anyway other than via the API. But I'm talking about banking systems which handle a lot of sensitive information, your typical small e-commerce website hosted by a third party isn't going to bother with all this. Even on single server setups I'd suggest making the salt a constant within a file rather than unique and within the database.
^^ Interesting. ^^
I would advise against that purely on practicability. It basically comes down to: Am I good enough in hiding this salt? I would not bet on yes in the scenario that I was compromised.
In any case the salt is going to be chilling in memory or be an obvious file access and with the time tables that some companies have given to learn that sort of thing is a very realistic issue.
Anyway, enough derailing of the topic.
That's playing with fire if you have a compromised system.
I would advise against that purely on practicability. It basically comes down to: Am I good enough in hiding this salt? I would not bet on yes in the scenario that I was compromised.
In any case the salt is going to be chilling in memory or be an obvious file access and with the time tables that some companies have given to learn that sort of thing is a very realistic issue.
Anyway, enough derailing of the topic.
TouchMyBox
Member
Obviously this was done by someone who is really obsessed with NPD numbers and just wanted some accurate steam sales numbers.
I don't follow. If they get access to your file system you are screwed either way as they'll just dump your mysql files and site files and get the salt no matter where it was stored. The purpose of storing the salt in the file-system however is so if they only hack your SQL database (which is the case most of the time on front facing websites) they don't have the salts. Store it in the mysql database and your screwed by either type of attack, store it in a file and your only in trouble if they manage the harder task of getting to your file-system.
If it's encrypted to the standard you'd suspect from Valve and given that they implemented Steam Guard which is a very security-conscious system I think the encryption is probably chosen to be quite solid.
But even if it wasn't solid, we're talking about data from 2004-2008. Only a small percentage of those credit cards in that file will still be active, as I think the average issue time is 4 years. Some are significantly shorter with 2 years.
My point is about attacking the passwords on a whole table which is going to yield a magnitude more results when only a single salt per table is used vs. individual salts. (Computing once per table vs. once per row.)
Oh I completely glossed over the 2004-2008 part. I joined in 09 so I'm good I guess, thanks though.
Yup, the fact they got to the file system is pretty scary - but if it was only old backup files then most of the risk will have expired by now.
But still, when they hack your file system your really supposed to do what Sony did and basically pull everything offline. Because if they get any source code - even after you've patched up the original exploit chances are armed with your files they'll just find a dozen more. They stripped the servers down, formatted them and rewrote a lot of the framework code. Valve did..what? put a message up on Steam if you logged in. I guess they've discovered it so late, and nothing drastically bad has come about yet - so is it worth doing it? Anyhow, they know far more about what actually got accessed than we do so best just to give them the benefit of the doubt, in gabe we trust etc.
But still, when they hack your file system your really supposed to do what Sony did and basically pull everything offline. Because if they get any source code - even after you've patched up the original exploit chances are armed with your files they'll just find a dozen more. They stripped the servers down, formatted them and rewrote a lot of the framework code. Valve did..what? put a message up on Steam if you logged in. I guess they've discovered it so late, and nothing drastically bad has come about yet - so is it worth doing it? Anyhow, they know far more about what actually got accessed than we do so best just to give them the benefit of the doubt, in gabe we trust etc.
Stumpokapow
listen to the mad man
You've already had someone discuss other protections, which are the way to go.
But assuming you don't, and assuming you save a salt with the password, there's no reason for that to be the salt or to necessary compromise your salting routine.
Consider the password "password".
Now, assume I add a global, site-wide salt "sdf7ygusd7868gsdauuo" to the end of every password. This salt exists within my authentication code, but is not stored in any database anywhere, and so only a compromise of the server that actually gets code access can obtain this information. Now, assume I add a per-user salt (say, this user's salt was "776df789-dfs8ujoj;asjj") to the end of the password, after the global site-wise salt. I rather foolishly store this salt in plain text in the user data, so compromising the user database also gets the salts per user. Why not also add a salt based on the user's password itself; for example "repeat the password four times and then append the last character of the user's password 6 times and then append a rot13 of the character's first password four times"? This, again, can be implemented in code logic rather than in a database.
So the user's password, pre-encryption, is now: passwordsdf7ygusd7868gsdauuo776df789-dfs8ujoj;asjjpasswordpasswordpasswordpasswordddddddcccc.
Let's say that the password is then hashed with sha-1. The hacker who dumps the database knows: 776df789-dfs8ujoj;asjj and ec7300e4c6148eb8a26b17553b57e07113724b16. Do you expect they'll be able to get the user's password? This raises the bar for a compromise from an SQL injection or database compromise to a file system / server compromise.
Angelus Errare
Banned
Meh, not like the CC info from 2002 is even usable.
ThaiGrocer
Member
No unusual change to my bank accounts so far. All of my money is still going towards Valve.
Yes. I respect the fact that they're being upfront about this and keeping everyone posted.
So basically, hackers got the same data that was stolen from PSN (except billing addresses were also encrypted)
Looks like the lesson learned from the Sony fiasco has been: "If you get hacked, resume normal operations and keep it low key. Hold off on giving details until a year later when the story has chilled."
Not sure how I feel about that.
Looks like the lesson learned from the Sony fiasco has been: "If you get hacked, resume normal operations and keep it low key. Hold off on giving details until a year later when the story has chilled."
Not sure how I feel about that.
The Faceless Master
Member
the standard is raised to 2 free games now!
Rebel Leader
THE POWER OF BUTTERSCOTCH BOTTOMS
Bah! You get hats instead!
Stumpokapow
listen to the mad man
Key differences:
First, hackers compromised live data from Sony. They did not compromise live data here, but rather multi-year old data. As people noted, your CC expires every few years, so old data is not likely to be useful even if it was breached. I don't think I still have working credit cards from 2004 due to card replacements (or at least expiry date updates)
Second, while passwords were hashed by Sony, it's not clear that they used a strong hashing function or any kind of salting--and the passwords were there at all, which they weren't with Valve. Even if passwords were involved in the Valve hack (which they weren't), Valve offers two-factor authentication while Sony does not.
Third, Sony's intrusion included birthdates and billing addresses--and so someone's ability to steal an identity based on the Sony information is higher than based on the Valve information.
Fourth, after the first Sony breach, there were follow-up breaches that hit SOE and obtained much of the same information. No further breaches occurred with Valve. Part of the reason why Sony was grilled was because it was one thing after another with them.
There's also a major difference of scope as well, but I'll yield that both are huge data breaches.
My only real criticism to Valve throughout this process is that they opted not to share technical details of the attack, and that the initial response time from the forum defacement until the notice was probably about 2 days longer than it should have been (although still 3 days ahead of Sony). I probably would have forced a password reset as well.
Billing info was in the leak. They just don't have your brithday, like Sony did. Is there any info on the encryption used by Valve on that info to make it a non-issue? Billing address and credit card number potentially leaked out seems like it can still cause some damage.
And credit card data from 2004? Why use only the start date? What if someone had a newly issued card in 2008 on Steam? It's still within 4 years and it could still be valid.
I think I remember having the technology guy correcting an answer from Kaz Hirai that the passwords were hashed + salted.
(I even think I remember it as a clarification written below in one of the livestreams of the japanese press conference.)
But how to find this source again in all this misinformation when searching the net? Impossible for me.
(When I mean misinformation I mean I can google for PSN breach and find a source that says they were saved in plaintext. Or stuff that mixes SonyPictures up with the SCE PSN breach.)
I think Sony and Valve both fucked up, but both were public about the fail. Sony moreso than Valve as they kept repeating what had happened and of course not having PSN running served as a reminder every day. I'm sure you could argue that Valve should have gone offline to and have a third party investigate the issue. I don't know what the correct course of action is in that case.
I don't think it's incredibly important which is worse, and in both cases the damage done by the actual hacking seem to be minimal. PSN obviously took a bigger hit, but that was a result of Sony voluntarily shutting down PSN in order to play it safe. My point is that the lesson Sony and their peers seem to have learned is that it's probably not the best idea to play it safe. Just shrug it off and keep details hush hush until you've internally looked into it. Doing so mean there's no downtime and it probably saves us some unnecessary stress, but it also means that the next time one of these networks gets hacked there's a better chance that actual damage may happen.
Valve says live data was accessed. Obviously that means that Valve knowingly kept the servers live when they knew there had been a potential compromise. It's hard to know how long it took them to come to confirm that the breach of access did not result in actual data theft, as they don't provide us with many details. Going by their press release, they only recently found out that the backup was stolen. That doesn't exactly imply swiftness.
Correct, encrypted passwords were included in the PSN hack but there's a reason mandatory reset is standard practice when anything like this happens. It's a relatively simple fix. And I'm not sure on what basis you can be so dismissive of Sony's hashing while you give Valve's a free pass (in respect to the encrypted cc/billing info leaked by both hacks).
Both PSN and Valve had billing addresses, encrypted, leaked. I think it was the personal address you originally used when making the PSN account that was unencrypted. Greater chance of identity theft? Sure, but there are easier ways to get someone's birthdate and address that don't involve hacking major online networks.
We weren't made aware of any further breaches on Valve's servers. Valve was hush hush about the whole thing. I'm not implying that there actually were additional attacks, but there's not really any way for us to know unless Valve acted like Sony and told the public.
My point is this: I think that moving forward, the lesson learned is that it pays off for companies to be more hush hush with the details. I assume you'd agree that it's probably not in the best interest of customers.