Contactless backers have always pooh-poohed this as a security threat, pointing out that customer names, security codes and other authentication information isn't transmitted by the cards. But if retailers are only relying on numbers and expiration dates, with one contactless grab—or one well aimed digital picture snap from a mobile—thieves get all they need.
And although the E-tailer's customer-service department insists that card numbers with the wrong name attached should be rejected, a simple experiment made it clear that at least some transactions are approved that way. (Two out of two media tests had transactions approved and shipped.) If it had been fraudulent, it would have been up to the payment-card holder to notice, complain and get the charge reversed.
L.L.Bean did not respond when we described the problem by E-mail. That's troubling, too. There could be a strategy behind this approach—for example, that the company has decided it's willing to take the loss for what it calculates to be a small number of low-value fraudulent purchases that it doesn't catch. But without an explanation, it's impossible to say whether it's a policy or a security hole.
The point here is clearly not that L.L.Bean is less secure than other chains. Indeed, the significance of this situation is that many other chains have similar security holes. It may be against policy—as it is with L.L.Bean—and it may be against how customer service is trained, but it happens.
For more than five years, payment vendors have been arguing that the data leaks created by contactless cards are not a concern, because they generate insufficient information to make a transaction with a major E-tailer.
Our experiment began after we received a tip that a purchase would go through on LLBean.com with only a card number and date. The editor who placed the order used his own card number and expiration date, but used an address that was in no way associated with the credit card used (even the ZIP code was different). The name used for the order had the same initials as the card holder, but couldn't have been mistaken for the name on the card account.
The E-Commerce site's system accepted the order for an under-$25 item with the valid card number and non-matching name and address. Within a few minutes, an initial confirmation arrived at the Gmail address given with the order. Less than 90 minutes after that, another confirmation arrived with an order number and word that the order was being processed. More than a day later, a third E-mail message arrived, confirming that the order had been shipped. The payment card was charged on the day of the order.
During the long gap between getting an order number and getting shipping confirmation, we called customer service and inquired about the order by order number. We expressed surprise that the name was wrong, muttered that it was because someone else had actually placed the order for us, and corrected the name—but not the address.
The customer-service rep told us she could correct the name in the system, but she couldn't stop the order because the package was "already on the truck." When we expressed surprise that the order would go through with a name and address that didn't match the card, the rep said, "I'm not sure why it went through. It shouldn't have."
That's as much of a response as we were able to get from the retailer.That's as much of a response as we were able to get from the retailer—which is surprising, considering the current level of noise over the leaks of E-mail addresses from Epsilon, non-card personal information from Sony's PlayStation Network and PIN-pad tampering at Michaels. Those incidents are getting large amounts of attention, even though they required plenty of effort on the part of thieves to steal the data.
But with L.L.Bean, there's no sophistication required—just information from the face of a payment card. That's easy to acquire. It might come from a thief scooping up numbers from contactless cards in a crowded place. But a thief could more easily snap a photo of the card with a mobile-phone camera when a customer uses the card in line at the checkout. Or if a customer puts the card down momentarily at an ATM. Easiest of all would be to simply get some card numbers and expiries from a cyberthieves' site on the Internet.
Without a name or ZIP code match, much less a CVV number, the only authentication is the expiration date. That's no authentication at all.
At a time when politicians are falling all over themselves to berate retailers and service providers for failing to protect non-financial information like the passwords to a free online games network, and when real-time authentication of payment cards is at the center of mobile-payment schemes, authentication should be a baseline requirement for any online transaction. Why wasn't it here?
It's true that if this had been actual fraud, instead of a purchase by the actual cardholder, the cardholder would probably have been able to get the charge reversed. And because L.L.Bean had made the transaction without proper authentication, the retailer would have eaten the loss.
That's still a bad idea, because it depends on the cardholder—who may not even be a customer of the online retailer—to spot the bad charge, initiate a request to reverse it and generally do all the necessary legwork. From a financial standpoint, L.L.Bean would only get dinged for the charge if the cardholder noticed it in time to challenge the charge. If that cardholder wasn't an L.L.Bean customer, that's not exactly a great marketing gimmick.
And if the cardholder did happen by coincidence to be an L.L.Bean customer? When a customer connects a fraudulent charge with a retailer, the customer usually concludes that the thief somehow got the information from the retailer. That's no way to make customers happy.