NodeJS – Pomcor

A Demonstration of Two-Factor Cryptographic Authentication with a Familiar User Experience

I have just published a GitHub repository demonstrating a method of two-factor cryptographic authentication with a fusion credential, which provides the same user experience as traditional authentication with username and password, but with strong security. Developers with an Amazon AWS account can use a script provided in the repository to install the demo on an EC2 instance of their own. A live demo running on a Pomcor server is also available at demo.pomcor.com.

Security benefits of credential fusion

By analogy with biometric fusion, where two biometric modalities are combined in a manner that provides higher accuracy than if they were used separately, credential fusion combines authentication factors in a manner that provides stronger security than if they where used independently of each other.

In the demo, a password is fused with a cryptographic credential comprising a key pair extended with a secret salt. To authenticate, the frontend of the relying party (RP) hashes the user’s password with the secret salt, signs a challenge with the private key, and sends the public key, the signature, and the salted password to the backend. The backend verifies the signature with the public key, then computes a hash of the salted password with the public key, called the fusion hash, and verifies it against a registered version of that hash. The public key and the secret salt are deleted after authentication, and only the fusion hash is stored in the backend.

If the password and the extended key pair were used separately, the password would provide protection against device theft and the key pair would provide protection against a man-in-the-middle (MITM) phishing attack where the phishing site would relay messages between the legitimate site and the user’s browser and capture the session cookie after the user logs in. This would be prevented because the frontend of the phishing site would not have access to the private key, which is protected by the same origin policy of the web enforced by the browser. But the password would be still be vulnerable to phishing attacks, reuse at malicious sites, and backend breaches.

In the fusion credential, on the other hand, the password and the cryptographic credential protect each other as follows:

The password is protected against capture by a phishing site, because it is not sent in the clear.
The password is protected against reuse at malicious sites that use traditional authentication by username and password because the password is not sent in the clear, and at malicious sites that use a fusion credential as in the present authentication method, because different such sites would use different secret salts.
The password is protected against backend breaches because neither the password nor any value derived from the password that could be used in a dictionary attack are stored in the backend. In traditional authentication with username and password, by contrast, a salted password is stored in the password database, along with the salt itself. The salt prevents dictionary entries being tried against all salted passwords at once, but does not prevent dictionary entries being tried against the salted passwords one at a time. In the present authentication method the password is hashed with a salt, but like the private key, the salt is a secret that never leaves the user’s browser, and neither the salted password nor the salt are stored in the backend.
The key pair is protected against cryptanalytic and postquantum attacks, because the public key is not stored in the backend. In traditional cryptograhic authentication with a key pair, the public key is registered with the RP and stored in the backend database. An attacker who breaches the backend might be able to derive the private key from the public key, either by exploiting a weakness of the signature cryptosystem, or, in a perhaps not so distant future, by using a quantum computer. But in the present authentication method, only the fusion hash is stored in the backend.

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.

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.

Cryptographic Authentication Is Not That Easy After All

See also the cryptographic authentication page.

Updated as shown below.

At the last Internet Identity Workshop (IIW) we gave a demo of a sample web app that featured cryptographic authentication, and argued that implementing cryptographic authentication is easy. Later, in the blog post Easy, Password-Free, Cryptographic Authentication for Web Applications I discussed the code of the sample web app and said that cryptographic authentication provides a “simple alternative” to authentication with a password. The issues discussed in the post, however, were not simple! Since then we have had to revise the code of the demo several times to fix bugs and, in the process, we have come to realize that cryptographic authentication is not that easy after all. It does not take much code, but it requires a lot of attention to detail to avoid a variety of pitfalls.

In this post I recapitulate the pitfalls that we have encountered (some of which were already discussed in the earlier post) and explain how we avoid them in the latest version of the demo code.

Easy, Password-Free, Cryptographic Authentication for Web Applications

See also the cryptographic authentication page.

Update. The demo code mentioned below has been updated to fix bugs. If you find any additional bugs please report them through the contact form ~~or by posting to the PJCL forum~~. (The PJCL user forum has been discontinued as of May 27, 2018.) The date of the latest update will be shown in the PJCL page. Please see also the blog post Cryptographic Authentication Is Not That Easy After All.

For years there has been consensus that passwords have to go. To the many reasons for not using password authentication, the European GDPR will add, when it goes into effect on May 25, stringent requirements to notify users and regulators when passwords are compromised, backed by substantial fines. And yet, passwords are still the dominant authentication technology for web applications. This is because the alternatives that have been proposed and tried so far are complicated and expensive to implement. But there is a simple alternative that you can implement yourself, if you are a web application developer: cryptographic authentication with a digital-signature key pair stored in the browser.

At last week’s Internet Identity Workshop (IIW) we showed how easy it is to implement this alternative. We gave a demo of a sample web application, exercising the user interface and looking at the code. The sample application was implemented in Node.js and used the Pomcor JavaScript cryptographic library (PJCL) on the client and server sides. The code of the sample application, which we will refer to as the demo code, can be found in the PJCL page of the Pomcor site (subsequently modified as explained below to accommodate Internet Explorer).

PJCL Can Now Be Used in Node.js Server-Side Code Exactly as in the Browser

We have just released Revision 1 of Version 0.9.1 of the Pomcor JavaScript Cryptographic library (PJCL), which changes the way in which library functions are defined, making it easier to use PJCL in Node.js. In this post I describe the change and explain why it is important for full stack web application development.