Verified Insecurity

One of the issues that has worried merchants who are trying to sell on the Web has been the reluctance of some consumers to use their credit cards over the Internet.  The SSL/TLS protocols for ensuring a secure, encrypted connection between the browser and the server are in part a result of this.  More recently, a new security addition has been developed, called 3-D Secure, has been introduced; it is more commonly known under the trade names Verified by VISA™ or MasterCard SecureCode™.  In essence, this system adds an additional interaction to the process of making a credit card purchase at a Web site; an additional form appears on the screen, asking the user to enter a password to confirm (s)he is the owner of the credit card.  This system has proved relatively popular with merchants, since they have an economic incentive, in the form of lower charge-backs for bad transactions.

However, in a paper [PDF] presented at the Financial Cryptography conference last week, researchers Ross Anderson and Stephen Murdoch, from the University of Cambridge Computer Laboratory, argue that, while the 3-D Secure system has been successful because of its economic incentives, its engineering leaves a great deal to be desired, especially from the consumer’s point of view. As Ross Anderson put it, in a post on the lab’s security blog:

From the engineering point of view, it does just about everything wrong, and it’s becoming a fat target for phishing.  So why did it succeed in the marketplace?   Quite simply, it has strong incentives for adoption. Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders.

Some of the problems with the system are primarily technical: the usual method of presenting the password verification form is through an IFRAME, which means that the normal browser mechanisms for  indicating a secure connection (such as changing the color of the address bar) will not work.  Some card issuers offer users the option of setting up the password when the first transaction is attempted, and use very weak authentication methods (such as asking for the cardholder’s date of birth), which are popular targets for phishing attacks.  (I have written about the use of this kind of “security question” before.)

Another consumer-unfriendly aspect of the system is its use, by the card-issuing banks, to introduce modified contract terms that apply to the “verified” transaction.   The consumer, who is focused on completing the transaction, is unlikely to read these contract amendments carefully, and some banks are using them to shift all liability for fraudulent transactions to the cardholder.  In addition, of course, banks generally tend to like new electronic transaction forms, in significant part because they are not subject to long-established consumer protection rules that apply to paper transactions.  (For example, if the bank pays a check with a forged signature, under US and UK law it is the bank’s responsibility; but this typically does not apply to electronic “signatures”.)

In essence, the system does not do much at all to enhance the security of the customer.  The merchants, who pay for the implementation of the system, do so because the banks give them an economic incentive; and the banks like the system because it gives an aura of security while allowing them a sneaky way to shift liability to their customers.  As has been often observed, if you have a scheme to rob Peter to pay Paul, you can count on Paul’s enthusiastic support.

The paper does contain some suggestions for methods that would enhance security.  One idea, for example, is for the bank to transmit a one-time verification code to the cardholder’s cell phone via an SMS text message.   The potential thief would have to be able to access both the credit card and the phone to complete a fraudulent transaction.  The key message is that the problem is technically solvable; what is needed is rules that align economic incentives properly.

Comments are closed.