Recommendations on Retail Payment System Security

According to the Nilson Report, Global Credit card and debit card fraud resulted in losses amounting to $21.84 billion during 2015.  Losses have increased every year since 2002.  While the majority of these losses are charged to the card issuers, the cost is passed along to the consumer in the form of interest charges and fees.  (See sources and other statistics at WalletHub.)

Moreover, we have seen the growth of an illegal industry attacking and stealing personally identifiable information, and monetizing that information using credit and debit card account numbers, ATMs, and e-commerce.  In the market place of this industry it is possible to buy active primary account numbers and authenticating data.  The size and complexity of this industry makes it all but impossible to estimate its cost to the legitimate economy.  

Given the number of enterprises collecting, communicating, and retaining this data, some leakage is inevitable.  However, it is the ability to monetize the data that supports the illegal trade and which motivates many of the active attacks.  While we have seen some arrests and convictions in the illegal industry, many of these attacks and the fraudulent use of the data are going unpunished.  

It is the author's assertion that one means of reducing this illegal trade is to reduce the storage and use of primary credit and debit card account numbers.  Specifically we propose the elimination of the primary account numbers on the face of the card, the magnetic stripe, in the transaction, and in storage on merchant sites; all of these uses to be replaced by physical and digital tokens.  In most cases, the Payment Authorization Number (PAN) should be a digital token rather than the primary account number.  We assert that the financial  technology and payment card industries already know how to do this, that there are demonstration projects ongoing, and that much of the necessary infrastructure to do this is already in place.  

The new Apple credit card is an example of a physical token that hides the primary account number.  Contactless EMV cards and mobile wallets are examples of digital tokens at transaction time.  While the current practice is to put the primary account number in the clear, both in text on the face of the card and on a magnetic stripe, this is for purposes of backwards compatibility, is archaic and unnecessary, and, in the light of the problem outlined above, should be eliminated.  

Some merchants have already replaced the primary credit card account number in their customer record with a digital token.  While this may add a little cost it reduces the risk of attacks against their systems and that the account number can be compromised in a breach.  

PayPal, Masterpass, AmEx Express Pay, Apple Pay, and Visa Checkout are all examples of services for authorizing e-commerce payments without the use of the credit or debit card account numbers.  These systems not only guarantee the merchant payment but transfer the cost and risk of authenticating the customer name and address to the service provider.  While the services may marginally increase the transaction cost to the merchant, this is more than offset by the reduction of risk.  These services also reduce the risk to the consumer of the leakage and fraudulent use of his account numbers.  

We recommend the following:

• The elimination of the magnetic stripe from all newly issued credit or debit cards
• The use of one-time Payment Authorization Numbers  (PANs) throughout the payment system
• The replacement of primary account numbers with one-time payment authorization numbers in e-commerce
• The replacement of primary account numbers with digital tokens in merchant systems storage
• The replacement of mag-stripe and PIN at ATMs with EMV
• Preference for digital wallets at point-of-sale and ATMs
• The elimination of the primary account number in text on the face of cards
• Prefer EMV cards with biometrics for convenience and security

These recommendations are intended to address the systematic problems in the retail payment system.  They are independent of one another and each can be implemented, in whole or in part, by itself.   However, they do compliment one another and collectively are necessary to the greatest effectiveness.  The first is the most important and the only one for which there are no trials or demonstrations.  Every little bit will help.

We recognize that implementation of these recommendations will take time but it is urgent and should be done within 3-5 years.  While we believe that these recommendations are self-justifying, we recommend that mechanisms like the Payment Card Industry Data Security Standards and California and New York legislation be used to add motivation as necessary

The Budget Fairy

It is a persistent plaint of the security managers that they do not have sufficient budget to do what they think should be done.  One wonders where they think budget comes from.  There is no budget fairy that comes down and confers budget on good little boys and girls. Those managers who have budget all got it the same way; they asked for it.  

Security managers are peculiarly loath to ask for budget for fear they will be told no. (A "no" in the record might look bad but it is an implicit acceptance of any risk that the proposal was intended to reduce.  It should be in the record.) Those who ask for budget get told no a lot. Those who have budget did not take no for an answer. They re-did their proposal or their justification and asked again.  And again.  As many times as necessary to get to yes.

Note that almost anyone in the hierarchy can say no.  Those who have budget, find the executive or manager who can also say yes.  They never accept no for an answer until they are sure that they have proposed to someone who can say yes if she wants to.  Note that while we may sometimes get budget from senior staff, it is usually the line of business executives who control most of the resources and incur losses.  (Senior line of business executives often have "budget" or "plans and controls" staff, who manage budget, understand the process, and know how much discretion the executive has.  These staff can be very helpful.)

Those who have budget are the same managers who are being promoted.  General management likes few things better than managers who will tell them how to spend money profitably.

Security initiatives are usually justified either by a reduction, at least over time, in the cost of security or the cost of losses.  These reductions have the advantage that they fall through to the bottom line as profit.  It is useful to budget for "losses;" while they occur irregularly, they do occur.  At least at the level of the enterprise or business unit, they can be estimated; all budgets are estimates but get more accurate with experience.  Increases in the budget for initiatives can be justified in part by a reduction in the budget for losses.  

Managers often see budget as a restriction on their ability to spend.  Rather they should see it as permission.  

Limitations of Biometrics

It is Blackhat/Defcon time so it should not surprise anyone that the media is full of hacks. While the hackers pretend to demonstrate that the security mechanism is useless, most of the attacks are so expensive as to be impractical.  What they really demonstrate is the limitations of the mechanism.  Regular readers of this blog know that all security mechanisms have limitations; understanding those limitations are part of our stock in trade and I write about them often.   

A recent demonstration spoofed Apple's FaceID in only "120 seconds," as though that were the only cost of attack.  They omitted the special knowledge and access.  A recent article in BankInfoSecurityNews raised alarms over the discovery of a database of fingerprint images for sale.  

First, keep in mind that biometrics are really about convenience, not security. That is why they are best used as one factor in multi-factor systems. 

Second, they do not rely upon the secrecy of the reference but upon their resistance, at least in context, to counterfeiting. Your visage is an authenticator for your drivers license. It is public information. While a photograph of you might be able to fool a computer, no other person would be likely to confuse the photo with you.  There is too little information in the photo for it to be mistaken for you.  The more information that the implementation uses, the lower the risk of false positives but the higher that of false negatives and the more power and time required for a check.  

Finally, as this article suggests, just like passwords, biometrics are fundamentally vulnerable to spoofing and replay attacks; implementations must resist them. For example, Apple's FaceID uses tests of "liveness" to distinguish between a real person and a photo of the person or a replay of an earlier submission.  Perhaps they are better used on mobiles, where possesion of the mobile is one factor and where the instant data is compared to the reference locally and does not go across a network where it could be captured for replay.