Is a new protocol needed for credit card transactions?

Question

It seems like many places spend a ton of time and money securing their site for credit card transactions. However, there are still millions of credit card numbers being stolen. Fraud is big business, and easy to do online. In Europe, credit cards have been almost entirely replaced with chip and pin systems that protect against stealing of credit cards at the terminal and the loss of physical cards. This is starting to make its way to the US and Canada as well. However, the easiest place to steal credit cards seems to have been the internet for some time now.

So I've been thinking, would it be possible to create a secure protocol for placing credit card transactions online so that sensitive data doesn't need to be sent to the web server? Is it even feasible to migrate to such a system?

What I am thinking is along these lines:

1. Merchant contacts their processing service provider and obtains transaction code.
2. Merchant responds with transaction code, amount/summary, and processor information via HTTP headers, with content to fall back on if the client doesn't support it
3. Client sends a request to their issuing bank with authentication information, passing along the same information sent by the server.
4. Client's bank checks funds and contacts the merchant's processing service provider, agree on the information, and gets an approval code if the transaction is good
5. Bank responds to client with pass/fail details
6. If the transaction failed, the client can try another account or responds to the server with failure
7. On success, the client responds to the server with the approval code
8. Merchant confirms the approval code with their processing service provider and captures funds when ready

In this scheme, the client and merchant never exchange sensitive information. So you either have to attack the banks, the client's machine, or replace the credentials on the server so everything goes to your personal account (which is risky).

I guess this isn't so much of a question, as it is looking for thoughts on how to improve things.

Answer 1

You've asked a bunch of questions.

Do we need a new protocol for credit card transactions? "Need" is not the right word. Credit card security is all about risk management: balancing the losses due to security problems, against the costs of a better security mechanism. In the credit card space, there are huge costs to changing the protocol, given the huge deployed base. In addition, anything that makes it even a little bit harder or less convenient for credit card holders to make a purchase has major implications for the credit card company's bottom line, so credit card companies may be glad to accept some rate of fraud if in return making a purchase is really easy and convenient.

So, while the current protocol for credit card transactions (send your credit card number in cleartext to the server) has almost no security from a technical perspective, it may well be good enough, when you consider the costs of the alternatives. In any case, this is not a yes/no question: it's a matter of balancing the risks and the rewards.

Is it chip-and-pin more secure? Chip-and-pin eliminates a number of security problems in prior systems. However, it has problems of its own. First, there have been some security problems found, in turn, in chip-and-pin.

Second, adoption of chip-and-pin in the UK was initially tied to a change in the liability model in a way that has harmed consumers. In the event of a disputed charge on your card, what happens? The answer used to be: by default, the bank would refund you (if you claim you didn't make the purchase, the presumption lies with you: the bank had the burden of proof if they wanted to argue that you are lying). With the adoption of chip-and-pin, many banks changed the model: by default, you have to pay (if you claim you didn't make the purchase, the burden of proof is on you to prove it). I'm not familiar with the latest status, so I don't know if this is still true, but I think it illustrates a general risk to consumers.

In particular, when new protocols are adopted, there is an opportunity for mischief: an opportunity for banks to claim that the new system is so secure and so impenetrable that, in the event of a dispute, the bank's computer systems should be presumed correct.

Could we design a more secure protocol for web-based credit card transactions? Yes, certainly. The primary challenges are not technical in nature -- rather, they relate to the ecosystem. There are many players here, with diverse interests, and any change would need to be adopted by most or all of the players -- which means, a new protocol will only be successful if it is in all of their interest. Designing a protocol that reflects these ecosystem constraints, and is simultaneously more secure, is the real challenge.

Before diving too deep into design of a new protocol, I suggest you start by studying history. For instance, you might look at SET, a protocol which encrypted the customer's credit card number on the client side, so that the merchant never got to see the credit card number (only an encrypted version). Sounds like a good idea, right? Yet SET went nowhere, for a number of reasons related to legacy issues and ecosystem considerations. So, study your history, and learn from it.

Resources for further reading. I suggest the following papers and resources to learn more:

• Optimised to fail: Card readers for online banking, Saar Drimer, Steven J. Murdoch, and Ross Anderson. Financial Cryptography 2009. See also the associated short blog post.

• Wikipedia on EMV Vulnerabilities.

Answer 2

If you don't want to transmit sensitive information, a disposable credit card protocol exists. It's not widely spread but at least one bank in France provides this system. When you need to make a transaction, you go on your bank online site and generate a single-use credit card number. You can use this virtual-card to purchase something online as you would do with your real card. The single-use properties ensures the number can't be stolen to purchase other items.

Other newest protocols include the use of two step authentication, where you have to provide a second code sent to you on you phone by SMS. These are useful to avoid someone using a stolen number. Unfortunately, it would required the protocol to be use by everyone to be efficient.

As far as a new protocol is concerned, I would reserve myself from assessing it. It's a bit like cryptography and would require a full scientific analysis before validation.