Authentication

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.

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

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

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).

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:

Pomcor Releases JavaScript Cryptographic and Big Integer Library

We have just released a beta version of a JavaScript cryptographic library usable in any JavaScript environment and based on very fast big integer arithmetic functionality that may be of interest in its own right.

The Pomcor JavaScript Cryptographic Library (PJCL) is available free of charge for any kind of use, but not under a traditional open source license. The traditional open source paradigm encourages contributions by the developer community at large, but we believe that this paradigm is not well suited to cryptography. To protect the integrity of the cryptographic code, the license prohibits modification of the cryptographic functions.

We have been using the library internally for our own research on authentication and identity proofing, and this first release includes symmetric and asymmetric digital signature functionality, including HMAC, DSA, and ECDSA with NIST curves. Future releases will provide broader cryptographic functionality, including encryption and key exchange. We believe that the library provides the only available JavaScript implementation of DSA, which is important to those wary of the opportunities for hiding backdoors that might be provided by elliptic curve technology.

The underlying big integer functionality includes Karatsuba multiplication. Continue reading “Pomcor Releases JavaScript Cryptographic and Big Integer Library”

Storing Cryptographic Keys in Persistent Browser Storage

This blog post is a companion to a presentation made at the 2017 International Cryptographic Module Conference and refers to the presentation slides, revised after the conference. Karen Lewison is a co-author of the presentation and of this blog post.

Slide 2: Key storage in web clients

Most Web applications today use TLS, thus relying on cryptography to provide a secure channel between client and server, and to authenticate the server to the client by means of a cryptographic credential, consisting of a TLS server certificate and its associated private key. But other uses of cryptography by Web applications are still rare. Client authentication still relies primarily on traditional username-and-password, one-time passwords, proof of possession of a mobile phone, biometrics, or combinations of two or more of such authentication factors. Web payments still rely on a credit card number being considered a secret. Encrypted messaging is on the rise, but is not Web-based.

A major obstacle to broader use of cryptography by Web applications is the problem of where to store cryptographic keys on the client side. Continue reading “Storing Cryptographic Keys in Persistent Browser Storage”

Comments on the Recommended Use of Biometrics in the New Digital Identity Guidelines, NIST SP 800-63-3

NIST is working on the third revision of SP 800-63, which used to be called the Electronic Authentication Guideline and has now been renamed the Digital Identity Guidelines. An important change in the current draft of the third revision is a much expanded scope for biometrics. The following are comments by Pomcor on that aspect of the new guidelines, and more specifically on Section 5.2.3 of Part B, which we have sent to NIST in response to a call for public comments.

The draft is right in recommending the use of presentation attack detection (PAD). We think it should go farther and make PAD a mandatory requirement right away, without waiting for a future edition as stated in a note.

But the draft only considers PAD performed at the sensor. Continue reading “Comments on the Recommended Use of Biometrics in the New Digital Identity Guidelines, NIST SP 800-63-3”

Remote Identity Proofing Discussed at the Internet Identity Workshop

This is Part 3 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

To get community feedback on our remote identity proofing project we made a presentation two days ago at the 23rd Internet Identity Workshop in Mountain View. The slides can be found here. We were gratified that the feedback was positive and there were in-depth discussions with identity experts both during and after the presentation.

We started by explaining the goal of the project. Remote identity proofing has often relied on asking the subject multiple-choice “knowledge questions” (e.g. which of the following zip codes did you live in five years ago?). This method is terrible for privacy, since it relies on the identity proofing service gathering and using troves of personal information about people. Furthermore, due to the proliferation of personal data available online, it has now become ineffective. Continue reading “Remote Identity Proofing Discussed at the Internet Identity Workshop”

Implementing a PKI on a Blockchain

This is Part 2 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

In the previous post I described the concept of a rich credential, and how a rich credential issued by an identity source can allow a subject to identify him/herself remotely to a verifier with a key pair, a password, and one or more biometric samples such as facial image, even if there is no prior relationship between the subject and the verifier. That was Solution 1, the first of five solutions that we have identified as possible alternatives to knowledge-based verification in the course of our research project on remote identity proofing.

We have now published a paper on Solution 2. In Solution 1 the identity source was a DMV. In Solution 2 the identity source is a bank.