Linked by Thom Holwerda on Fri 25th Dec 2015 22:17 UTC
Games

So uh, look up from your Christmas dinner for a second, because Steam is having a major security meltdown at the moment.

It's the middle of Steam's big winter sale, which means a huge number of people are browsing, buying, and playing games right now on the platform. Some of them, however, seem to have tripped into a major security hole. A variety of users on Twitter, NeoGAF, and Reddit have noted that they can see other users' account information - including addresses and credit card data - instead of their own details.

From what I can gather online, users would occasionally be logged into not just their own accounts, but also those of others, including being able to see their information. The general consensus seems to be that you couldn't actually abuse said credit card information (you only have the last two digits and you still need the security code to actually buy stuff), but people who use PayPal to pay on Steam might not be safe.

Steam's store has been completely shut down, but you can still play online. Major security problem here, and it seems to be related to caching, although there's no official word on that.

See? This is what I get for buying an Apple Watch. I upset the balance.

Order by: Score:
Oh I do declare
by kwan_e on Sat 26th Dec 2015 03:35 UTC
kwan_e
Member since:
2007-02-18

I have the vapours!

Reply Score: 3

Priest
Member since:
2006-05-12

When I create a password I enter it in cleartext and websites store just a hash of that password instead of the password itself and its more secure that way.

If I give steam my credit card, after the first time they process a transaction from it, the bank/credit card company they process with should respond back with a hash to use for all future transactions.

Instead of hashing only the credit card number itself (because it would be valid if used at a different retailer still) it would hash a few of the credentials so that it would only be valid for transactions for my account on

The fields would be something like

store.steam.com, hash-create-date, credit-card-number, secret-biz-to-biz-security-token

Then the bank responds with an MD5 hash for steam to store like "4444d101816d0518b0527d04b37e4e21" and they use that instead of my actual credit card number for all future transactions.

Now steam saves only the hash into a database and does not need to keep a copy of my actual credit card information. If anyone compromises the database and gets a copy of "4444d101816d0518b0527d04b37e4e21" it's essentially worthless to them unlike a credit card number where someone can just print up a card with it and take it to Walmart.

Even if all of the info it nabbed (expire, security code, hash etc.) they still couldn't use the card anywhere because it's only a temporary token used for future transactions on my account so that my actual credit card number is never actually stored in the retailers (Steams) database.

This would get credit card numbers out of the hands of retailers and vastly reduce the risk of credit card thefts when database hacks inevitably happen.

Reply Score: 9

dpJudas Member since:
2009-12-10

When I create a password I enter it in cleartext and websites store just a hash of that password instead of the password itself and its more secure that way.

For the same reason that even this is not always done. And then when it is hashed, half of them just encrypted it instead or didn't include any salting.

I once worked shortly for a company that was responsible for maintaining a pin code database and issuing credit cards with a chip. They used a MS Access database for this. One day we got an email sent to all employees that VISA would show up the next day, and it was therefore extra important we followed the official security rules.

The sad truth is that most security is mostly only about stopping the average dumb thief. It is for the same reason that once someone with a brain starts doing more advanced crime, the penalties skyrocket. Society is built around the assumption that intelligent people do not exploit the system.

Reply Score: 4

Alfman Member since:
2011-01-28

dpJudas,

When I create a password I enter it in cleartext and websites store just a hash of that password instead of the password itself and its more secure that way.
...
One day we got an email sent to all employees that VISA would show up the next day, and it was therefore extra important we followed the official security rules.


Well, I'd argue that visa and mastercard are largely to blame for relying on cryptographically insecure technology in the first place. I want to scream at them: PCI compliance is not a substitute for crypto. Proper crypto would make it impossible for a breach to leak raw credit details that can be used to commit fraudulent transactions elsewhere.


I feel the reason visa/mastercard have been so lazy in fixing CC security is because they aren't liable for fraud. Instead they've shifted the liability to merchants and continue to charge fees on fraudulent transactions. I'm very confident that we'd see the abrupt end of static CC numbers and finally get some secure crypto if visa/mastercard were actually on the hook.

Reply Score: 4

Alfman Member since:
2011-01-28

Priest,

Instead of hashing only the credit card number itself (because it would be valid if used at a different retailer still) it would hash a few of the credentials so that it would only be valid for transactions for my account on

The fields would be something like

store.steam.com, hash-create-date, credit-card-number, secret-biz-to-biz-security-token

Then the bank responds with an MD5 hash for steam to store like "4444d101816d0518b0527d04b37e4e21" and they use that instead of my actual credit card number for all future transactions.


We have to be careful with hashes because they are reversible when there isn't sufficient entropy to begin with.

Consider this pseudo code:
function decrypt(cc_hash, salt, ...) {
for(cc=0; cc<10^16; cc++) {
if (hmac(cc,salt,...)==cc_hash) return cc;
}
}


In only 10^16 operations, we just reversed a salted CC number hash. This is before taking into account the fact that CC numbers contain prefixes and luhn validation that give them even less entropy.

http://www.linkspiders.com/freelists/credit%20card%20teleph...

https://en.wikipedia.org/wiki/Luhn_algorithm

When computers get faster at brute forcing, but entropy of things like credit cards and passwords remain fixed, it tends to negate most of the theoretical benefits of hashing those values.

You could use a truly random surrogate key to identify the merchant's customer - since it was not generated using customer details, there would be nothing to "crack". But my favorite approach to the problem is to use PKI. The customer cryptographically signs a transaction to authorize it and no-one including the merchant or even the bank can create fraudulent signatures. Unfortunately Visa & Mastercard prefer to double down on a PCI compliance governance model rather than promote cryptographic infrastructures that would render it unnecessary.

Edited 2015-12-26 17:56 UTC

Reply Score: 6

Priest Member since:
2006-05-12

I agree with you that credit card numbers alone don't provide enough entropy but even that alone is still more secure than not hashing the value at all.

I also partly addressed the point by encrypting the entire string rather than just the credit number to add entropy.

"store.steam.com, hash-create-date, credit-card-number, secret-biz-to-biz-security-token"


The hash creation date and secret-biz-to-biz-security-token would serve to add sufficient entropy.

An attacker would have to know both of those values in order to begin the process of brute forcing the credit card value. If a credit card database was obtained there is no reason they would also know the creation date of the hashes present.

The secret-biz-to-biz-security-token would be a long field that would add significant entropy to the hash to the extent that brute forcing a credit card number from the hash would be impossibly without first knowing that value.

Even if the value is known/determined a cracking a single 16 digit credit number number and a date is possible though not trivial. Cracking a database of hundreds of thousands of credit cards even knowing much of the required information is still a pretty tall order to accomplish and would successfully mitigate a majority of the fraud possible with such a database which would serve to vastly lower the expenses.

Maybe it's possible to crack a few of the credit cards in the list but not all of them and even then they would not be cracked immediately giving people time to notice and respond to the hack before the cleartext card numbers become available to the hackers.

Eliminating > 95% of related fraud would be well worth it and it's very possible to add other security mechanisms to the system that would increase that.

Once you move the system away from clear text card numbers there is basically an infinite numbers of ways you can pile onto the system to add entropy as needed based on computing potential of the day.

Then again after the initial transaction the bank could always just give steam a temporary completely random number to use for future transactions only valid for them as well that would be 100% useless for an attacker to do anything with.

There are really numerous solutions that would work but they really need to stop storing them in a clear text database.

Maybe there is opportunity for a startup to create a payment company that deploys technology like this and undercuts visa/mastercard by needing lower fees and fraud insurance because of it.

Reply Score: 2

Alfman Member since:
2011-01-28

Priest,

I agree with you that credit card numbers alone don't provide enough entropy but even that alone is still more secure than not hashing the value at all.


This is true, I did want to point out the cryptographic weaknesses. The possibilities range from EC2 clusters or GPGPUs to re-provisioning the specialized bitcoin ASICs that are specially designed to brute force hashes.

http://products.butterflylabs.com/homepage-new-products/10-gh-s-bit...

So it becomes a question of "how much does it cost to break" rather than "is it possible to break". At this point I concede an infiltrator may just go for an easier (and more profitable) target, so in that respect you may be "safe" even though you are still technically vulnerable. It all depends on how much high quality credit data is worth on the black market.


I also partly addressed the point by encrypting the entire string rather than just the credit number to add entropy.
"store.steam.com, hash-create-date, credit-card-number, secret-biz-to-biz-security-token"
The hash creation date and secret-biz-to-biz-security-token would serve to add sufficient entropy.
An attacker would have to know both of those values in order to begin the process of brute forcing the credit card value. If a credit card database was obtained there is no reason they would also know the creation date of the hashes present.


I disagree with this assumption. IMHO for security we should dismiss date as a source of any entropy whatsoever since it's not random and is very likely to correlate strongly with timestamped transactions. A hacker can bate the database with known transactions and credit cards to figure out the correlation.

It's not clear from your description who would have access to a secret-biz-to-biz-security-token? If the merchant has it, then it has zero entropy when merchant systems are compromised. If the merchant does not have it, then as far as the merchant is concerned the hash is indistinguishable from a random surrogate key. Given the damage that could be done if the security token were leaked, and that random keys are more secure, I can't think of any advantage in using an opaque hash over using a genuinely random key.


Even if the value is known/determined a cracking a single 16 digit credit number number and a date is possible though not trivial. Cracking a database of hundreds of thousands of credit cards even knowing much of the required information is still a pretty tall order to accomplish and would successfully mitigate a majority of the fraud possible with such a database which would serve to vastly lower the expenses.


I agree with you here, but why not go with my suggestion to use PKI crypto that isn't vulnerable to this attack?

