The Ultimate Guide to Passwordless Authentication

Nik Pot -

Password-based world

Digital identity is so critical to everything we do online, yet it gets compromised in almost every cyber security breach. Every now and then we would hear the news and learn about yet another data breach where identity compromise would be at the core of it. But not everybody is willing to accept the simple truth – we are not equipped with the proper tools to protect our identity. We keep using old inefficient architectures and tools that have been invented decades ago.

First passwords probably arrived at the Massachusetts Institute of Technology in the mid-1960s, when researchers at the university built a massive time-sharing computer called CTSS. The punchline is that even then, passwords didn’t protect users as well as they could have.

Fast forward 60 years and we are still using the same “strings of characters” that can ruin our lives and reveal everything about us. Your email. Your bank account. Your files. Your private photos. Your location. No matter how complex, no matter how unique, our passwords can no longer protect us. We constantly try to patch passwords, but we are unsuccessful. Take Multi-Factor Authentication as an example. Despite the obvious benefits, users are still leveraging it on a selective basis due to the significant user experience friction that it introduces.

At idemeum we believe patching passwords is no longer an option. We have to come up with simple, secure, and passwordless technology stack to handle our authentication online.

How passwords survived for that long

Using passwords to access online services is a commonplace experience and so are the user frustrations.

Passwords have survived for that long probably due to the three major reasons:

  1. Simplicity – passwords are very simple to use. Type in characters, press a button, and you are in. No additional hardware required and no compatibility issues with pretty much any service online.
  2. Ubiquity – passwords are everywhere. Unfortunately, they are like digital waste– everywhere we go, we leave a password behind. The experience of using passwords is so ingrained in our digital routine that there is no need to explain anyone how to use them. It is familiar and casual.
  3. Replaceability – when compromised passwords are easy to replace. Unlike biometrics that are immutable, we can generate as many passwords as we want.

Why passwords need to go away

When one starts digging into real password experience and implications the reality becomes more disappointing.

  1. Expensive – passwords are expensive for users and developers alike. Developers pay maintenance $ for storing, hashing, encrypting, and managing password infrastructure. Users pay productivity hours given the fact that passwords cause lock-outs, need to be reset frequently, and consume time with inevitable recovery flows.
  2. Cause friction – yes typing password is simple. But looking at the overall lifecycle, we first need to create one, and with more and more stringent requirements (seven uppercase letters, four special characters, etc.) it is not an easy feat. But the real dance comes when you need to remember your password out of 100s of combinations that you already have
  3. Wildly insecure – more than 80% of breaches are due to compromised credentials. The statistics is validating that hackers’ tools are effective: phishing, spear phishing, brute forcing, rainbow tables, and many others are always there to aid in compromising your password.

The reality is that we are all annoyed by passwords. We’ve got dozens to remember, some of them annoyingly complex, and on any given day, as we read e-mails, send tweets, and order groceries online, we’re bound to forget one, or at least mistype it. Moreover, we know passwords are going to compromised. That will happen sooner or later. And no one is going to enjoy it when that happens.

Passwordless world

Passwordless authentication (or “modern authentication,” as it is known in the industry) is the term used to describe a group of identity verification methods that don’t rely on passwords. Biometrics, security keys, certificates, and specialized mobile applications are all considered passwordless authentication methods.

We will now get deeper into each passwordless technology:

  1. Certificate based authentication
  2. Magic links
  3. One-time passwords (OTPs)
  4. Hardware tokens
  5. Webauthn/FIDO2
  6. Mobile as authenticator

Certificate based authentication

Certificate based authentication allows users to securely access an application by exchanging a digital certificate instead of a username and password.

To create a digital certificate, Public Key Infrastructure (PKI) must be used. PKI allows for what is called an asymmetric encryption. Client generates two keys: private key that is kept secret by its owner, and public key that is disseminated widely and openly. Leveraging this asymmetric key pair, PKI enables:

  • Public key encryption – message is encrypted with a recipient’s public key. For properly chosen and used algorithms, messages cannot in practice be decrypted by anyone who does not possess the matching private key.
  • Digital signatures – message is signed with the sender’s private key and can be verified by anyone who has access to the sender’s public key. This verification proves that the sender had access to the private key, and therefore is very likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as a signature is mathematically bound to the message it originally was made from, and verification will fail for practically any other message, no matter how similar to the original message.

