"Right now it is very easy to get somebody's identity," said Eugene H. Spafford, executive director of the Center for Education and Research in Information Assurance and Security at Purdue University. "Plus there is a low threshold for authentication." To use someone else's credit card, for instance, all that is needed is the number, name, expiration date and, possibly, the three-digit security code. (In the CardSystems case, all that information was stolen.)What may be additionally required, Mr. Spafford said, are stronger authenticators like so-called digital wallets, which contain all the data needed for transactions in encrypted form.
Some experts argue that protecting personal data is a hopeless task, that the emphasis should be on making transactions more secure."Making information harder to use is the key," Mr. Schneier said. "Making it harder to steal is a dead end."
This deserves some unpacking.
The basic problem with credit card authentication is that the information required by the merchant to run your credit card is exactly the same information that you require to use it: the number, the exp date, the security code, and maybe your ZIP. Every time you give your credit card to someone in a restaurant, they have an opportunity to steal your card information (remember having to tear up your carbons?). And of course, Mastercard's database has exactly the same information. So, any compromise of the merchant's or issuer's systems leads to the attacker being able to forge credit card charges. Not all authentication systems are like this.
Credit card authentication is tricky because it involves a large number of parties (you, the merchant, two banks, VISA...) so let's take a step back and talk about a simple system: user authentication where I convince some remote computer that I am who I say I am. The way that all of these systems work is that the server has some verifier V that it stores with my record. I have some secret information S that corresponds to V. When I authenticate, I provide an authenticator A (based on S) which the server checks against V.
Roughly speaking, there are three classes of system:
V=S and the server stores S.
Anyone who compromises the server once can simply steal S and
can then impersonate me to the server any time that they want.
These systems are usually called password-equivalent.
A=S.
This is how style UNIX passwords (and a lot of SSH password authentication)
works. The system stores a password hash and the user gives
the server his password. If the server is compromised and the
attacker steals the password file, then he can't directly impersonate
the user. However, if he has long-term access to the server he can
of course capture the user's password when it comes over the network.
In addition, because the system needs to be able to compare
V and S the attacker can verify whether a given
S is correct by checking it against V. This isn't
a problem if S is well-chosen, but if its, for instance,
a common word, then it's pretty easy to guess. This is called
a Dictionary Attack.
S,A, and V are all different.
This is how public key authentication works. You store the private
key (S). The server stores the public key (V))
The server provides some challenge which you sign to create
A. The server can verify that you know S but
can't use that information to impersonate you to anyone
else. (Note for crypto-nerds: the non-password equivalent
zero-knowledge password protocols fit roughly into this category as
well.)
From a security perspective, public-key type systems are vastly superior. However, their deployment has been spotty at best. The major reason is that it requires changing both the client and the server. In particular, computing A from S is nontrivial and requires software on the client side, which is an obvious deployment hassle. This used to be a big problem with login authentication, but in the wake of the wide deployment of SSH it's starting to go away--though other usage and user education issues still remain. However, it's easy to see how it could be a problem with credit card systems, since the terminals used to authenticate credit cards are extremely primitive and the protocols are difficult to change.
Credit card authentication is more complicated but basically a password-equivalent scheme. You give your credit card to the merchant, they give it to their acquiring bank, and so on all the way down the line. Anyone in this chain has the opportunity to steal your credit card number and use it. Merchants routinely keep copies of your credit card to enable features like Amazon one-click, so merchant database theft is a real problem (as-is merchant fraud). And of course the back-end probably has all the credit card numbers sitting in some database, ready for theft (this isn't the only implementation, but it it's the easiest one.).
So far, most of the reactions of the credit companies have been to add new authenticators that aren't actually printed on the credit card (your ZIP code and the security code) but since those authenticators need to be provided to any merchant you want to do business with they won't stay secret for long. As long as the system is designed so that your "secret" information and the information the merchants get are one and the same, credit card theft and fraud will continue to be a real problem.
In my next post on this topic, some of the obstacles to removing password equivalence from the credit card network and a special SET retrospective.
