Schneier on Security
A blog covering security and security technology.
« 27 Suspended for Looking at George Clooney's Personal Data |
| Security Risks of Wholesale Telephone Eavesdropping »
October 15, 2007
Merchants Not Storing Credit Card Data
Now this is a good idea:
In a letter sent Thursday to the Payment Card Industry (PCI) Security Standards Council, the group responsible for setting data-security guidelines for merchants and vendors, the National Retail Federation requested that member companies be allowed to instead keep only the authorization code and a truncated receipt, the NRF said in a statement.
Erasing the data is the easiest way to secure it from theft. But, of course, the issue is more complicated than that, and there's lots of politics. See the article for details.
Posted on October 15, 2007 at 2:05 PM
• 32 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
I think everyone interested in Retail and Security should attend the NRF show in NYC in January. It's where all the tech companies sell to retail companies, and there are usually some interesting insights. It's not DefCon, so the security considerations are more hidden in marketing, but it's still interesting. I'll be there-
I wonder if the retailers are grandstanding to divert criticism and avoid having to secure systems that contain other customer data.
It makes sense for them to avoid storing account numbers, but as TJX showed they not only store things that they are not required to store, they store data they are prohibited from storing.
Seems like a smokescreen, or a political ploy to avert legislation.
Good luck getting the merchant banks to accept that additional risk and cost. The banks presumably like externalizing those problems...
Based upon past retail experience, I'm betting this is a way to get rid of certain time-consuming customers who try to make returns without receipts and expect the store to look up the transaction by CC#.
Well, yes, that's one of the issues. Nobody in this wants to be the sole caretaker of the data because that means sole blame when things get publicized. And the banks and card issuers are far more centralized than the retail industry, which means better talking points. So data gets spread around so that fingers can be pointed afterward.
Probably true as well... though from one of the comments that hit Slashdot, I get the impression that the official rules from the Payment Card Industry for 'securing systems' aren't exactly internally consistent anyway, which really doesn't help implementation.
PCI compliance is a money maker for the card brands. Being compliant means you have jumped through hoops and paid big bucks for your audit. Now, if you are not compliant (not every business model can be) they have in the contract that they 'can prohibit your ability to accept payment cards' though they never do. Now, if there is a breach and you are compliant, your MSP & Processor has to pay, which will eventually go after the issuing bank. If you are not compliant, prepare to get bent over! They will assume an amount of fraud on your behalf. They will pull this number out of the air, subtract 18% and stick you with the rest. Who gets that money? The card brand (Visa/MC/Amex/etc) the issuing bank. This can bankrupt a business. The more merchants that are non-compliant, the more revenue they can tap off this stream. Don't think this will become mandatory. There are already solutions out there to prevent CC fraud, but no one cares.
How would a merchant handle refunds, if he has only truncated data of his customers credit card?
Everyone seems to be going to a reference number, token or unique code to replace the card number.
@Marc: To handle a refund, the customer would need to supply the merchant with the same credit card information used for the initial sale - a credit card with the same last 4 digits and exp date.
I'm amazed that stores in the US need to keep all the CC information. Information that you don't have in your computer is information that can't get stolen, no?
With the date, last few digits of the card number, and authorization number, isn't that enough information to narrow it down to one transaction? As far as I know, this is all that required in Canada.
@CTheSoup: How would I know which of my credit cards I used with this merchant? Particularly if I want to return something the next day, way before I get my monthly statements?
This is a hugely problematic area that has arisen due to historic inattention to security on all sides. The technology model on which credit cards are based has serious security problems and is beyond its best before date. Current efforts to fix the system are unfolding on several fronts and are going to be difficult.
PCI is a reaction to account breaches. EMV/Chip is a reaction to fraud. They are complementary. Neither fixes the entire problem.
@Silva D - You don't understand the landscape when you claim PCI is a huge money maker for the brands. The assessments are performed by third parties, not the brands. And when there is a breach money must be spent to address the problem.
@Guvn'r - It sounds like there is a bit of grandstanding and deflection in the NRF position. Sending a letter to the PCI standards council is the wrong place. It should have gone to the CEO's of the brands who control the operating regulations. There is also lots of opinion that they already have permission not to store, see http://pcianswers.com/2007/10/11/...
@Marc the masked card number and the transaction authorization code should be enough.
@Bryan - PCI certainly has warts and inconsistencies but it is here and will improve security. How people react to the warts will have a lot more to do with how effective it is.
PCI is only a partial solution. One largely driven by breach history and drawing on industry best practice. It is by definition a minimum and a moving target. Fortunately, it isn't a fast moving target.
Interpreting the intent of requirements can be a problem.
Misunderstanding about compensating controls (not the controls themselves) are a problem - one that has been clarified.
Finding the reasonable path through remediation and balancing solutions to meet the requirements can be difficult.
Under and over remediation can be a problem. And one not helped by vendors who seize on PCI to oversell their solution or argue in favor of driving their pet requirements to very high compliance levels. Caveat merchant.
Retrofitting security into existing systems is a huge problem and expense.
Rushing to the wrong solution, a short term solution, can be a problem. Taking a stand and finding time to get to the right solution can be a trial.
The all or nothing nature is a problem. There is no sense of major and minor violations.
The shear size of the initiative and time frames are a huge challenge.
EMV (Chip and PIN) is another partial solution. One the US is lagging on and will probably pay for in the future.
Other PCI initiatives on terminals and applications are also partial solutions.
Even doing all of this won't eliminate fraud and breaches. But it should control it a lot more.
@DAG, thanks for all the good info!
Reading the linked story, and a blog it links to, it seems obvious this is just another example of the reaction being to push back against the need for security instead of accepting the need to solve those problems.
Those links make it clear that there is a widespread attitude that if only we don't story CC numbers there's no need to secure the retailer systems.
So the equivalent of a keylogger on magstripe swipe POS terminals is not a concern?!
Data storage is not the only problem, it's just the headline grabber because there are millions of accounts compromised in one exploit. Trouble is, if that's fixed there will be no concern about having millions of accounts compromised one at a time when the next TJX-style incident goes undetected for years...
I'm the CTO of a company that offers, among other things, online transaction services. I established a policy from the start of not storing credit card data, as simple security common sense (we let the card processors do it for us) and this has stood us in good stead with the subsequent introduction of SB 1386 et al. and PCIDSS.
It's a practical fact that every single one of these big compromises involved stored credit card data sitting on a server - not storing it reduces risk enormously.
The article contains one significant implied factual error - it says that you don't have to store the CSC (CVV2, CID2, etc.) number, when in fact, the card issuers forbid you to store it - you are only allowed to hold it for the time required to auth the initial transaction, which is typically a few seconds.
The CSC system was introduced specifically to prevent online use of stolen cards (unlike the PIN, the CSC is not on the magnetic stripe) and to offer a reliable alternative to the AVS street number and ZIP checking for fraud detection - AVS is a retrofitted hack and has an error rate of nearly 5%, which makes it more or less worthless in many environments.
PCIDSS has a lot of good practical security policy in it, but it has no scaling at all, and it is very much aimed at large installations - the same rules theoretically apply to momandpop.com as to Bank of America, though the Level 3 and 4 self-certification loophole ensures that mom and pop don't follow it in practice - new clothes for the emperor!
One point I missed - merchants *are* obliged to store the full card number (or, like us, outsource that function) because it is needed for a number of purposes:
1. Although transactions are authorized in real time, they settle in batches. A full card number is required for the settlement file for most processing platforms. This means keeping it for 24 hours.
2. You need the card number to issue a refund - this means keeping it for the duration of your refund policy, often 30 days or more.
3. If you're doing automated monthly billing or installments, the card number has to be presented and authorized every month - this means storing it indefinitely.
The brands / platforms could solve this problem generating a **unique** and cryptographically secure reference code for each authorization, and allowing that to be used for purposes 1-3 above.
Call me biased, but presuming that this is the thrust of the request, I find it very reasonable.
That securityfocus article is misleading:
"PCI stresses that most transactions do not need to store the full account numbers or the CVV2"
It actually stresses that the full card number doesn't need to be stored except in rare cases (only for a recurring charge in the future, NOT for refunds or chargebacks), it recommends minimum standards for how to store it and it also FORBIDS storing the CVV2. (This is the big one)
The NRF's letter is a smokescreen. They complain about the difficulty of doing something they shouldn't do, that they themselves insist on doing for bogus reasons, and they've frequently been told to stop doing.
@DaveC - ty good points. I'm not sure if there are any regional variations in this operating regulation.
@guvn'r - to your keylogger example. If you go through the PCI DSS and look at all the requirements, getting a key logger in place should be it much more difficult. PCI is about far more than encrypting data (ie. physical, config, hardening, network, monitoring, etc.), See http://www.pcisecuritystandards.org/
There is another related standard for POS (Pin Entry) terminals called PCI PED.
Plus there are other practical and useful anti-fraud things that are not in these standards.
@DAG, your comments about PCI standards would be more impressive if the number of merchants not meeting them were less. The whole NRF smokescreen is an attempt to weaken or eliminate requirements they are ignoring anyway, so expecting those requirements to protect against other threats seems incredible.
@Andy Dingley, your last paragraph almost hits the nail on the head, but their complaint is about the difficulty of securing it.
What they are saying is that the difficulty of securing something they aren't required to do but do anyway should exempt them from being required to do it...
You are correct when you say the assessments are performed by third parties and the card brands do not profit. But, you must not be aware of the fines imposed by the card brands. They will assume a level of fraud, lets say $100 million. The will be so kind to deduct 18% for baseline fraud. Then they will leave you with an $82 million fine. Somewhere on visa.com/cisp is a description of their method for taxing.
Are CC numbers really needed for refunds? I would suspect that the refund wouldn't come through as a nother CC transaction? Do I care which card it was on if I show proof of purchase from the store through a receipt? And heck, if I don't care about proof of purchase (some stores will take back anything), then why do I care which store gets the credit? I'm not doing a cancel on the transaction.
I know that I'm very happy with two particular vendors I do lots of business with. DigiKey doesn't store my card number. As comments above show, if they have my phone number, they can always get it again.
Better yet is McMaster Carr, who just set us up with an account, no questions asked. Pretty hard to hack as the ship to address is fixed. We are sure to pay them on time as they give a 2% discount for paying really fast.
I have had opposite results with some companies that are perhaps not so savvy about security. One gunsmithing firm I've dealt with has resulted in a hacked card -- twice for twice.
Someone dumpster diving because they are anti gun, know many gun guys are rich, and this outfit doesn't shred? Who knows. Can't do further business with them as a result, though.
Does this mean I'll no longer get customized coupons based on past purchases made with a given card? ("Huh, I didn't buy soy milk this week, yet a got a coupon for it....")
@Refunds, yes it will come through as another card transaction.
Many merchants will not do cash refunds on card purchases. They only do exchanges or process refunds as a credit to the card used to charge the purchase.
It's an anti-fraud measure, and makes sense to me.
I always assumed they got back at least a portion of the fees by doing a charge back, thus they insist on the same credit card.
In terms of VISA making money off PCI... fines are just the tip of the ice berg... that's more of a slap on the wrist compared to the money they make when moving a non compliant retailer into a higher interchange bracket. Interchange is what this is all about.
Even with the NRF piece of it in play, PCI is still a reality, it just might make it easier for some retailers to comply once the full card numbers are taken out of the equation.
And if that happens... VISA and the vendor community lose out on a serious revenue stream.
AFAIK the PCIDSS standard is intended to be pretty uniform across all countries, although there are local laws to consider (and in the US, this now goes down to the state level). US federal law forbids printing anything except the last 4 digits on receipts, even though PCI standards consider first 6 + last 4 with the middle digits missing as adequately masked.
The big variation is in level of adoption and enforcement of PCI compliance, and the US is quite far behind other countries such as Canada.
@Kevin - with most merchant agreements, they will only pay the interchange percentage on the net sales, i.e. refunds do get them fees back. However, in the credit card industry "chargeback" refers to something different - it's a transaction which is refused payment by the card issuer, typically due to fraud; the merchant is fined, typically $25 here in the USA.
@gork - they can use a one-way hash of your card number or track2 data (e.g. SHA1) to support consumer tracking without having the card number itself
@Several - I don't know of any US-based platform that will settle or process a credit / refund without a full card number; smaller merchants, or people like me who don't want to store card numbers, typically have access to this functionality from their intermediary gateway vendor, but big retailers typically integrate their IT systems directly to the platforms, so they are storing card numbers in-house.
@DaveC - storage of prohibited data (e.g. track 2) even hashed track2 is forbidden. Hashing of PAN is fine but please use salt.
PCI is the only standard I know of that allows storage of information at one point of time and then forbids it after an event (i.e. authorization).
I really don't think PCI was put in place to extract profits through fines or higher interchange.
Fines are what they are, compliance fines are not that much different from other fines. Often people who get fined are chronic violators. Some are unlucky. Fairly or not, fines are the penalty for getting caught or ignoring an authority.
If fines aren't exact or accurate enough for some they could implement controls to better track their exposure. But then that would be substantial parts of PCI.
I do agree that more transparency in the fines process would be helpful. The only brand I know of that publishes anything is Visa US, and that in summary form. The other brands consider this information confidential ASFAIK.
Why don't I just store a hash of the credit card number......
I am interested in better understanding what the actual costs would be by both retailers and processing networks to implement such a proposal. Can anyone shed some light on that?
I want to confirm that only the last 4 digits of the credit number can show on a customer receipt and the retailers receipt copy. I understand a retailer can be charged $1000. per transaction for each transaction showing the entire credit card #. Is there a NYS website or federal website that confirms this information?
@ Lori -
There is a separate law in the US called the Fair and Accurate Credit Transactions Act (FACTA) (which amended the Fair Credit Reporting Act (FCRA).
Here's an announcement from the FTC on the topic - http://www.ftc.gov/bcp/edu/pubs/business/alerts/...
As amended by FACTA, FCRA requires truncation of receipts provided to customers. (Failure to truncate on receipt copies retained by the retailed might not violate FACTA, but would likely be a violation of PCI DSS.) FACTA provides for statutory damages of a minimum of $100 and a maximum of $1000 for knowing and willful violations of the truncation requirements.
Since December 2006, plaintiffs’ class action firms in California and elsewhere have filed over 200 nationwide class actions in federal court against a broad spectrum of retailers and restaurants alleging violations of the FACTA. Fortunately for retailers so far, courts have taken a fairly conservative stance on interpreting what it means to "knowingly and willfully" fail to truncate.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.