Client can then create a digital certificate that will conform to X.509 standard. X509 certificate will have various fields to identify the owner, including public key, subject name, validity period and others. The key here is that digital certificate needs be signed by some trusted 3rd party, so that this certificate can be trusted to represent identity of the owner.

In order to use digital certificate to authenticate to a target application, client will need to share a X.509 digital certificate with the application along with the proof of possession. Proof of possession will be represented by a nonce signed by a private key. When application receives the digital certificate, it can extract the user information from that certificate, and then will verify proof of possession to make sure that the requestor actually owns the private key.

Certificate-based authentication flow

Certificate based authentication is very popular in enterprise space due to the fact that most employee devices are managed with MDM, and it is convenient and easy to provision certificates to client devices.

However, certificate based authentication is not as prevalent in consumer and developer space, as it is quite complex to install and manage X.509 certificates on unmanaged user devices. Some vendors try to create mobile and desktop applications that aim to simplify certificate provisioning and management, but the user experience will still be complex for ordinary users.

With magic links an application sends a unique URL link to user’s email address or mobile phone via SMS. There is no need to enter any credentials. Instead, the user clicks on the magic link to authenticate. Since the magic link includes unique one-time authentication token, the user is logged in and redirected to an application landing page.

Magic link authentication flow

Magic links enable great frictionless experience for the users as there are no credentials to remember and very few steps to perform.

However, we believe that to provide best possible experience magic links need to be combined with cross app Single Sign-On, so that when the users verify their email with magic link they can maintain the session and seamlessly login across applications.

One-time passwords (OTPs)

OTPs are heavily used in multi-factor authentication flows, but one-time passwords or one-time codes can also be used as a standalone authentication method.

OTPs are time-bound numeric codes linked to a reference.
  • One-time passwords function via random algorithms that create a new and random code each time access is requested.
  • These codes are sent to a user upon providing a reference (email address or phone number). When the user enters the code back to a target application, the user is authenticated.
  • As soon as the OTP enables access to the account, its validity comes to an end. Since an OTP (a four or six-digit numerical PIN code in most instances) can be entered just once, it’s not as risky as static passwords that can be used multiple times.

The biggest advantage offered by OTPs in contrast to standalone passwords is that they’re safe from replay attacks. In plain language, an adversary who uses trickery to capture your OTP can’t reapply it, since it’s no longer valid for future logins or sessions.

Hardware tokens

A hardware security token is a physical device that validates user’s identity and grants access to the target application or resource. The user must possess this token to complete the authentication process. Hardware tokens can be used as a primary authentication method, or used in combination with other authentication factors such as username and password.

Hardware tokens come in many forms, most commonly as USB tokens, key fobs, and wireless Bluetooth tokens. Also, there are three main types of hardware tokens.

  • Connected tokens – a user must plug the security token into the system, computer, cardholder, etc. to complete the verification. Two examples of this type of token includes a USB token and a Common Access Card (CAC), the latter of which requires the use of a CAC reader.
  • Disconnected tokens – these are the small devices that look like a sim card, keychain fob, or USB flash drive. These tokens generate a unique and temporary cryptographic code that must be input by the user to gain access to a computer resource.
  • Contactless tokens – with contactless tokens, you don’t need to connect to a device or enter any access codes. Instead, contactless devices connect with the system wirelessly. Based on the connection’s credentials, the system either grants or denies access. The most noteworthy examples of contactless tokens are Bluetooth tokens.

Webauthn / FIDO2

The Web Authentication API (also known as WebAuthn) is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password.

WebAuthn is part of the FIDO2 framework, which is a set of technologies that enable passwordless authentication between servers, browsers, and authenticators. Today WebAuthn is supported by major browsers, including Chrome, Firefox, Edge, and Safari.

