Authentication – Page 2

Identity in a Zero Trust Architecture

In the previous post I said I was happy that the new CFO of Pomcor, Ken Cone, has experience with government contracting, as his experience may help us apply for and manage government funding for our reasearch on identity and authentication protocols. Identity is an essential element of cybersecurity, and Executive Order 14028 has recognized that cybersecurity is an essential element of national and economic security.

Here I want to add that identity is essential, more specifically, in modern “zero trust” cybersecurity architectures whose importance is recognized by the Federal Government. The White House has stated in the OMB memorandum M-22-09 that a zero trust approach to security is needed today to provide a “defensible architecture” in the current threat environment. The Department of Defense (DoD) has published a Zero Trust Reference Architecture, and M-22-09 directs Federal Agencies to move towards zero trust cybersecurity principles.

This has implications for identity. As stated in the Reference Architecture and cited in M-22-09, “The foundational tenet of the Zero Trust Model is that no actor, system, network, or service operating outside or within the security perimeter is trusted. Instead, we must verify anything and everything attempting to establish access.” This means that secure identification is an essential requirement of zero trust architecture.

To meet this requirement, M-22-09 calls for multi-factor authentication (MFA); not the usual MFA, however, but rather what the memorandum calls “phishing-resistant MFA”, where phishing resistance is achieved by using a secret that is not shared with the relying party. That means a private key.

Thus the memorandum is calling for cryptographic authentication, which is what Pomcor has been working on for years, and is working on right now. I look forward to Pomcor contributing to the transition towards zero trust in the Federal Government and to the adoption by the Government and the Private Sector of cryptographic authentication methods that provide strong security.

Pomcor Granted Patent on Frictionless Cardholder Authentication

This post has been updated to include the patent number.

Pomcor has been granted US patent 10,825,025 on the method of cardholder authentication that I have discussed before on this blog. The Cardholder Authentication page has links to earlier materials. Actually, the patent was granted on November 3, 2020, but I was busy working on TLS traffic visibility at the time.

3-D Secure 2 purports to reduce the friction created by 3-D Secure 1 as it redirects the cardholder browser to the card issuer’s site for authentication. But it does so by omitting cardholder authentication altogether for transactions deemed low risk, and may increase friction for other transactions.

Eliminating friction with a Service Worker

We eliminate friction instead, for all transactions, by using a Service Worker registered with the browser by the issuer to intercept the redirected request and authenticate the user by proof of possession of a private key, which is used to sign a description of the transaction and thus provide a defense against transaction repudiation to the merchant.

The private key is associated with a credit card certificate that contains the corresponding public key and a cryptographic hash of the data printed on the credit card. The card data is not included in the certificate to avoid exposing it to an attacker who uses malware or physical capture of the cardholder’s device to obtain the certificate. When the merchant’s site or native app receives the certificate along with signature, it verifies the hash against the printed card data entered by the cardholder.

We originally used the idea of intercepting an authentication request with a Service Worker in connection with Rich Credentials, then presented it in general terms at ICMC 2017.

Are Service Workers still usable?

People have been telling us recently that Service Workers can no longer be used because WebKit deletes Service Worker registrations, along with first-party data stored in the browser, after seven days of non-use. This is an unfortunate complication, but it does not mean that Service Workers and first-party data can no longer be used. It just means that the web app that registers the Service Worker, in this case the issuer’s web app, must be added to the home screen, as explained in this WebKit blog post.

Airport Security in the Age of COVID-19

As the travel restrictions imposed to control the coronavirus pandemic are beginning to be relaxed in some parts of the world, it is time to start rethinking airport security in the age of COVID-19. Even if an effective vaccine is found for COVID-19, it will be out of the question to go back to long lines at security checkpoints and boarding gates, and the manual checking of identity documents and boarding passes.

In a provisional patent application that I coauthored with Karen Lewison before the pandemic and have now published, we proposed an automated method of verifying the identity of travelers that could be used in the post-pandemic world to speed up the security check and the boarding process, and to eliminate the face-to-face interaction with a security officer at the checkpoint and a flight attendant at the boarding gate. The method takes advantage of the high accuracy achieved by today’s deep neural networks for face recognition, while overcoming the privacy concerns raised by the collection and storage of facial images.

Here is a summary of the method.

Identity Verification: A Coronavirus Challenge to the Financial World

Updated April 1st, 2020

This blog post has been coauthored with Karen Lewison

The coronavirus pandemic is causing unprecedented disruption throughout the business world. Businesses that are not able to cope with public health orders and new customer behaviors are going out of business, while businesses that are able to adapt are thriving and expanding their market share. Disruption will be temporary in sectors of the economy where face-to-face interaction adds value to the business-to-customer relationship and a physical presence on the street is an essential requirement of the business model; gyms, bars and conference centers will no doubt reopen once the pandemic has been controlled. But changes brought by the pandemic will be permanent in sectors of the economy where face-to-face interaction adds no value and a physical presence is a legacy of a traditional business model. One of those sectors is the financial world.

A challenge to financial institutions

Financial institutions have been less impacted than other businesses by the pandemic. In the US, the entire financial sector has been declared critical infrastructure by DHS and is thus protected against closure orders by states or counties. And most financial transactions are now conducted online using web browsers or mobile apps, without face-to-face interactions that would put employees and customers at risk of contagion. Nevertheless, coronavirus poses a challenge to financial institutions: how to verify the identity of new customers.

Pomcor Granted Patent on Rich Credentials

Pomcor has been granted US Patent 10,567,377, Multifactor Privacy-Enhanced Remote Identification Using a Rich Credential. Karen Lewison is the lead inventor and I am a coinventor. Pomcor has so far been granted a total of eight patents, two of which we have sold. The remaining six patents that we own are listed in the Patents page of this web site.

This latest patent is special because it provides a solution to a major societal problem: how to identify people over the Internet with strong security. Techniques are available for authenticating repeat visitors to a web site or current users of a web application. But authentication techniques are only applicable once a relationship has been established. They are not applicable when somebody wants to establish a new relationship, e.g. by becoming a new customer of a bank, or signing up with a robo advisor, or applying for a mortgage, or renting an apartment, or switching to a different car insurance.

A New Tool Against the Surge of Application Fraud

This blog post has been coauthored with Karen Lewison

In recent posts we have been concerned with online credit card fraud and how to fight it using cardholder authentication. In this post we are concerned with another kind of financial fraud, known as application fraud or new account fraud. Both kinds of fraud have been rising after the introduction of chip cards, for reasons mentioned by Elizabeth Lasher in her article The Surge of Application Fraud:

“Due to the high volume of data breaches, Social Security numbers, mailing addresses, passwords, health history, even the name of our first pet is all for sale on the Dark Web. When you combine this phenomenon with the economic pressure applied on fraudsters to find a new cash cow after chip and signature plugged a gap in card-present fraud in the US, there is a perfect storm.”

The term “application fraud” refers to the creation of a financial account, such as a bank account or a mortgage account, with the intention to commit fraud. Application fraud can be first-party fraud, where the account is opened under the fraudster’s own identity, or third-party fraud, where the fraudster uses a stolen identity. Here we are primarily concerned with the latter.

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.