Two-factor credit-card safety for online transactions

* Protecting against credit-card fraud online

A guest author writes: "The problem with incorporating a second factor in online credit-card transaction processing is the backend process. Changing the data formats would require millions of vendors to adapt the new process - so expensive that it's unlikely to be implemented. An interesting idea to overcome this massive redesign problem would be to include authenticating information for the transaction in the credit-card owner's name field."

My friend and colleague Jurgen Pabel was one of our first graduates from the Norwich University Master of Science in Information Assurance. He is an active participant in our alumni discussion group and a frequent and welcome correspondent. Here, I present his latest suggestions (entirely his with minor edits and additions).

* * *

Bank of America's SafePass program described in the Jan. 3 issue of this newsletter prompted the following proposition.

Just a few years ago every credit-card transaction was authenticated by two factors: the actual credit card (possession) and either the correct PIN or a valid signature (knowledge / capability). The Internet broke this security scheme in that it was no longer possible to verify the possession of the actual credit card.

Banks responded by adding the credit-card verification (CCV) numbers on the back of the cards, but if the card is stolen that doesn’t help stop fraud either.

Adding a second factor to the login process for online banking portals is a good measure to reduce the risks of unauthorized access through compromised credentials. The SafePass program introduces the customer's mobile phone as a second factor for authentication to Bank of America's online banking portal.

However, millions of credit-card users still depend solely on the secrecy of their credit-card information to guard them against online credit-card fraud. A new universal second factor would be useful, even though in most cases customers are liable only up to a certain amount in case of provable fraud; someone's got to pay the bill, and it isn’t the banks: it’s people who pay finance charges on late credit-card payments.

The problem with incorporating a second factor in online credit-card transaction processing is the backend process. Changing the data formats would require millions of vendors to adapt the new process - so expensive that it’s unlikely to be implemented. An interesting idea to overcome this massive redesign problem would be to include authenticating information for the transaction in the credit-card owner's name field.

Any bank issuing credit cards would be able to extend its transaction-authorizing process either to require the physical card to be present (swiped) or to require a one-time code to be included in owner's name field. These changes would not require any modifications outside of the issuing bank's infrastructure. The authenticating information might be transmitted via text-message to the customers mobile phone number - transforming the mobile phone into the second factor as in the SafePass program.

There are additional aspects to consider. First, there are going to be vendors with whom customers frequently execute online credit-card transactions, and they will want to be able to save their credit-card information in their customer profile at the vendors’ Web sites. It must therefore be possible for customers to mark certain vendors as trusted for transactions where the authentication information won’t have to be present in the name field.

Under this scheme, compromised credit-card records would pose a much lower threat of unauthorized charges to customers because they could not be used for most transactions, as they would contain no usable authentication information. The exception would be unauthorized charges with vendors the customer has marked as trusted, but vendors could employ mechanisms to either prevent or to detect such fraud - such as blocking deliveries to unauthorized addresses or requiring confirmation from the authorized e-mail accounts - and thus give customers reason to declare them as trusted with their bank.

A lot more nitty-gritty details would need to be worked out; for example, how do customers notify their bank that they are about to conduct a transaction and thus need a new one-time code? I welcome contacts from readers interested in pursuing discussions of these ideas. Please contact me via e-mail to discuss this and other solution alternatives. 

[MK adds: I’ll be happy to get a detailed proposal published.]

* * *

Jurgen Pabel, MSIA, CISSP, is a consultant with Akkaya Consulting Gmbh. He runs an interesting technical blog that often includes security topics. He last wrote for this column in 2006

Learn more about this topic

 
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.

IT Salary Survey: The results are in