Webauthn allows applications to integrate with strong biometric authenticators built into end user devices, like Windows Hello or Apple’s Touch ID. Instead of a password, a private-public key-pair (known as a credential) is created for a website. The private key is stored securely on the user’s device; a public key and randomly generated credential ID is sent to the server for storage. The server can then use that public key to prove the user’s identity.

Let’s first look at the major components required to enable passwordless authentication with Webauthn.

Webauthn architecture components
  1. Webauthn API – common and public API implemented by all major browsers that provide a mechanism to interact with FIDO based authenticators. This API defines registration, meaning enrollment of a credential, and authentication methods.
  2. FIDO2 server – FIDO2 implementation in the application’s backend. FIDO2 server calls browser based Webauthn API in order to communicate with the platform or roaming authenticator.
  3. CTAP – Client to Authenticator Protocol. CTAP defines how the FIDO client running on a specific platform, e.g. an operating system or a web browser, can talk to an external authenticator such as a USB-powered security key or a mobile phone that can interact with the computer via NFC or Bluetooth.
  4. FIDO authenticator – hardware based authenticator (USB device or built-in biometric sensor) that protects that user private key with which the authentication is performed.

Here is the high level flow to show how Webauthn authentication is performed on the web.

Webauthn registration:

  1. First a user proves his identity with some other means, such as proving ownership of an email (using magic link), or uploading ID document for online identity proofing.
  2. FIDO2 server starts the registration process by calling Webauthn browser API with the registration request.
  3. Webauthn API communicates with FIDO authenticator over CTAP to create scoped credentials for the user.
  4. Private key will be stored with authenticator and public key will be passed to the application backend. Response to the FIDO2 backend server will include various attributes including public key, attestation, and client data.
  5. Application backend will store the public key and associate it with the identity of the user.

Webauthn authentication:

  1. User requests access to the application.
  2. FIDO2 communicates with the Webauthn API using authentication method and passing the authentication challenge.
  3. Webauthn API passes the request to authenticate and challenge to FIDO authenticator using CTAP protocol.
  4. User is prompted to use biometrics to unlock access to authenticator private key.
  5. Upon success, challenge is signed with the user private key by FIDO2 authenticator and is passed back to application backend.
  6. Application validates the signed challenge with the user public key and grants access to the user.

Webauthn is the modern authentication protocol that is currently undergoing broader adoption across website and browsers. It offers strong passwordless authentication for the users, however as you can see it is not solving enrollment / registration step. To provide complete frictionless experience to users Webauthn needs to be paired with other tools such as magic link or online identity proofing to address user enrollment.

You can try Webauthn demo here.

Mobile as authenticator

The last passwordless method we wanted to cover is using your mobile phone as an authenticator. It is also called Passwordless MFA as it combines multiple authentication factors together:

  • Something you have – you mobile phone and certificate that resides on your mobile device.
  • Something you are – mobile device biometric sensor, such as Face ID or Touch ID.

There are various implementations that we have seen in the industry, but we believe that the best and most secure implementation should be leveraging FIDO and Hardware Backed Security on a mobile device. Meaning that authentication shall be driven by FIDO protocol, and both iOS and Android support FIDO today. And the FIDO private keys need to be protected by HSM modules on mobile devices (Secure Enclave on iOS or TEE / StrongBox on Android).

The most typical authentication flow is to install and leverage a mobile app that will handle authentication.

  1. User requests access to an application.
  2. QR-code is displayed instead of asking user for any input. There are various possibilities here – for instance asking for email and then sending push notification, but we find QR-code providing the most seamless experience.
  3. User scans the QR code with mobile app.
  4. Application triggers FIDO based authentication.
  5. User authenticates with a biometric sensor on a mobile device.
  6. The application verifies the authentication response according to FIDO spec and grants access to the user.

Final thoughts

When we talk about Passwordless Authentication we immediately think and focus on authentication only. However, we need to think about user digital identity journey holistically – how will users enroll into our identity system, how will we authenticate them strongly yet providing great experience, and how will we let users manage and maintain their digital identity.