Authentication – Page 2

Passwordless Authentication for the Consumer Space

This is part 1 of a series on cryptographic authentication. Part 2 and Part 3 are now available.

FIDO adoption lags in spite of general availability

In a white paper issued in March 2022 the FIDO Alliance candidly announced that FIDO-based authentication based on the FIDO2 standards, which include the Client-To-Authenticator Protocol of the FIDO Alliance and the companion Web Authentication API (WebAuthn) of the W3C “has not attained large-scale adoption in the consumer space”.

FIDO2 is a cryptographic authentication solution for the web, which uses a key pair managed by an authenticator and is advertised by the FIDO Alliance as being “passwordless”. The key pair may be stored in the authenticator, or, equivalently from a security viewpoint, it may be encrypted under a symmetric key stored in the authenticator, and exported to play the role of a “credential ID”. The authenticator may be a “roaming authenticator” carried in a “security key”, or a “platform authenticator” provided by the OS of the user's smartphone or laptop.

Early authenticators were security keys, which few web users had. Today most smartphones and laptops have platform authenticators, and that makes FIDO2 a generally available web technology. But the announcement by the FIDO Alliance shows that general availability has not translated into general adoption.

The white paper attributes this to challenges that consumers face with platform authenticators: “having to re-enroll each new device”, and having “no easy ways to recover from a lost or stolen device” as the credentials managed by the platform authenticator of the device are lost. To address the loss-of-credential problem, Apple, Google and Microsoft have announced a joint effort to devise solutions that are expected to become available “in the course of the coming year” and that, according to the white paper, will involve “multi-device credentials”.

Another contributing factor to the lack of adoption, however, is no doubt the complexity and cost of the FIDO2 authentication solution. Implementing the solution in a web app requires FIDO Server software provided by a company certified to provide such software by the FIDO Alliance. A team from the certified company must work with a team from the company that is developing the app to integrate the solution into the app. By contrast, an ordinary 2FA solution is implemented by the app developers themselves, possibly by a single developer, without any integration effort.

Thus FIDO faces two obstacles to widespread adoption: usability and cost.

Two working demonstrations of cryptographic authentication on GitHub

But cryptographic authentication need not be complicated, costly or challenging to the consumer. It can be implemented simply by storing a key pair in persistent browser storage (localStorage or IndexDB), registering the public key, and authenticating by proof of possession of the private key. I will refer to this as the browser storage solution to cryptographic authentication while referring to the use of a FIDO authenticator as the FIDO solution, or the authenticator storage solution, glossing over the fact that the private key may be exported under encryption rather than physically kept in the authenticator.

The browser storage solution can easily overcome the two obstacles that FIDO faces in the consumer space. To demonstrate this I have published on GitHub two demo web apps that implement passwordless, phishing-resistant cryptographic authentication with a key pair credential, without relying on an authenticator. In both of them the key pair is generated in the browser by the JavaScript frontend of the app, and kept in the localStorage facility provided by the Web Storage API. One of them uses a “nosql” (MongoDB) backend database to register the public key and store the user data, while the other uses an “sql” database for that purpose.

Pomcor Releases PJCL 1.0.0 on GitHub and npm and Deprecates the Beta Versions of the Pomcor JavaScript Cryptographic Library

In 2018 we published a series of beta versions of the Pomcor JavaScript Cryptographic Library (PJCL), which we called 0.9.0, 0.9.0r1, 0.9.1, 0.9.1r1 and 0.9.1r2. (We shall use semantic versioning to name future versions.) We then had to put the PJCL work on hold, but have now been able to resume development. We have refactored the library as an ES6 module and released version 1.0.0 on GitHub at https://github.com/fcorella/pjcl.git, and on npm.

While testing the refactored version 1.0.0 we found two bugs that we tracked back to version 0.9.1r2. Specifically, we found a bug in function pjclPBKDF2_SHA256 and a bug in function pjclFFCValidateG_256, which caused the JavaScript interpreter to throw exceptions. We fixed the bugs in a maintenance release 0.9.1r3, but we have now archived and deprecated the beta versions and will no longer be maintaining them.

If you want to stay informed about PJCL in the future, please subscribe to GitHub notifications about the pjcl repository.

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.