Retailers Fighting To No Longer Store Credit Data 136
Technical Writing Geek writes with the news that the retail industry is getting mighty fed up over credit card company policies requiring them to store payment data. The National Retail Federation (NRF) has gone to bat for store owners, asking the credit industry to change their policies. The frustration stems from payment card industry (PCI) standards and new security measures going into place across the retail experience. Retailers are now trying to point out that many of the elements of the standard would not be a requirement if they didn't have to store so much payment data. "Even if the NRF's demands were immediately met, it would take several years before retailers could purge their systems and applications of credit card data, he said. Over the years, retailers have collected and stored credit card data in myriad systems and places -- including relatively old legacy environments -- and they are just now realizing the data can be a challenge, he said. Purging it can be a bigger headache because the data is often inextricably linked to and used by a variety of customer and marketing applications; simply removing it could cause huge disruptions."
Data Theft (Score:4, Insightful)
Well (Score:3, Insightful)
All about shifting liability (Score:5, Insightful)
Re:Well (Score:5, Insightful)
Let the CC company keep a transaction ID and all confidential information, and the retailer keeps the same transaction ID, along with purchase details. That puts the burden of security all in one place, with the CC company, rather than scattered around with all the various retailers.
And if there's a trail to be followed, the CC company and retailer can compare records through the transaction ID.
Re:Data Theft (Score:4, Insightful)
Several Issues (Score:4, Insightful)
On the other hand, retailers still need to secure whatever legacy data they have, and work on purging the systems that store it. These are two different problems, and both sides of this debate seem to want to point out the problems with their opponent's positions without addressing their own issues. If retailers have the data and aren't securing it, then I have little sympathy for them when they get heavily fined for not treating our sensitive data properly, even if the CC companies require the storage of some of that data and shouldn't. Especially for major retailers where the IT budget can be spread across many, many stores.
So, short term solution is to get the retail stores to abide by the current security regulations posted by CC companies. The longer term solution is to get a more sane set of security solutions from the CC companies, and make it so that every retail outlet is required NOT to store sensitive data that crackers might want to get a hold of. This would reduce the number of outlets to our sensitive data to a minimum. It would reduce it to the companies that have to retain that data anyway.
Cash is so easy. (Score:4, Insightful)
Very simple compared to the 15 page credit card contract for the consumer and the headaches for the retailer.
Henry David Thoreau said it best, "Simplify".
Re:The joys of insecurity (Score:2, Insightful)
- Not all point of sale systems (especially older ones) are set up to only show last four = code modification. If the vendor still supports it.
- Hard copy of receipts to reverse chargebacks need to be reprogrammed to only show last four.
- Hard copy of detail tape and settlement journals likewise.
- Modify register and pole display programming to obscure card number as well
- Got old credit card terminals? Oh, bummer. You get to replace them all at a few hundred bucks a pop if they can't be upgraded to Triple DES. Retail math primer: 100 stores * 10 terminals * $300 = $300k plus time and effort to reinject merchant numbers, test, roll-out, etc. Oh. And how long will that standard last?
- Credit card terminals go down? Rules require taking a manual imprint of the card. Now those copies need to be stored and secured.
And at corporate? Same issues.
- Delete it from the marketing databases. Delete it from loss prevention programs.
- Password protect each individual spreadsheet used for reconciling payments and thats still not secure.
- Also have to make sure nobody can email or otherwise copy the files and take them out with them.
- When glitches happen and duplicate charges happen, somebody at corporate needs the full number to issue the credit.
- Years of back-up tapes contain the data too - on-site and off-site.
The biggest problem, and its difficult (and costly) to even insure against, is the virtually unlimited amount of damages which can pile up - even on a retailer trying to do it right. The NRF, of which we are a member, has it right. There is no need for us to store card numbers at all. If the processor and banks have the full number (which they do), then a chargeback request for a signed receipt based upon location, date/time, amount and last four is all that is necessary. I'm not carping about the cost of protecting sensitive data. I'm carping about the cost of being forced by Visa/Mastercard regs to store *unnecessary* sensitive data then having to jump through ever-changing hoops to do so.
TJ Maxx is another issue. They clearly dropped the ball by allowing their kiosks onto their store networks unfirewalled, but anyone who minimizes the cost/effort behind this issue is sorely misinformed.
Oh yeah. Guess who ends up paying these costs?
Re:Data Theft (Score:2, Insightful)
Re:why not encrypt? (Score:3, Insightful)
Most applications I've seen - quite a few, both in-house and off-the-shelf - use a fixed symmetric key for credit card encryption, stored right in the application code or in a configuration file. Often this key is on the same server as the database, and even if it is not, the app server probably has the same vulnerabilies and probably the same passwords that gave you access to the database. They also typically don't use a unique initialization vector for each database row, so a dictionary attack against the encrypted card data is often dead simple (often the cipher and mode of operation are chosen poorly as well, and there's only about 30 bits of entropy in a credit card number).
Doing encryption key management correctly is not easy. To do it right, you'd need to use public key encryption, or a Kerberos-like system where an entered password can temporarily unlock a copy of the shared encryption key. Better yet, use hardware key escrow. And don't forget the need to revoke keys, and change them often.
It's much easier and safer to just to throw away the card numbers and CVC as soon as you get the auth code from Visa. Right now we keep card data only for as long as it takes the transaction to settle. But it would be best if card data was only ever stored in RAM (and yeah, I know the swapfile is a vulnerability, too).