An idea for improving credit card security

It seems like there’s always some company or other letting its credit card database fall into the hands of a malicious party, whether it’s internal or through the Internet. It’s obvious that people don’t know what they’re doing when it comes to taking necessary precautions to protect their data, and that they’re really good at storing it in plain text, which makes it simple to index.

What if it were possible for the model to shift in a manner that both introduced multi-factor protection on data and lets the clueless keep doing business without needing to learn anything new or change their processes at all (particularly that plain-text thing, since it’s so efficient)?

What I’d suggest is really quite simple: don’t store credit card numbers anywhere. At all.

Now, of course, the first response I’d expect to hear, were I to stop there, is “but we can’t take a hash and reconstruct a value understood by the processors, and encryption still involves storing the number!”, and whoever were to say that would be entirely right. The next thing I’d expect to hear is “but if we do away with credit card numbers, users won’t know how to pay for things!”, and this, too, is right.

Credit cards wouldn’t have to go away or change form at all. Numbers would still be transmitted over the Internet, covered by whatever transport-layer security is deemed acceptable by the involved parties, but something magical would happen when they’re received: they’d be sent to the credit card company, just as they are now. Shocking revolutionary twist, isn’t it?

No, it’s not quite that simple, but it’s pretty close. The credit card number would be sent along with a credit-card-company-issued merchant-ID and a unique identifier would be sent back, forever marrying the customer’s payment method with the merchant (no cryptographic integrity needed — it can be a predictable, sequentially-issued number, so long as it draws from a universal, multi-merchant-accessible pool to let entropy do its thing to prevent systematic lookups). Upon receipt of this identifier, the credit card number would be discarded and the identifier could be stored as an attribute of the user’s account on the merchant’s end. When the user wants to make another purchase, the identifier gets sent to the credit card company again and the onus is solely on that party (which should have nigh-impenetrable security) to figure out which financial institution’s patron to charge for the transaction.

“Okay, so… uh… what if the identifier gets compromised?”, I imagine to be the looming question to be. The answer is elegant in its absolutism: nothing.

The identifier uniquely identifies a pair of entities: the customer and the merchant. If the credit card company receives an identifier from a party other than the merchant to which it is registered, the transaction is void (and easy to stop, through an immediate severance of the binding) and if the merchant attempts to act fraudulently, the customer has a very clear path of recourse. Consumer-protection failsafes notwithstanding, the only circumstances under which an attack would be profitable to a malicious party would be if the merchant provided goods or services they cared about, and for that vector to be exposed, the attacker would need to have inside knowledge of how data actually flows between components of the merchant’s architecture, which would require the compromise of many disparate systems, providing multi-factor protection through the omnipresent mashup of security-oriented design and brain-breaking “MAKE IT WORK NOW” kludges.

To summarise this idea, a single sufficiently large numeric identifier (probably 1024-bit to start, which allows potential for easy expansion and eternal backwards-compatibility) would identify a customer (credit card) and a merchant (registered business) in a manner intelligible only to the credit card provider, the party with the greatest investment in security. This identifier could be stored unencrypted in databases and be protected by processes and checks, rather than arms-race-oriented encryption and social trust.

The fact that this identifier is bound to exactly one relationship means that its external value is non-existent and that its potential for harm, should it slip, is limited to that one relationship, making it something that can be treated as an attribute of another pre-existing parallel relationship (the user’s account with the merchant — though one-offs are fine, too, if the merchant doesn’t need to request an identifier), which allows whatever security resources a merchant has to be focused on protecting user data in general, for the company’s benefit, rather than the patron’s. (Authentication like Amazon’s or that of reputable banks would be a beneficial, but unnecessary, complement)

Lastly, the way that the identifier is known to only two parties (the merchant and the credit card company) means that it can be quickly abandoned (from the merchant’s end) if it ever gets compromised, without having any more impact than requiring a new identifier to be issued in a subsequent transaction.

Just a thought, though. Feel free to cite this to help overturn any patents that may be issued around a similar idea — security shouldn’t be encumbered.
Seems Moneris has been doing something similar for a while. Oh, well. At least the idea’s been implemented in some capacity.

Leave a Reply

Your email address will not be published. Required fields are marked *