Blog – Page 5

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.

Pomcor Granted Patent on Multifactor Cryptographic Authentication

Pomcor has recently been granted US Patent 9,887,989 on a multifactor cryptographic authentication technique that uses a cryptographic key pair in conjunction with a password and/or a biometric key while protecting the password and biometric data against back-end security breaches. All our patents are available for licensing.

At the last Internet Identity Workshop we demonstrated single factor cryptographic authentication, not covered by the patent, where a key pair stored in browser local storage is used instead of a password for authentication to a web application. (A proof-of-concept implementation of a simple web app is available in the PJCL web page and described in the previous post.) Cryptographic authentication has huge advantages over password authentication, as passwords are vulnerable to back-end database breaches, phishing attacks, and password reuse at malicious or insecure sites. But when used in multifactor authentication, a password provides the unique benefit of being something that the user knows, independent of something that the user has (a device that contains a private key or is able to generate or receive one-time codes) and something that the user is (a biometric feature). Our latest patent discloses a novel multifactor authentication technique where a password can provide this benefit while being immune to the vulnerabilities of conventionally used passwords.

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.

Second Release of PJCL Expands Functionality Following NIST Cryptographic Specifications

Today we have released version 0.9.1 of the Pomcor JavaScript Crytpographic Library (PJCL). The initial public release provided digital signature functionality, which we had been using internally for our own research on authentication and identity proofing. This release adds key agreement and key derivation functionality. The next release will provide symmetric and asymmetric encryption primitives, including AES and RSA. To be notified of future releases you may ~~sign up for the user forum~~, subscribe to the feed of this blog, or follow me on Twitter (@fcorella). (Update: The PJCL user forum has been discontinued as of May 27, 2018.)

PJCL can be used in any JavaScript environment, both client-side (e.g. in a browser) and server-side (e.g. under Node.js). It comes with extensive documentation on the functionality that it provides, which includes: