Password equivalence and identity theft (II)

Static and reusable
Because the credit card number almost never changes, you can memorize it. Even better, merchants can memorize it, which is what lets Amazon do 1-click ordering.

Easy to read
There are three separate ways for the merchant to get the information they need to clear your credit card. The easiest is to swipe the mag stripe, but the raised digits let them use a credit card press (or even some carbon paper and a pencil in a pinch) or they can just transcribe the credit card number visually off the face.

Short
Credit card numbers are fairly short, which makes them easy to type in into fields (e.g., at Amazon). This would be impractical if the numbers were much longer.

Cheap
Finally, credit cards are incredibly cheap to manufacture. I don't know what credit card companies pay, but you can buy mag strip cards in lots of 1000 for less than $.15/each, so I imagine the price to the credit card issuers is more like $.05. Mag stripe readers are also cheap and credit card terminals are extremely simple and cheap to manufacture.

(Nearly?) all proposed more secure solutions involve giving up one or more of these properties. If it doesn't it's going to be basically isomorphic to credit cards: a symmetric key which you give directly to the merchants in order to execute a transaction.

The naive approach that everyone thinks of first is to use digital signatures. Every credit card account gets a public/private key pair and when you want to execute a transaction you just digitally sign it. This is an outstanding design in that it manages to sacrifice nearly all of the above properties: You'd sign each transaction separately so the authenticator always changes. Performing the signature requires extensive computation so it's not cheap. The signatures are long (The shortest digital signature scheme based on a standard assumption (BLS) is 163 bits long, which maps to about 50 decimal digits! (Yes, there are alternative encodings but they're still long.)) so you can't really type them in, meaning you need some kind of electronic interface to deliver them. Probably no more mag stripe interfaces, at least not static ones.

Despite all this, signatures aren't an inherently bad technology for making purchases on the Internet. Of course, they'd require entirely new software deployments on the client, but that's arguably merely a transition problem, and software only takes half of forever to replace. However, for in-person transactions that involve swiping credit cards, this means that the customer has to have some handheld computing device. Typically this is assumed to be a smartcard, which means replacing every point of sale terminal--not an easy task. Even if you've succeeded, note that you've now basically ruled out the possibility of dump POS devices like the old credit card swipe machines. I still get asked to use these fairly often...

Years ago I was a bit player in Visa/MasterCard's SET signature-based electronic payment system. SET managed to have all the disadvantages I mentioned above and then some. Aside from requiring extensive processing on the client side, the protocols and PKI in particular were fiendishly complex. In addition, the computational effort required on the server side was truly excessive. To make matters worse, Visa and MasterCard never offered any real incentives to merchants to deploy SET. This explains why going on 10 years later you're still not using SET to buy stuff on the Internet.

Another possibility is to have a device that simulates a credit card but that produces a different credit card number for each transaction. The card would generate a stream of valid credit card numbers (some credit card issuers already have web sites that let you produce temporary numbers in order to let users shop online while reducing the perception of fraud). This type of system can be made to have a lot of the same UI properties as today's system: the numbers would have to be a little longer but not enormously--maybe 20 or 25 digits instead of 16. You could implement this with a smartcard but a more attractive approach would be with an LCD display like a SecureID card. Then people could key in the numbers just like with a conventional card. You might even be able to convince it to simulate a mag stripe, just like those CD-to-tape adapters you can get for your car. Merchants wouldn't necessarily be able to store the number, since it would change every time, but you could imagine having the card also produce long-term codes one per merchant, thus making merchant database compromise more easily containable. This design has at least one major disadvantage: the cards are sure to be expensive and will likely be bulkier than an ordinary credit card.

The principal concern with any of these systems is getting merchants to be willing to deploy them. The issuers can ship new cards to users whenever they're ready, but unless the merchants deploy the readers and server side software, people will have to use standard credit cards. Back when I was working on SET, everyone assumed that the acquiring banks would give merchants who deployed SET a break on their credit card processing charges, but as far as I know this didn't happen--though they may have belatedly decided to do it after I was no longer involved. Some incentive like that will surely be required to get deployment of any new system: remember that customers have no real liability when their cards are stolen so their incentive to change is extremely small.

If we ever do see attempts to deploy a new system, expect the initial few generations of cards that get rolled out to be dual purpose, e.g., a smart card with a mag stripe and raised credit card digits on the face. You could use the card in either mode but merchants would get a break for using it in secure mode. I don't see many signs of this happening in the US though. I keep hearing that smartcards for financial transactions are big in Europe, but I'm not that familiar with the European financial industry so I don't know if this is true.