One of the key items on my 2014 prayer list is security. While I continue to believe that we really can address security to a very great (but, of course, not absolute) degree, we simply do not. Maybe it's the fact that the cost of a breach can be easily shifted to the victim, or laziness or ignorance on the part of system designers, engineering managers, developers, and marketers, to say nothing of clueless senior managers. But none of this matters. We can avoid a lot of drama and heartache with just a tiny bit of out-of-the-box thinking.
Case in point: credit card theft. The recent (hey, let's call it what it is - ongoing) rash of embarrassing security breaches got me to thinking - how come we haven't solved this problem in particular? And, especially, why are the repercussions of a failure on the part of providers ultimately a problem only for the customer? It's nothing for credit-card companies to ship out a new card, but potentially a huge hassle for us mere-mortal users. And identity theft isn't an issue for the provider, but it clearly is for us. They create the problem; we pay the price, and they don't care.
The solution that's on the horizon involves the use of "smart cards", with embedded chips, as is done in many parts of Europe and Asia. This, plus a PIN required for every transaction, as is also common in Europe, should reduce fraud enormously. After all, this is an instance of two-factor authentication, which is clearly better than the no-factor authentication in use today.
But why don't we simply get the retailer out of the loop? What business does any retailer have in obtaining someone's credit card number? This is clearly an artifact from the bad old days when a paper swipe of the card was retained out of necessity. Today's online world, however, eliminates this requirement.
So, instead, why not simply initiate the credit transaction, via a swipe, app, or whatever, with the credit-card issuer or their proxy, rather than the supplier of goods or services? The customer via this process (which includes some form of two-factor authentication and end-to-end encryption, of course) says it's OK to transfer funds to the supplier. All associated rights are preserved, records are kept, and the provider gets paid in much the same way as today. But they retain no credit-related information about the customer, other than that a transaction with a given customer took place on a given day. If they want to gather marketing-related info, and the customer gives permission for such, fine. But the breach of a server at Target or Neimann-Marcus won't cause any financial heartburn to the credit-card issuer or the customer. Nothing of value with respect to credit, anyway, can be stolen from the retailer, and it should be fairly easy to convert existing systems to work in this fashion.
Of course, the credit-card issuer/processor had better have their security act together. But the number of possible points of failure or compromise goes down dramatically with the process proposed above, and this approach could certainly serve as a bridge until the many years required to fully cut over to smart cards pass. And, gee, we may even find that smart cards - and perhaps even POS terminals and cards of any form - aren't really required at all, replaced by the customer's own smartphone and keys known only to the owner of the device.