The 3-D Secure protocol version 1.0, marketed under different names by different payment networks (Verified by Visa, MasterCard SecureCode, American Express SafeKey, etc.) aims at reducing online credit card fraud by authenticating the cardholder. To that purpose, the merchant’s web site redirects the cardholder’s browser to the issuing bank, which typically authenticates the cardholder by asking for a static password and/or a one-time password delivered to a registered phone number. 3-D Secure was introduced by Visa in 1999, but it is still unevenly used in European countries and rarely used in the United States. One reason for the limited deployment of 3-D Secure is the friction caused by requiring users to remember and enter a password and/or retrieve and enter a one-time password. Consumers “hate” 3-D Secure 1.0, and merchants are wary of transaction abandonment. Another reason may be that it facilitates phishing attacks by asking for a password after redirection, as discussed here, here, and here.
3-D Secure 2.0 aims at reducing that friction. When 3-D Secure 2.0 is deployed, it will introduce a frictionless flow that will eliminate cardholder authentication friction for 95% of transactions deemed to be low risk. But it will do so by eliminating cardholder authentication altogether for those transactions. The merchant will send contextual information about the intended transaction to the issuer, including the cardholder’s payment history with the merchant. The issuer will use that information, plus its own information about the cardholder and the merchant, to assess the transaction’s risk, and will communicate the assessment to the merchant, who will redirect the browser to the issuer for high risk transactions but omit authentication for low risk ones.
This new version of 3-D Secure has serious drawbacks. It is privacy invasive for the cardholder. It puts the merchant in a bind, who has to keep customer information for the sake of 3D-Secure while minimizing and protecting such information to comply with privacy regulations. It is complex for the issuer, who has to set up an AI “self-learning” risk assessment system. It requires expensive infrastructure: the contextual information that the merchant sends to the issuer goes through no less than three intermediate servers—a 3DS Server, a Directory Server and an Access Control server. And it provides little or no security benefit for low risk transactions, as the cardholder is not authenticated and the 3-D Secure risk assessment that the issuer performs before the merchant submits the transaction to the payment network is redundant with the risk assessment that it performs later before authorizing or declining the submitted transaction forwarded by the payment network.
There is a better way. In a Pomcor technical report we propose a scheme for securing online credit card payments with two-factor authentication of the cardholder without adding friction.
The proposed scheme is based on the fact that cryptographic authentication, if done right, can provide security without friction. Ordinary credit card web payments require the cardholder to enter credit card data including the credit card number, expiration date, and security code, and cardholder data that may include, at the merchant’s discretion, the cardholder’s name, address, phone number, etc. This can be viewed as one-factor authentication, with a knowledge factor. The proposed scheme keeps this factor as-is, and adds as a second factor a requirement to prove possession of the private key component of a cryptographic payment credential.
The cryptographic payment credential consists of the private key and a short-term credit card certificate signed by the credit card issuer, which binds the associated public key to the credit card number. A significant security feature of the proposed scheme is that the private key is stored in the cardholder’s browser while the credit card certificate is kept by the issuer and supplied at transaction time. This makes it possible to use the credential on an ordinary browser without recourse to secure hardware and without exposing the credit card number to an attacker who gains physical possession of the machine that hosts the browser. The private key is stored in a browser database, from which it can be retrieved through the IndexedDB API using a key ID.
In the proposed scheme the cardholder enters credit card and cardholder data as usual in a checkout page hosted by the merchant. Then the cardholder is given the option to continue the checkout process as usual or continue the process with cardholder authentication. The cardholder is taken to a confirmation page hosted by the merchant after choosing the first option, or to a confirmation page hosted by the issuer after choosing the second. This is the only difference between the two options from the point of view of user experience.
The second option is implemented by a redirection from the merchant’s site to a cardholder authentication endpoint of the issuer’s site. The merchant finds the URL of the endpoint in a database of issuing banks that implement the scheme (the scheme database). Each issuer is identified in the database by its issuer identification number (IIN), which consists of the first six digits of the credit card number. (Eight digits will be used in the future.) The database maps the IIN of each issuer to the endpoint URL. It also maps the IIN to the public key associated with the private key that the issuer uses to sign credit card certificates.
Redirecting the cardholder to the issuer’s site is superficially similar to 3-D Secure 1.0, where the merchant redirects the cardholder’s browser to the issuer’s site for authentication with a static password and/or a one-time password. But in the proposed scheme the cardholder is not asked for a password after the redirection. All the cardholder has to do is review the description of the transaction shown in the issuer-hosted confirmation page and click on a button to submit payment, as he or she would do in a merchant-hosted confirmation page. Thus the redirection in the proposed scheme does not create friction, and does not facilitate phishing attacks by leading to a site that asks for sensitive information as 3-D Secure does.
When the cardholder clicks the payment submission button, a presubmission script in the confirmation page uses the key ID to retrieve the private key, then uses the private key to sign a description of the transaction. The browser sends the signature to the merchant together with the credit card certificate, which is not stored in the browser but was downloaded by the issuer to the browser within JavaScript code embedded in the confirmation page.
The merchant verifies the signature on the transaction using the public key in the credit card certificate, and the signature in the credit card certificate using the public key associated with the issuer’s IIN in the scheme database. The credit card certificate is not revocable because it has a short validity period, and because in case of compromise of the private key the credit card itself can be invalidated. If the two signature verifications succeed, the merchant saves the signature on the transaction to be used for dispute resolution, and proceeds to submit the transaction to the payment network as usual.
Whereas 3-D Secure 2.0 requires expensive infrastructure, the proposed scheme is inexpensive, requiring only the scheme database that maps the IIN of each issuer to the issuer’s public key and cardholder authentication URL.
See also: