Whenever another batch of millions of credit card numbers is compromised, as happened again recently, the same reactions predictably ensue. Security experts climb out of the woodwork offering interviews on how to harden computers and networks. Payment processors acknowledge mishandling of records. But nobody talks about reducing the attack surface area so that when systems are breached, and when procedures aren't properly followed, the consequences are far less severe.
The phrase "attack surface area" shows up mostly in the context of Microsoft's efforts to increase the inherent security of its products by doing the things everybody said they should have been doing all along: running by default with the fewest possible services, and with the least possible privileges.
Reducing attack surface area is a general strategy, though. The simple single sign-on technique I've been writing about recently is a variation on the theme. Giving websites derivatives of valuable passwords, rather than the valuable passwords themselves, limits your attack surface area.
In the realm of payment processing, a similar idea has been floating around for a long time. It's been six years since I first mentioned the notion of one-time credit card numbers in a couple of columns. Why haven't we advanced this story?
There are two main arguments. First, with minimal to no liability for losses related to unauthorized purchases, U.S. cardholders aren't feeling much direct pain. Second, no alternate scheme approaches the convenience of the current one. Both arguments are really lame. Can't we do better?
Somebody will. Absorbing losses isn't a great business plan, and neither is operating a system that is demonstrably vulnerable. Convenient one-time credit card numbers -- available not only in your browser for online purchases, but in your wallet for store purchases -- will make some entrepeneur rich, and will make a lot of people feel safer.
More generally, we need to internalize the underlying concept. Whenever we transmit or store a datum of permanent value, we expose it to attack. So, wherever we don't have to, let's not do that.
Former URL: http://weblog.infoworld.com/udell/2005/06/20.html#a1253