Authentication – Page 3

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.

3-D Secure 2 May Allow the Merchant to Impersonate the Cardholder

3-D Secure is a protocol that provides security for online credit card payments by redirecting the cardholder's browser to the web site of the bank that has issued the credit card, where the cardholder is authenticated by methods such as username-and-password or a one-time password. 3-D Secure is rarely used in the US because the cardholder authentication creates friction that may cause transaction abandonment, but it is used more frequently in other countries. The credit card networks have been working on a new version of the protocol, called 3-S Secure 2, where the issuing bank assesses fraud risk based on information received from the merchant through a back channel and waives authentication for low-risk transactions.

In a paper presented at HCII 2019 we showed that 3-D Secure 2 has serious privacy and usability issues and we proposed an alternative protocol that provides strong security without friction for all transactions by cryptographically authenticating the cardholder. We have now looked in more detail at a particular configuration of 3-D Secure 2 where the cardholder uses a native app instead of a browser to access the merchant's site, and we have found security flaws, described in detail in a technical report, that may allow a malicious merchant to impersonate the cardholder.

Online Cardholder Authentication without Accessing the Card Issuer’s Site

One of the saddest failings of Internet technology is the lack of security for online credit card transactions. In in-store transactions, the cardholder authenticates by presenting the card, and card counterfeiting has been made much more difficult by the addition of a chip to the card. But in online transactions, the cardholder is still authenticated by his or her knowledge of credit card and cardholder data, a weak secret known by many.

Credit card networks have been trying to provide security for online transactions for a long time. In the nineties they proposed a complicated cryptographic protocol called SET (Secure Electronic Transactions) that was never deployed. Then they came up with a simpler protocol called 3-D Secure, where the merchant redirects the cardholder' browser to the issuing bank, which asks the cardholder to authenticate with a password. 3-D Secure is rarely used in the US and unevenly used in other countries, due to the friction that it causes and the risk of transaction abandonment; lately some issuers have been asking for a second authentication factor, adding more friction. Now the networks have come up with version 2 of 3-D Secure, which removes friction for low risk transactions by introducing a “frictionless flow”. But the frictionless flow does not authenticate the cardholder. Instead, the merchant sends device and cardholder data to the issuer through a back channel, potentially violating the cardholder's privacy.

Last August we wrote a blog post and a paper proposing a scheme for authenticating the cardholder without friction using a cryptographic payment credential consisting of a public key certificate and the associated private key. We have recently written a revised version of the paper with major improvements to the scheme. The paper will be presented next month at HCII 2019 in Orlando.

Pomcor Contributes Biometrics Chapter to HCI and Cybersecurity Handbook

Karen Lewison and I have contributed the chapter on Biometrics to the book Human-Computer Interaction and Cybersecurity Handbook, published by Taylor & Francis in the CRC Press series on Human Factors and Ergonomics. The editor of the paper, Abbas Moallem, has received the SJSU 2018 Author and Artist Award for the book.

Biometrics is a very complex topic because there are many biometric modalities, and different modalities use different technologies that require different scientific backgrounds for in-depth understanding. The chapter focuses on biometric verfication and packs a lot of knowledge in only 20 pages, which it organizes by identifying general concepts, matching paradigms and security architectures before diving into the details of fingerprint, iris, face and speaker verification, briefly surveying other modalities, and discussing several methods of combining modalities in biometric fusion. It emphasizes presentation attacks and mitigation methods that can be used in what will always be an arms race between impersonators and verifiers, and discusses the security and privacy implications of biometric technologies.

Feedback or questions about the chapter would be very welcome as comments on this post.

Frictionless Secure Web Payments without Giving up on Cardholder Authentication

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.

Random Bit Generation with Full Entropy and Configurable Prediction Resistance in a Node.js Application

This is the fourth and last post of a series describing a proof-of-concept web app that implements cryptographic authentication using Node.js with a MongoDB back-end. Part 1 described the login process. Part 2 described the registration process. Part 3 described login session maintenance. The proof-of-concept app, called app-mongodb.js, or simply app-mongodb, can be found in a zip file downloadable from the cryptographic authentication page.

In app-mongodb, random bits are used on the server side for generating registration and login challenges to be signed by the browser, and for generating login session IDs. On the client side, they are used for generating key pairs and computing randomized signatures on server challenges.

In quest of full entropy

There are established methods for obtaining random bits to be used in web apps. On the client side, random bits can be obtained from crypto.getRandomValues, which is part of the W3C Web Crypto API. On the server side, /dev/urandom can be used in Linux, MacOS and most flavors of Unix. However, neither of these methods guarantees full entropy.

Login Session Maintenance in Node.js using Express and Handlebars

This is part 3 of a series of posts describing a proof-of-concept web app that implements cryptographic authentication using Node.js with a MongoDB back-end. Part 1 described the login process. Part 2 described the registration process. This Part 3 is concerned with login session maintenance in a broader scope than cryptographic authentication. Part 4, concerned with random bit generation, is now available. The proof-of-concept app, called app-mongodb.js, can be found in a zip file downloadable from the cryptographic authentication page.

Update. The name of the constant securityStrength has been changed to rbgSecurityStrength as noted in the last post of the series and reflected in one of the snippets below.