The PKI crypto would not depend on any secret inputs (ie "secret-biz-to-biz-security-token"), it could even be encrypted in the user's web browser such that the plain-text credit card is never transmitted to the merchant's server at all. The hash approach relies on keeping secret keys for entropy. A breach could leak the secret token used for entropy in all customer credit card records.

The hash approach has another drawback that has nothing to do with security: it requires the bank/processor to keep a database of CreditCard hashes + details per merchant. This is technically doable, but the PKI solution allows the bank/processor to decrypt all the information it needs from the transaction itself without any pre-existing knowledge of the merchant's customers.


Maybe there is opportunity for a startup to create a payment company that deploys technology like this and undercuts visa/mastercard by needing lower fees and fraud insurance because of it.


I want that too, and I even feel confident that a small startup could build the service/platform without too much difficulty. However cutting through the banks and oligopolies is a different matter, why would a bank want to partner with a more efficient CC system with less overhead and fewer kickbacks? One could try to sidestep these players, but visa and mastercard's lawyers contractually require merchants to charge customers the same amount regardless of the credit card fees. This should be illegal, but it's a large part of why competitors haven't popped up saying "hey, you'll pay lower prices at the store when you use our card". Until Visa/MC contracts are outlawed, new competitors can't offer lower prices to customers, and without oligopoly power can't negotiate high fees needed to offer competitive customer reward programs. It's a tough market to break into.

Reply Score: 2

Alfman Member since:
2011-01-28

Was too late the edit my post, but I found a list of prices for CC on the black market:

http://blog.imperva.com/2011/10/current-value-of-credit-cards-on-th...

Reply Score: 2

Alfman Member since:
2011-01-28

Priest,

This would get credit card numbers out of the hands of retailers and vastly reduce the risk of credit card thefts when database hacks inevitably happen.


I strongly favor a solution that eliminates the need for merchants to handle sensitive information at all (even if it's only transient/temporary). Merchants should only receive encrypted authorizations and the customer's browser or the bank would apply the crypto.

But if the industry is simply unwilling to go that route for whatever reason, then I agree with you we should at least limit merchant possession to a one time occurrence to significantly reduce the window in which the data is vulnerable. To this end, I'd propose one change to your solution by using PKI rather than a hash.

proof = PKIEncrypt(date + merchant + CC details + ..., issuer-visa/mc public key).
From this point forward, the merchant can use this as proof that they had the CC details, which they can now discard. Even if the proof is leaked, it isn't valuable to outsiders who want the CC details for fraud.

There's still a window of opportunity to collect CC details when customers are entering it, but at least the customer database would be safe.

Edited 2015-12-26 18:57 UTC

Reply Score: 2

Come on Thom
by shotsman on Sat 26th Dec 2015 18:00 UTC
shotsman
Member since:
2005-07-22

What has buying an Apple Watch got to do with this?
Perhaps a little under the weather?

If I buy one will it do the same to me? ;)

Reply Score: 1

RE: Come on Thom
by Sauron on Sat 26th Dec 2015 18:04 UTC in reply to "Come on Thom"
Sauron Member since:
2005-08-02

He's probably after some sympathy for buying it in the first place! ;)

Reply Score: 4

RE: Come on Thom
by Sidux on Mon 28th Dec 2015 09:55 UTC in reply to "Come on Thom"
Sidux Member since:
2015-03-10

Because it's still a secure platform of choice.
Too bad they don't do gaming that much (nor they are interested in such a thing) because all gaming platforms had major security flaws until now.

Reply Score: 1

leech
Member since:
2006-01-10

I pretty much never save any of my credit card information on Steam or any other places.

They have a little check box that says 'save for future use' or something like that. I always uncheck it. It's not like it takes more than a minute or so to type it in anyhow.

One exception is Sony's playstation store. It requires you to save a Credit Card in there, you have to go in there after the purchase to then delete it! I think that option was only ever put in place after they had their hack too... There should always be a way to not save the information there.

On another note, it was only ever the last 4 digits that people got a hold of, not terribly useful.

Reply Score: 3

Soulbender Member since:
2005-08-18

Or you can just buy steam wallet codes.

Reply Score: 2

On a lot less relevant side...
by dionicio on Mon 28th Dec 2015 17:25 UTC
dionicio
Member since:
2006-07-12
So small...
by dionicio on Mon 28th Dec 2015 17:55 UTC in reply to "On a lot less relevant side..."
dionicio Member since:
2006-07-12

unaware, and innocent an individual is.

Today is innocents' day ;)

Reply Score: 1

RE: On a lot less relevant side...
by dionicio on Mon 28th Dec 2015 18:05 UTC in reply to "On a lot less relevant side..."
dionicio Member since:
2006-07-12

At the end of the day, individuals, just that, all we are. And just me goes with I when dreaming, or hopping.

Reply Score: 1

dionicio Member since:
2006-07-12

Boing, boing.

Reply Score: 1