Will Cardholder Authentication Ever Come to the US?

This blog post has been coauthored with Karen Lewison

You may have heard that the EU is struggling to implement the Strong Customer Authentication (SCA) requirements of Payment Services Directive 2 (PSD2). The directive was issued four years ago, Regulatory Technical Standards (RTS) followed two years later, and the SCA requirements went into effect on September 14. But on October 16 the European Banking Authority (EBA) had to postpone enforcement until December 31, 2020, due to pushback from the National Competent Authorities (NCAs) of the EU member countries. In an opinion announcing the postponement, the EBA cited as a reason for the pushback the fact that 3-D Secure 2 (3DS2) is not ready.

The problems that the EBA is having with the SCA requirements have more to do with the bureaucratic formulation of the requirements in PSD2, than with the technical difficulty of providing strong security. We will discuss this in another post, but first we want to ask here whether cardholder authentication will ever come to the US.

Cardholder authentication is used in Europe, but rarely in the US

Strong cardholder authentication has been used in Europe for many years, without waiting for PSD2. It is implemented using the original version of 3-D Secure (3DS1) introduced by Visa in 1999 and adopted by other card networks, rather than the new version that EMVCo is struggling to specify. 3DS1 is used to different extents in different European countries but it is rarely used in the US.

The reason for this disparity is clear. Authentication is burdensome. Consumers in the US have practically no liability for unauthorized use of a credit card, so they have no motivation to authenticate. Given a choice between making a purchase from a merchant who requires authentication and a merchant who does not, they will choose the merchant who does not; and when asked to authenticate, they may abandon the transaction instead. European consumers, on the other hand, have historically had substantial, sometimes unlimited liability for unauthorized purchases. Liability was capped to 120 euros by the first Payment Services Directive in 2007, then to 50 euros by PSD2 when it went into effect on September 14, which is still non-negligible. For the sake of security, European consumers may prefer a merchant who requires authentication, in spite of the burden of providing it.

The absence of cardholder authentication in the US makes online shopping convenient for consumers, but it also makes online credit card fraud easy for criminals. The introduction of chip cards reduced the fraud rate for in-store transactions by making it practically infeasible to clone cards; but fraudsters shifted their efforts to the web and the fraud rate for online transactions increased.

Reducing the online fraud rate will require cardholder authentication. But in the US, cardholder authentication can only succeed if it does not create friction that may cause transaction abandonment and customer loss. One of the goals of the new version of 3-D Secure is to reduce friction. But 3DS2 is unlikely to ever be implemented.

3-D Secure 2 may never be ready

The credit card networks have been touting 3-D Secure 2 as the means of implementing PSD2 in Europe and providing frictionless cardholder authentication in the US. But the 3DS2 specification has been under development for many years and it is far from ready, as shown by the postponement of SCA enforcement. A look at the specification shows not only that it is not ready, but also that it may never be ready.

We looked at the specification when we wrote a paper on frictionless cardholder authentication that we presented at HCI International 2019 and was published in the Late Breaking Papers proceedings of the conference (Springer LNCS 11786). The authors’ version of the paper is available on this site. We found the following shortcomings, discussed in more detail in the paper:

  • The cardholder is only authenticated for some transactions, friction is not reduced for those transactions, and latency is added to all transactions.
  • The merchant is required to send cardholder information to the issuing bank through a back channel, potentially violating the cardholder’s privacy.
  • Biometric authentication has extremely poor usability, requiring the cardholder to read and understand instructions, and to manually find and open a bank app.
  • 3DS2 requires a costly infrastructure, including three additional servers besides those used to implement the merchant and bank sites.

Later we had a second look at the specification, focusing on a particular configuration of 3DS2 where the cardholder uses a merchant app to shop at the merchant’s site. This time we found fundamental security flaws that enable attacks by a malicious merchant (or by malicious personnel working for the merchant); variations on some of those attacks can also be carried out by a malicious developer of merchant apps, or by a hacker with remote write access to the code of the merchant app before it has been signed.

The following attacks are discussed in more detail in a technical report:

  • A malicious merchant can capture answers to security questions and use them to impersonate the cardholder.
  • A malicious merchant can capture one-time passwords and use them to impersonate the cardholder.
  • A malicious merchant can add itself to a whitelist of merchants trusted by the cardholder.

The flaws that enable these attacks are not minor flaws that can be fixed by minor changes; fixing them would require a different approach to cardholder authentication in the merchant-app configuration.

The same technical report also identifies and discusses in detail several fundamental security misconceptions about mobile technology that seem to underlie the security flaws.

The fundamental nature of the security flaws and misconceptions suggests that EMVCo may never be able to put the 3DS2 specification on a sound security footing. Even if it could, the end result would have privacy, usability and cost drawbacks that might preclude adoption by banks and merchants.

But frictionless cardholder authentication is possible by other means

The flaws and shortcomings of 3DS2 do not mean that it is not possible to provide frictionless cardholder authentication for all transactions with good usability, minimal cost, and no privacy violations. We describe a cardholder authentication solution that does that in the HCII paper.

In a nutshell, the merchant’s site redirects the cardholder browser to a URL in the issuing bank’s DNS domain, but the redirected request is intercepted by a service worker registered with the browser by issuing bank, and handled within the browser without network access. The service worker asks the cardholder to confirm the transaction and signs the transaction with a private key associated with a certificate that binds the associated public key to a cryptographic hash of the credit card data. The certificate contains a hash of the data rather than the data itself to avoid storing the data in the cardholder’s computing device that carries the credential. The user experience (UX) for the cardholder is the same as in an ordinary credit card payment on a web site, except that the confirmation page is a bank page constructed by the service worker. More details can be found in the paper.

The solution supports the use of a bank app and/or a merchant app. If there is a bank app in the cardholder’s device, the service worker further redirects the browser to the app, which does the work of confirming and signing the transaction and may authenticate the cardholder biometrically. If the cardholder is using a merchant app rather than a browser, the merchant app asks the default browser to open a JavaScript URL that sends the request that is intercepted by the service worker.

Consortia of issuing banks could bring cardholder authentication to the US

The solution that we proposed in the HCII paper provides cardholder authentication without any friction that could impede adoption in the US. But can it be deployed given that the credit card networks seem committed to 3-D Secure 2? We think so, for the following reasons:

  1. The credit card networks were committed to the Secure Electronic Transactions (SET) protocol in the nineties, but they abandoned it after the specification process bogged down. The specification of 3DS2 is now bogged down.
  2. The credit card networks need not be concerned with cardholder authentication, a process that does not involve the acquiring bank and is separate and independent from the authorization and settlement processes managed by the networks, as made clear by the 3DS2 specification itself.
  3. There would be no need for the entire credit card industry to buy into a single authentication scheme. The proposed solution could be implemented by a consortium of issuing banks, or by several competing consortia. The use of such consortia would be transparent to the cardholder. A merchant could choose to support the use of zero, one, or more than one consortia, and would know whether to use a particular consortium for a particular transaction by looking up the IIN portion of the credit card number in a non-confidential but integrity-protected database provided by the consortium. The database would map the IIN to the URL to be intercepted by the service worker and to the public key to be used for verifying the bank’s signature on the credit card certificate.

As law enforcement has trouble keeping up with foreign crime syndicates and an ecosystem of fraud, frictionless cardholder authentication may be the only effective way of reducing the multibillion dollar tax that credit card fraud levies on society in the United States.

Leave a Reply

Your email address will not be published.