There's a rather active thread on the forum right now about this topic and it's*****ing me off, so I thought I'd expand on it and write on it here.
If you're a small business and accept any form of "plastic card" payment, you have issues to deal with regarding security. The only exception is firms that have a "swipe" reader and store nothing -- in other words, they use one of the "XON" terminals or similar.
If you have a computer system that takes credit card orders and numbers, you have this issue.
Small Merchants
You must secure cardholder data to meet Payment Card Industry rules!
Small merchants are prime targets for data thieves. It’s your job to protect cardholder data at the point-of-sale.
If cardholder data is stolen – and it’s your fault – you could incur fines, penalties, even termination of the right to accept payment cards!
Learn how the PCI Data Security Standard can protect cardholder data and prevent theft.
Yeah, payment card industry rules intentionally designed to make it possible for them to slough off their responsibility for security onto you, the small merchant, thereby intentionally disadvantaging you as a business compared to those larger firms that have monstrous internal IT support structures.
I've got more than a bit of experience with this, having dealt with it when I ran MCSNet in the 1990s. Back then we had the same problem but dealt with it in what were at the time reasonably-effective means.
In short the problem comes about as soon as you accept and store, for any length of time, a credit (or debit) card number. That number, plus an expiry date, forms the ability to charge the customer's card. When coupled with a CVV number (the three or four-digit number on the back) and/or a customer address, it's even more important as the former is not on the magstripe and the latter allows an "AVS" (address verification) match.
If you read the standards you'll find that they not only mandate that you "prevent" the theft of this data but they're now requiring audits by so-called "trusted parties" to verify compliance. Exactly how this process works is probably open to some negotiation but if you certify compliance and then later have a breach you're in trouble -- big trouble. Potentially business-ending trouble, as the fines are per card stolen.
When we started dealing with this back in the 1990s I went to the merchant processor we were using with a means to fix the problem permanently. They ignored me. Since this is back in the public consciousness I want to outline where the problem is, what I proposed back in the 1990s, and hopefully, through doing so, will cause small merchants to bring pressure through Congress, if necessary, to put a stop to the rabid anticompetitive behavior that is exhibited by these networks with their "rules."
Let me begin: We all want secure networks and consumers have every right to believe that when they go into a store or shop online their data will not be stolen and then used to rob them. This is an entirely-reasonable expectation and it's not that hard to do. But the merchant networks have designed procedures that could be easily tightened to prevent most data breaches from being effective, along with destroying the value of "stolen" databases in the "carder" network world.
The merchant networks have failed to do this and given the simplicity of doing so I argue their failure is intentional and has the effect of being severely anti-competitive to small and medium-sized businesses.
Today many merchants pretty-much have to store card numbers for three reasons:
- Return fraud. In short it's against card issuer rules to issue a credit to a card that you did not originally charge. Customers will occasionally try to do this for various reasons. They will also try to buy something on a card and then return it for cash, which is a round-about way to get a cash advance without paying the fee for doing so. You're required as a merchant to prevent these acts by your merchant agreement. In order to do so you need to be able to verify that the means of a refund or credit matches the original payment form.
- Chargeback investigations. Do you need that number? Most of the time no, but once in a while yes. The reasons for this are somewhat complex but if you think all issuers are straight-forward when you get a chargeback you're wrong -- they're not, and sometimes you suspect (or are very sure, because your system says so and so does your bank account) you already refunded the card. How do you prove the refund happened to the specific account in question if you don't have the number involved stored?
- Recurring billing. If you're an online service provider of some sort then you probably want to offer this. Some merchants don't -- on purpose -- because recurring billing often winds up generating a lot of complaints over hard-to-cancel charges and thus can generate a lot of chargebacks. But many merchants believe these risks are outweighed by the "convenience" to customers (and the flowing revenue from those who forget!) of "automated" billing. To do that you must have the card number on file to be able to resubmit it.
These two factors mean that many brick and mortar and virtually all online merchants (or those with any online presence at all) wind up having to store card numbers. This then turns their database into a treasure trove of useful information as the customer data (address, etc) along with the card number and expiry date is present. If stolen this is extremely useful, and when stolen in bulk it's very valuable indeed!
This is what drives the security and audit policies.
But those policies are never going to work. All security of this sort devolves into security of the key space, assuming secure encryption protocols. If I can steal the encryption key(s) used for a storage system I can steal the data. If I can compromise the system while it's running I don't need to steal the encryption keys, as I can just ask for the data and it will be provided through the currently-valid set of credentials. Both are a problem and the solution is not to have millions of merchants with supposedly-secure data stores where the security of all depends on effective key management. That is only defensible as a design if it is necessary.
This design is not necessary. It's done this way because the processing networks find it convenient to offload good security practices and their costs onto the small merchant, and in the process of doing so they not only radically increase your costs as a small merchant they destroy security for everyone, including consumers.
Look folks, this problem is not hard to solve. The merchant processors could easily change their operating protocol to work like this:
- When you authorize a transaction the merchant processor, in addition to sending back approval, sends back a cryptographic token (e.g. a 32-byte HEX value.) This value may be stored by the merchant if desired. The merchant thus never stores any card data at all.
- The returned token is valid until the later of some time period (e.g. 1 year) or the expiry of the card involved. It can thus be submitted in place of a card number in the future to authorize either charges or refunds. However, and this is the important point, it is valid only when presented from the merchant that originally obtained it.
Now you have a database that is utterly worthless if stolen. If I manage to rip off a database full of MD5 hashes I have nothing since the only way I can use them is to debit or credit the original merchant's account! Not only can I not use them with any other merchant I also can't reverse them into the card numbers themselves. The hashes thus have no value to a thief as they're unusable to do anything other than put money into (or take money from) the original merchant's account, which is of no value to him.
Note that the hash does not necessarily have to be globally unique -- it just must be unique for a given merchant during the time domain where it is valid. Only the processing network -- or the issuing bank for the card -- knows if the hash is valid or not in association with a specific merchant ID.
Incidentally there are card issuers that do this for "online shopping" -- Discover's "Deskshop" application is one of them. It generates "random" card numbers (tied to you) that are good only at the place first used and some of them allow multiple uses at the same merchant. But this model, in the generalized sense, is not implemented in the wire protocols for merchant processing networks.
Implementing this change reduces the problem domain at the merchant end to securing the physical network on which card numbers are fleetingly present during the original transaction processing process -- a much simpler process. Since there is now never a reason to store a card number, any storage of a card number, expiration date or CVV is now prohibited -- period -- and if caught doing it no matter who you are, big or small, your merchant account is permanently revoked.
At the same time the perfectly-valid business reasons to be able to ascertain with certainty that you refund to the original payment method remain intact and recurring billing is made easy. In fact, if you have brick-and-mortar locations and want to offer recurring billing you can now do so and get the security of "card present" chargeback protection since the original authorization that generates the MD5 sum can be done off a swipe! This is a significant boon to merchants and in fact was one of the reasons I wanted this back in the 1990s -- it would have been nice to be able to capture a digital picture and a physical card-swipe for customers who were willing to come into our office and set up recurring billing that way, thereby proving (1) they were there and physically authorized the transactions, and (2) that the card was physically present. Having such a token valid for a period such as one year (or the expiry of the card if less) would be perfect for most uses such as this.
Note that this change would shift the responsibility for security of the "large" data stores where it belongs -- to the processing networks and banks. Large-scale data breaches from merchants would instantly cease; if such a breach occurred in the future it would have to have come from either the bank or processing network itself.
More than a decade after I first proposed this with the noose tightening around the necks of small business it is time to push back hard against these monopolists. The merchant networks are at their core anticompetitive things which is why Dodd-Frank targeted swipe and interchange fees.
There is absolutely no reason for businesses to have to store card numbers on their networks if the card processors take an actual interest in real security instead of increasing merchant costs and presenting the appearance of security.
We're well past the point where small merchants should sit for this abuse.
Ps: Before the wailing starts on the use of MD5: It does not matter if the means of generating the hash is cryptographically secure. Think it through folks -- use of MD5 (or SHA-256) is simply for convenience -- the only important thing is that a valid hash is only valid for a given customer and merchant, and only the issuing institution knows if a presented value is valid from a given merchant. Sparse key spaces are desirable for attempted hack detection easier and tend to be more efficient during index lookups, but that's all. The processing network needs only the first four numbers of the card + the cryptographic sum -- the first four on a card are the issuer ID and thus route the transaction. There is no problem with merchants storing that, if you want merchant account portability, as the list of valid issuers is public and it doesn't help you get a valid account number.
