Slashdot Mirror
Sony: 10 Million Credit Cards May Have Been Exposed
WrongSizeGlass writes "The LA Times is reporting that Sony has revealed that 10 million credit card accounts may have been exposed two weeks ago when a hacker broke into the company's computers in San Diego and stole data from 77 million PlayStation Network accounts. Sony said it will provide credit card protection services for the 10 million customers whose data were compromised. Sony last week said it had encrypted credit card data, but not other account information, including names, addresses, email addresses and birth dates."
I know this is beating a dead horse... but the core problem here isn't Sony's epic failure... it's that the credit system is so broken that this information that was stolen is enough to seriously fuck with someones life.
I'm not trying to downplay Sony's screw up. I have a PSN account and as such am suitably nervous. This whole thing just reminds me of how messed up our system is.
...Were account passwords encrypted or hashed?
Using the credit cards will install a DRM rootkit on their computers right?
Sony, I thought you said no CC numbers were exposed! How will we ever trust you again when you lie like this? A month of PSN Plus you say?
It took years after the rootkit fiasco before I decided to extend some trust to Sony and spend money on their products. Then came the removal of otheros, and I ceased spending any money with them. Then their bully tactics when the console got hacked, and I was glad I'd not spent any further money with them. Now, I find even after not doing any business with them for such a period I'm still not free of their incompetence and poor management. What will happen to Sony as a result of this? Nothing. All the muppets out there will continue to do business with this incompetent, morally bankrupt, behemoth. Will I be dumb enough to become one of those muppets again? I hope not.
Why does everybody collect and store all these data centrally?
Just store it locally, on the playstation, electronically signed and encrypted in a way that the customer has to enter a passphrase to decrypt it when its really needed. make the "it is needed" message also necessarily signed by an independent system with no other function. Let this system do a statistic. trigger an alarm if the number of signatures per minute is deviating significantly from the expected number.
I just got up to speed on the whole PSN thing. I never once received an email from sony explaining the problems and I was too busy last week to spend an abundant amount of time on /. reading about the security breach. I just got a call today from fraud protection on my debit card tied to my main bank account. They got triggered to suspicious activity when multiple charges showed up in two different states at the same time. Someone had gone to 2 Home depots in FL and ran $100 gift cards 6 times in 2hrs today. This also happens to be the same card I had used to make a purchase from the PSN network a month ago for the DLC of fallout new vegas. To me this seems a little too coincidental to be the victim of some completely different fraud in the middle of this big stink with the 77 million accounts compromised from the PSN.
All online companies that store credit card data are required to be PCI Compliant, like the company I work for, http://solidtrustpay.com./ The only reason Sony would have been storing card info is to retain the ability to recharge cards monthly, etc. ALL data should be encrypted, not just card info; in particular, email addresses to prevent phishing and spam attacks. Let's hope they learn and adjust their database systems quickly!
An alternative is easy in concept, but the satus quo has the industry in a strangle hold. It's not like even a large consumer group acting together could *change* things from 'outside'
We are talking about 16 'secret' numbers that allow whoever figures them out to charge however much they want against your account. Occasionally an additional view on the back are needed for some retailers, but at the end of the day to even buy $5 of something with your card you must trust the seller to not do bad things with your account *and* keep it safe from others. This might have been about the best you could do when the seller was doing a carbon copy and would phone in the slips at the end of the day, but now everyone *immediately* contacts a server for validation and nearly every person with a card also has a pocket sized computer device capable of independently talking to bank servers. It's completely reasonable to have point-of-sale equipment that pairs with a phone and have the phone connect directly to bank servers to *specifically* authorize a transaction amount and have the PoS verify that data as well without such a silly use of an account number and just exchangine public keys and per-transaction authorization data.
The common defense is "oh, well, most card companies don't hold the customer liable for everything", ignoring:
-Some companies will hold the cardholder liable for some of it
-Sometimes they may argue that the cardholder didn't act promptly or other circumstance
-Even when everything works as 'promised', there is a cost incurred *somewhere* and that impacts you, either in higher interest rates on credit, lower interest rates on checking, and/or merchant prices due to processing fees. I'm about convinced this last one is the biggest motivation not to change, they play funny games with margin and can blame identity theft.
XML is like violence. If it doesn't solve the problem, use more.
It has been revealed that the whole problem began when a PSN admin inserted a Sony music CD. The installed rootkit then allowed hackers to access the network.
There's a bigger problem... If a system is sufficiently compromised, the attacker gets the encrypted card data, the encryption algorithm, and the keys (my favorite variation is where the database has a decryption stored procedure). We learned long ago to keep all encrypted card data in systems that have no users access and to only keep surrogate keys in transactional systems. For example, in our equivalent of the PlayStation Network, your credit card number would be stored as a meaningless number like "127". In order to process a transaction against the card, "127" and the transaction data is passed to the credit card system, where the credit card system looks up the real encrypted credit card number, decrypts it, and charges it. You could make the argument that we've simply moved the problem, but the credit card system is much easier to secure since no customer or even employee should ever be able to send a packet to it -- only a handful of controlled system can. Sure, if the transactional system is compromised, the attacker can process cards with our system, but as soon as we kick them out, the card data is useless to them.
As for the cryptanalysis problem, simply use a salt the same size as the card number and XOR the card number with it. Presto, perfectly random looking plain text with no (new) differential cryptanalysis vulnerabilities. You don't even need to do this if you use proper initialization vectors and a block cipher in CBC mode
What would fix this is to have credit cards generate a contract not tap an open vein. that is, the credit card is used to authorize a one time transaction (after which the credit card number itself can be discarded for the transaction ID). For recurring charges the transaction authorized should only enable payments to sony, for goods provided to a specific address or online account, and include a cap. that is non-transferable transactions are the thing we should keep on record.
There needs to be a mechanism for generating these transaction IDs.
Some drink at the fountain of knowledge. Others just gargle.
Sony never said no credit card numbers were compromised, they said that credit card numbers were in a separate encrypted database and probably were not accessed. But they can't be sure.
And they are saying the exact same thing now.
http://lkml.org/lkml/2005/8/20/95
That's what I was wondering about. I don't think that I've paid for anything via PSN, if I buy a game, I do it as disc and so it's unlikely that Sony has any information beyond my contact information. And let's be honest about that, it's been lost to crackers at least 3 times at this point, and I think it's probably been a few more times than that.
One solution is to let the payment processor store them.
I recently implemented an online payment system for a rather large client. We didn't want to store credit card numbers but had a need to process additional charges at a later date.
We used Paypal's Payflow Pro product (formerly offered by Verisign). They have a feature that allows you to store a reference number with any successful transaction processed. When you want to submit an additional transaction, you just supply this reference number along with the new amount and the credit card details are copied into the transaction data by the processor's system. You can then submit a new sale or auth without having to store the cc number.
Of course one issue with this is that since storing the CVV is prohibited, you cannot verify that this way. So what we do for that is submit a $1 auth at the data entry point, then void that. That allows us to verify the CVV from the customer before processing the transaction and storing the reference.
With this system, if the database is ever compromised the attackers would not be able to use the data to submit charges very easily since all they would have is the reference number which cannot be used on front end web or POS systems. It would only be valid with a backend hook into Paypal's payflow processing system.
I have had data breaches happen to my personal data multiple times at a big-ten school in the U.S., *and* at a big-ten school's medical center. There was always a press release, then a delay of a couple of days, then an personalized email with link & pin to start a year's worth of service with some credit protection service provider.
A successful API design takes a mixture of software design and pedagogy.