Slashdot Mirror
Retailers Fighting To No Longer Store Credit Data
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."
Let's ditch social security numbers too. Once we purge everything, we can come up with a new, unique, impervious to fraud, uncrackable new id for each person and their various accounts.
And if they didn't store the data then we wouldn't have the TJ Maxx crap like stuff going on in the first place. Storing it should be illegal - encrypted or not. There is no reason that numbers need to be stored - even for subscriptions. If worse comes to worse then get the lazy bastards to re-swipe or re-enter the card data.
"So long and thanks for all the fish."
It would seem to me that retailers SHOULD be storing the credit card data because there has to be some type of audit trail available. After all, people need to be able to track down credit card fraud, etc. I'm guessing that the credit card companies store this data as well, though, but they probably only store the amount of the transaction, card number and date, whereas the retailers would have the records of what was purchased, on what date, who rang up the transaction, etc.
My blog
I would be *very* surprised if the banks voluntarily accepted liability for any part of this chain. They face none now...they'll need a very strong reason to take any risk. The banks like the present system because they face no liability...if the merchant didn't do the right thing, or faces a chargeback, it's all on the merchant. (and it's on the merchant for liability if they're hacked)
There ya go!
Ask not what you can do for your country. Ask what your country did to you
"Retailers: In the interest of preserving your privacy, we'll all put your information into a single database instead of scattering it among lots of little ones."
How can I believe you when you tell me what I don't want to hear?
Why are these people "only now" realizing what this entails?
Oh yeah. Because they ignored it until they couldn't ignore it anymore.
Because the standard attempts to cover a widely disparate set of industries which have wildly different requirements, from Internet Ecommerce sites to the cashier at Ross.
Details of the standard are often in the eyes of the auditor. Auditor A may have one opinion, and you pass. Auditor B has a different opinion, and then you fail.
The standard is hopelessly vague when it comes to Ecommerce, and barely addresses network security, uses vague terms like 'deny all access to the server' without specifying specifics or context --- did you mean 'Deny physical to the server' vs. 'Deny SSH access to server' or 'Deny ALL access to the server, which means that my developer can't use a *webbrowser* to "Access the server"'. PCIDSS doesn't always make a distinction between which systems need to be L1 compliant vs L2.
There are at least two issues with credit card data based on this article. I definitely like the retailer's NOT storing full credit card data. The credit card type, possibly the bank, the card holder's name, the last few digits of the credit card number, and the charge date and time should be more than enough to identify a transaction, especially if there's a transaction id. The credit card companies HAVE to have full account data, but the more systems this data is stored in, the less secure it is, no matter what security is implemented at each individual site. If you can remove the bank and CC number entirely and work strictly off of transaction ID and card type, I'd be even happier. Storing this minimum of data would allow everybody to identify a particular charge if there's a dispute about charges, would still allow retailers to generate whatever statistical data they need, and would prevent identity thieves from getting full CC numbers, expiration dates, etc. from retailers.
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.
"This note is legal tender for all debts public and private."
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".
Linux - Because Mommy taught me to Share.
Its not that easy and its not just at the store itself. I work for a large national retailer and sit on the committee that is overseeing implementation of the CISP and now PCI requirements. Anti-intrusion systems and other general network security issues aside, there are, unfortunately, a lot of touchpoints that make this hard, time consuming and costly.
- 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?
Insert witty comment *here*. I'm fresh out of wit...
I've been working with a PCI certified auditor for close to nine months now to bring my company into compliance with the latest Data Security Standard. The DSS is a great source if you're looking for a concise primer on good development, administration and training practices, but... Bringing a company into compliance with all the requirements is incredibly difficult. No exaggeration, we've spent tens of thousands of dollars on the audit itself, tens of thousands more on infrastructure and the equivalent of one full time employee working on nothing but DSS compliance for the past year. Once we receive the stamp of compliance from the Payment Card Industry, we just have to turn around and do it all over again next year, the following year, the year after that, etc... Granted, once we get through the first audit, the following audits will be less expensive from a time and money perspective, but we're still looking at anywhere from ten to fifty grand a year for the certified auditor and any DSS mandated changes to our system. For example, the DSS requires for 2008 either an application layer firewall in front of web-facing apps or third-party code review. There goes my bonus for next year... Long story short - very few companies are going to be able to meet the Payment Card Industry Data Security Standard and on top of that, most companies don't want to store freakin' payment card anyway.
In spite of the smokescreen being thrown up by the big credit cards, it's really very simple.
The banks ALREADY have and must keep all of the information. Their byzantine PCI standards demand that the merchants keep a full duplicate of this highly sensitive data and dictate how it must be stored. The merchants maintain (correctly) that if the banks had as much intelligence as a slug all they would need to retain is non-sensitive (and useless to identity thieves) transaction/approval numbers rather than very sensitive cc numbers and identifying info.
In other words, in spite of what the banks claim, this is about reducing the risks and liabilities rather than shifting them. In fact, it's the banks that are trying to spread liability by maintaining a situation where they can plausibly play the blame game.
Various schemes have been available for DECADES to make sure that fraudulant credit transactions can not happen but the banks have fought against them tooth and nail in order to keep the current approach where name and cc number are all that's needed to commit fraud. They're also the ones that have been routinely offering big limit credit cards to toddlers, dogs, and cats then trying to stick innocent 3rd parties with the liabilities.
The entire identity theft problem only exists because of the very same banks. I'll bet that it would all stop instantly if a law was passed banning any attempt at collections for credit card debt unless the bank can present a picture of the alleged debtor actually signing the agreement for the account AND that without a digital transaction signature, the cardholder is presumed NOT to be liable for the charge. You can be assured that credit cards with useful smart chips and public key signature capability would be implemented the INSTANT such a law went into effect.
Please feel free to visualise (or not!) an analogy involving identity thieves, defrauded individuals, bank managers and goatse.
Hell, I know of one convenience store chain that is still running Windows 95 with a WinNT back of house.
Hell, I still support a POS system for a fairly large chain of dry cleaning shops that only runs on MS/DOS and uses a Lantastic peer-to-peer LAN in each store, and each store talks to the main office via LapLink and dialup modems each night to transfer it's daily sales data.
I was having hell locating motherboards that still had ISA card slots for the old Lantastic nics and dual RS-232 serial cards (each POS PC needs 4 serial port connections), but recently bought a whole truckload of ~1997-1998 vintage Gateway 2000 boxes with classic Pentium 233MHz cpus that work great, all for $100 the whole lot, so this dry cleaners company will keep running this old system for many years to come.
I have to post this anonymously, because I certainly don't want it to ever come back to bite my client, and also this requires me to be vague and my story somewhat hard to read. So here goes.
We have some software that tracks a certain kind of data. There is really no reason whatsoever that social security numbers should be part of this data. However, certain "upstream" entities, whom my client's customers depend on accepting my client's reports for "accreditation" purposes started requiring social security numbers attached to reports. Now, we're really not a bunch of retards, so our first response was to leave a blank space on our reports and let the customers fill this in themselves. But eventually some of the agencies decided that wasn't good enough, and required that we collect social security numbers from our customers, store them, and print them on reports. So we did this.
Fast forward a few years, not only has SOX put in a whole batch of requirements on companies that store that kind of info (which we have complied with), but some of the "upstream" agencies which we deal with, because of complaints from their membership, are now requiring that we not collect or store social security numbers, while others are still insisting that we do. Fucktards! There are really days when I want to buy a plane ticket and go strangle some of these dumbshits!!!
You're missing the point. The encryption doesn't prevent anything in 90% of applications, because the key mangement is terrible. You might was well just use base64 encoding and save the CPU cycles. Just using an AES-256 library function doesn't make the data secure.
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).