Demonstrations

Demonstration of cross-browser passwordless authentication

Two apps published on GitHub, one that uses a nosql database (MongoDB), and one that uses an sql database (MySQL) demonstrate a simple method of cryptographic authentication that allows the user to log in without a password on any browser, in any device. Both can be set up on an Amazon AWS EC2 server. An installation script and set-up instructions are provided.

To register, the user enters an email address and any self-asserted user data required by the relying party (RP) into the registration form. The RP backend creates a user record with the address and the user data, and sends a message containing a link with an email verification code to the address. The demos give you the option of using the AWS Simple Email Service (SES) to send the message, or to simulate the message by displaying a web page containing the link after a delay. Opening the link in a browser causes an HTTP request to be sent to the backend, which verifies the code and responds with a page containing JavaScript code that creates a key pair in localStorage and sends the public key to the backend along with a signature on a key-confirmation challenge. The backend creates a credential record containing the public key and the email address, the latter serving as a reference to the user record.

The user can then log in on any browser by entering the email address into a login page. JavaScript code in the page looks for a key pair associated with the address in localStorage. If found, it authenticates by signing an authentication challenge with the private key. If not found, the JavaScript frontend reports the absence of a credential to the backend, which sends an email verification link as when registering. Opening the link in the browser results in the creation of a key pair in localStorage, and the addition of a new credential record to the backend database containing the public key component of the key pair.

Demonstration of two-factor cryptographic authentication with a fusion credential

One-factor cryptographic authentication with a key pair has the security benefit of resisting both ordinary and man-in-the-middle phishing attacks, and the usability benefit of being passwordless. But a cryptographic factor is a possession factor, and as such is inherently vulnerable to theft of the device. For that reason it is typically used in conjunction with a second factor, such as a knowledge factor (a PIN or password) or an inherence factor (a biometric).

There are three methods of adding a second factor to a cryptographic factor.

1. One is to use the second factor to unlock the first factor. This is often done in smart cards, such as the US Government’s Personal Identity Verification (PIV) card, which must be unlocked with a PIN or biometric before use, and FIDO2 credentials stored in platform authenticators, which must be unlocked by the same PIN or biometric used to unlock the device.
2. Another one is to use both factors independently of each other. For example, the relying party (RP) could ask for a password in addition to verifying a signature on a challenge computed with the private key. This would provide protection against impersonation after device theft of following a successful MITM phishing attack. But it would leave the password itself vulnerable to phishing attacks, reuse at malicious sites and backend breaches.
3. A third method is to combine both factors into a fusion credential where they protect each other and thus provide more security than if they were used independently.

An example of a method of cryptographic authentication with a fusion credential can be found in this GitHub repository, with a live demonstration available at demo.pomcor.com. As explained in more detail in this blog post, a password is fused with an extended key pair in a way that provides the familiar user experience of authentication with email and password, while achieving phishing resistance, protecting the password against reuse at malicious sites and backend database breaches, and protecting the cryptographic credential against cryptanalytic and postquantum attacks.

As in the one-factor passwordless authentication demos, the user can log in on any browser in any device. But while in one-factor cryptographic authentication a different randomly generated key pair is used in each browser, in two-factor authentication the same cryptographic credential must be used in all browsers, because it must be fused with the same password. As explained in more detail in the blog post and in the README.md file of the repository, this is achieved without synchronization by generating the cryptographic credential from the email address and a rotatable master secret.