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
All parts are now available.
2 describes the registration process.
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
The IIW demo app was very simple. It only had a public “home
page” and a private “welcome page”, and it emulated
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
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
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.
Continue reading “Cryptographic authentication with Node.js and MongoDB”
I’m happy to report that we have found a way of bypassing
POST redirection bug discussed in
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.
Continue reading “A Bypass of the Firefox POST Redirection Bug”
See also the cryptographic
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
post) and explain how we avoid them in
the latest version of the demo
Continue reading “Cryptographic Authentication Is Not That Easy After All”
Pomcor has recently been granted
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
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
PJCL web page and described in the
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.
Continue reading “Pomcor Granted Patent on Multifactor Cryptographic Authentication”
See also the cryptographic
The demo code mentioned below has been updated to
If you find any additional bugs please report them
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
Please see also the blog post
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
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).
Continue reading “Easy, Password-Free, Cryptographic Authentication for Web Applications”
We have just released Revision 1 of Version 0.9.1 of the Pomcor
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
Continue reading “PJCL Can Now Be Used in Node.js Server-Side Code Exactly as in the Browser”
Crytpographic Library (PJCL).
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.)
and server-side (e.g. under Node.js). It comes with
on the functionality that it provides, which includes:
Continue reading “Second Release of PJCL Expands Functionality Following NIST Cryptographic Specifications”
environment and based on very fast big integer arithmetic functionality that may be of interest in
its own right.
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
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
opportunities for hiding backdoors that might be provided by elliptic curve technology.
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”
In a press
release, MasterCard announced yesterday an EMV payment card that
features a fingerprint reader. The release said that two trials have
been recently concluded in South Africa and, after additional trials,
a full roll out is expected this year.
In the United States, EMV chip cards are used without a PIN. The
fingerprint reader is no doubt intended to fill that security gap.
But any use of biometrics raises privacy concerns. Perhaps to address
such concerns, the press release stated that a fingerprint template
stored in the card is “encrypted”.
That’s puzzling. If the template is encrypted, what key is used to
decrypt it before use?
Continue reading “What kind of “encrypted fingerprint template” is used by MasterCard?”