algebraicthunk.net/ blog/ entry/ Credit Cards, Security, and Common Wisdom

The news media here are reporting about yet another massive leaking of credit card information. As usual, we get the hand-wringing about computer security at corporations, proposals to require tougher punitive actions against companies that have lax security, et cetera. Underlying every report is an assumption that this is just the way things have to be: of course companies have to amass huge databases of highly valuable financial identifiers, and of course the only way to mitigate the harm caused by individuals breaking into these databases is to tighten the security around them.

But wait just a moment here. What is a credit card number, anyway? A credit card number is essentially a token which means (translated to English) "I, Daniel Burrows, authorize the bearer of this card to incur indebtedness upon my behalf up to $LARGESUMOF_MONEY." Shouldn't we at least think twice about spreading this sort of thing around? Again: I'm supposed to keep my credit card number a secret, but what earthly good is a secret that (by its very nature) I have to tell to large numbers of people?

Ok, so credit card numbers have problems, but is there any reason to think we can do better? Consider this question: why do we need credit card numbers in the first place? If you think about this a bit, you'll realize that the essential function that my credit card number serves is this: it proves my identity to the credit card company at the time that I use the card to fund a transaction. Can we do this without passing magic blank-check tokens around? Phrasing this more formally: is there a way for me to prove my identity, but without permitting the party to whom I am proving my identity to masquerade as me?

Well, readers with a technical background (especially any Debianites) should know that the answer is "of course there is!" (and the rest of you should have figured it out from the direction my rhetorical questions were tending ;-) ) In fact, this scenario is one of the key features of a modern public-key cryptographic system. Briefly, in a public-key system, I have a secret "key" that only I know -- no-one, and I mean no-one, besides me is allowed to know it. I also have a public "identity" corresponding to the private key -- everyone is allowed to know this. The system then defines techniques by which I can prove that I know the private key corresponding to my public identity.

Hopefully you can see some obvious applications of this idea to resolve the problems with credit cards, although of course this is just a sketch; there are issues I've glossed over or left unaddressed. However, the thing that really frustrates me is not merely that people have overlooked one technique or another; I'm not even especially bothered that we're still using the old horribly insecure system (even if a replacement system were ready to roll out today, it would take a long time to convert everything out there to use it). What bothers me is that there is this vast blind spot about the whole idea of credit card numbers. These things are a truly terrible idea in the modern day and age, and I wish more people would think just a level above the usual public discourse about them; not just "how do we fix the latest instance of this problem?", but "can we completely eliminate the cause of this class of problems?"

Or, <rhetoric>Stop trying to bail a ship full of holes, and ask yourself whether you need a new shipwright.</rhetoric>

Comment by Tim Donahue at 6:14 AM:

Most (all?) credit card companies have started putting 2 factor authentication into use with credit cards. This comes in a variety of forms but the most common 2 are smart cards and the 3 digit security codes (I can't think of the correct term for the code) that is found on the back of every card I have. I think the biggest problem is the all the legacy equipment that is out there. At some point the credit card companies are going to have to require the use equipment that takes advantage of the newer technologies that are available today.

Comment by Jeff Rasmussen at 7:40 AM:

Could you use the credit card plastic device to store the private key encrypted with your 4 digit pin?

I'm all for increasing security but I don't like changing the user interaction without deep consideration.

Comment by Anonymous at 8:19 AM:

This is almost exactly what the new "chip & pin" cards do. They're challenge & response. All we have to wait for are cheap USB smartcard readers and a common framework so that ordering that book from Amazon just involves you shoving your smartcard in and clicking away.

Comment by dburrows at 10:45 AM:

Just to underline my main point -- what bothers me is less what we're using today or the specific technology that could fix it, and more that it seems like the "common person on the street" doesn't even see that this is a fundamental and fixable problem with how credit cards work. People just assume that the way things work now must be the only way they can be.

This is important because any replacement for the CC# system will have to have buy-in from a lot of the population. I also suspect that to get it actually rolled out in a form we can use will require public pressure: the current situation seems fairly stable, and it will be a lot of effort and expense to implement a more secure approach. Worse, there's little if any guaranteed reward for the companies that perform the rollout. The credit card companies might do the right thing on their own, but I'd feel more confident about it if their customers realized how unnecessary this whole mess is.

Moreover, if people don't recognize this fundamental issue, the "fixes" that we get for this rash of security problems could turn out to be just window-dressing or feel-good measures. For instance: the three-digit codes are nothing security-wise, because they're part of your 'key'! You have to give them out as part of a transaction, so you don't have control over where they go. This was illustrated in the recent breakin, where the three-digit codes were stored right next to the CC#s in the database.

Now, it's true that the company that was storing this stuff (including the security codes) wasn't supposed to be doing so -- but this just shows that the security of the CC# system relies on your being able to trust a large number of people you don't know to be both honest and competent. Security-wise, this is something to be avoided if possible.

Comment by Simon at 9:58 AM:

A former colleague mentioned briefly a company who were looking at mobile phone payment.

GSM mobile phones have PKI technology in them, although I'm not sure the end to end security is there yet for big value purchases yet.

But GSM style payment solves the problem of stealing credentials, and provides a convenient method of seeking approval for payments, as the credential is effectively "I have this phone, and know it's unlock pin". Whether the approval is by dialing a number, or sending an SMS message, or whatever. It would also mean one less thing to carry.

Mobile phones are less resistant to water than credit cards through - could be some interesting failure modes.

A good example was a vending machine, you dialed a number, and it dispensed a drink, your mobile phone was billed. Your mobile phone credit limit acting to stop massive fraud. Note owning a mobile phone generally means you are good for 200USD of credit.

I think almost any mode of payment where the retailer provides technical equipment (i.e card reader or number pad) is likely to leave open opportunities for fraud or theft that simply don't exist if you are using your own technology (read mobile phone or similar).

Interesting idea, and I can't see people objecting if mobile phone security has to be improved to make it work securely.

Obviously the precise technology could change, but there is no reason why the retailer need know anything about you but that you know the transaction ID for the X dollars they just got paid into their account. Nothing for the retailer to misappropriate at all.

Comment by dburrows at 6:32 PM:

Sorry, but I've had to close comments on this entry -- it was attracting too much spam.