At first glance it may seem that there is no need for login session maintenance in a web app that implements cryptographic authentication with a key pair. Every HTTP request can be authenticated on its own without linking it to a session, by sending the public key to the back-end and proving possession of the private key, as in the login process described in Part 1. That login process relied on the user supplying the username in order to locate the user record, but this is not essential, since the user record could be located in the database by searching for the public key, which is unique with overwhelming probability.

But login sessions provide important login/logout functionality, allowing the user to choose whether to authenticate or not. A member of a site accessible to both members and non-members, for example, may choose to visit the site without authenticating in order to see what information is made available by the site to non-members. Also, the proof of possession of the private key has a latency cost for the user due to the need to retrieve the challenge from the server, and a computational cost for the server and the browser. These costs are insignificant if incurred once per session, but may not be insignificant if incurred for every HTTP request.

The app discussed in this series, app-mongodb.js, implements login sessions in the traditional way using session cookies. Having said that I could stop here. But the Express framework used in the app provides interesting ways of implementing traditional login sessions, which are worth discussing.

Credential Registration for Cryptographic Authentication with Node.js and MongoDB

This is part 2 of a series of posts describing a proof-of-concept web app that implements cryptographic authentication using Node.js, Express, Handlebars, MongoDB and Mongoose. All parts are now available. Part 1 describes the login process. This Part 2 describes the registration process. Part 3 describes login session maintenance. Part 4 is concerned with random bit generation.

Update. The name of the constant securityStrength has been changed to rbgSecurityStrength as noted in the last post of the series and reflected in the snippets below.

Part 1 of this series described the login process of a proof-of-concept Node.js application that implements cryptographic authentication using a MongoDB database back-end. The app, called app-mongodb.js, can be found in a zip file downloadable from the cryptographic authentication page, where it is bundled together with a simpler app that has the same functionality and the same front-end but emulates the database using JavaScript objects, provided for comparison.

This post describes the registration process of app-mongodb.js. The app has a registration page reachable from a link found under a top-of-page login form in the public pages of the app. The registration page has a form where the user enters a username, a first name and a last name, but no password. The first and last names are representative of any info that the user may be asked to provide in a full-fledged application.

The registration process of app-mongodb.js has a structure similar to that of the login process described in Part 1. The browser sends an HTTP POST request to the /register-username endpoint of the server, conveying the username, first name and last name. The server creates a user record, called a “user document” in MongoDB terminology, and responds with a JavaScript POST redirection. The JavaScript POST redirection consists of downloading a script that generates a key pair, signs a server challenge with the private key, and sends the public key and the signature to the /register-public-key endpoint in a second HTTP POST request. The server cryptographically validates the public key, verifies the signature, and adds the public key to the user document.

The following code snippet shows how the server processes the first HTTP POST request, received at the /register-username endpoint.

Cryptographic authentication with Node.js and MongoDB

This is part 1 of a series of posts describing a proof-of-concept web app that implements cryptographic authentication using Node.js, Express, Handlebars, MongoDB and Mongoose. All parts are now available. Part 2 describes the registration process. Part 3 describes login session maintenance. Part 4 is concerned with random bit generation.

Update. The name of the constant securityStrength has been changed to rbgSecurityStrength as noted in the last post of the series and reflected the snippets below.

The PJCL library allows full-stack web developers to use the same cryptographic API on a browser front-end and a Node.js back-end, as explained here. At the last IIW we demoed a web app, implemented using Node.js and Express, that featured cryptographic authentication with a DSA key pair, using PJCL both in the browser to sign a challenge and in the Node.js server to verify the signature. Initial implementations of the app were complicated by having to work around a Firefox bug, which we reported and was confirmed. But eventually we found a simple way of bypassing that bug.

The IIW demo app was very simple. It only had a public “home page” and a private “welcome page”, and it emulated the back-end database using JavaScript objects. We are now releasing a more substantial proof of concept of cryptographic authentication that again uses Node.js and Express, but this time uses a MongoDB database, accessed via a Mongoose driver. Besides using an actual rather than emulated database, the new proof-of-concept app includes features such as on-the-fly login and garbage collection of incomplete user registrations. It also shows how to implement random bit generation with full initial entropy and configurable prediction resistance, which I plan to discuss in another blog post of this series.

The new app is available in a new cryptographic authentication page of the Pomcor site. It is bundled together in a zip file with a simpler app that has the same functionality and the same front-end, but emulates the database using JavaScript objects. The two apps, called app-mongodb.js and app-nodb.js, share the same static files and views. Comparing the two apps may help with understanding the code of the more complex app-mongodb.js. The apps may be run in any Node.js server with access to a MongoDB database and a /dev/random device file, as explained in a README file included in the zip archive.

A Bypass of the Firefox POST Redirection Bug

I'm happy to report that we have found a way of bypassing the Firefox POST redirection bug discussed in the previous post, obviating the need for code changes to cope with the redirection replay by Firefox when the user clicks the back button. While waiting for the bug to be fixed, this will simplify the implementation of web apps that rely on POST redirection, including apps that use cryptographic authencation or federated login. We have revised again the sample web app demoed at the last IIW, this time to simplify it by taking advantage of the bug bypass.