Our modern identity services are exposed through developer-friendly APIs, SDKs and Low-Code services to deliver the scale and performance required for any and all customer use cases.
Featured Blog Post:
It’s notoriously difficult to implement an account recovery process that prevents fraud without creating more friction for customers who are already locked out and frustrated. In a US consumer...
Our reliance on online services is ever-increasing. These services are affecting us nowadays more than ever: they are conduits to our social interactions, finances, general conduct and well-being. In any given minute Amazon ships out 6659 packages, Zoom hosts 208,333 meetings, Venmo users send $239,196 and Doordash delivers 555 meals (World Economic Forum).
Controls that were considered adequate to protect online systems in the past can no longer provide the level of security required – considering this new span of control and the possible impact of a breach that comes with it. This change starts with authentication controls: online services need to deploy authentication solutions that are to a large extent resistant to a wide range of credential theft attacks.
The need to replace these controls is further amplified by users’ growing expectations for a frictionless, delightful experience when working with online services. Online service providers need to deploy new advanced authentication controls that will provide increased security while at the same time improving the friction imposed by the current pervasive authentication methods. Much of the hardware required for implementing low-friction, secure authentication controls has been around for quite some time. With the advent of smart mobile devices, Security Coprocessors, Trusted Execution Environments, and biometric sensors are now ubiquitous.
FIDO 2.0 makes authentication controls based on these technologies accessible to online services (often called “Relying Parties”). FIDO 2.0 does that by introducing two specifications: WebAuthn and CTAP.
WebAuthn, as its name suggests, is an API for exposing advanced authentication solutions to web applications. Implemented by all major browsers, WebAuthn allows web applications to request the registration of authentication credentials or verification thereof. Behind the scenes, the WebAuthn implementation (called “the WebAuthn client”) operates different authenticators – implemented by software or hardware.
Some of these authenticators may be tightly integrated with the WebAuthn client, or the platform on which it is executing. Others, however, may be authenticators implemented outside this platform/WebAuthn client boundary. Indeed, they may be implemented as external hardware devices — such as a USB-pluggable security key or NFC-based authentication device.
Enter CTAP, which defines the protocol stack with which a WebAuthn client can communicate with such external devices. Together, CTAP and WebAuthn allow web applications to authenticate users with a wide range of authentication devices.
The use of WebAuthn credentials is based on public-key cryptography: A credential can be thought of as a key-pair, where the private key is known only to the authenticator. The authenticator only allows signing an authentication “proof” with it subject to successful user authentication (which could amount to only possessing the authenticator in some cases). When registering a credential for a user, the web application requests (through WebAuthn) that the authenticator generates a new key-pair. The authenticator then provides the public key of that key pair to the online service where an association between the public key and the user is maintained.
To authenticate a user using a WebAuthn credential, the online service generates a challenge and provides it to the authenticator to sign with the credential’s private key — again by invoking WebAuthn. The signed challenge is then verified by the online service using the public key associated with the user at time of credential registration. Of course there’s more to the FIDO 2.0 specification than what’s captured in this brief introduction: authenticator metadata, attestation and extensions to give a few examples.
While FIDO 2.0 provides sound building blocks for implementing strong authentication, Relying Parties still need to implement quite a bit of functionality when choosing to deploy FIDO 2.0. Aside from the obvious need to implement the authentication protocol, including generating WebAuthn requests and running the cryptographic verification process on the response, Relying Parties should adopt an authentication interaction model and implement it, or opt for using third party services.
A fundamental question to answer when designing the authentication interaction model is how credentials are actually registered and associated with a user. In a trivial interaction model, a user can register new credentials at any time, by providing their existing legacy credentials (e.g username + password) to the relying party as a prerequisite for the registration process. However such a design does not offer a significant security advantage over legacy authentication methods. Since an adversary that is able to attack these legacy methods can always register a new FIDO credential. A more evolved model may employ various risk mitigations in the registration process. Another improvement would be establishing trust over time in an authenticator’s association with a user, and perhaps allowing users to “transfer” trust between authenticators.
Transmit Security applies these approaches and others, such as leveraging a network of relying parties to share registered authenticators and the trust established for them across relying parties. Of course, users should be able to also review and manage their already registered credentials. Here too, the relying party needs to implement user experience journeys that would permit that.
Another point that immediately surfaces when coming to design and implement a FIDO 2.0 interaction model is the distinction between platform-attached and cross-platform authenticators. Platform-attached authenticators are authenticators that are only usable from a specific platform (e.g., a biometric authenticator attached to a desktop machine) whereas cross-platform authenticators are authenticators that can be used across different platforms.
Most user interactions, users would prefer using a platform-attached authenticator as the authentication process does not require them to plug-in an external device. Note that a single user accessing the service from multiple platforms, e.g multiple laptops, is required to register platform-attached authenticators on each of these platforms. And the relying party should accommodate this. With Transmit Security, a hybrid model is supported where a FIDO 2.0 platform-attached authenticator registered on a mobile device can be used to authenticate a session established from a desktop device. This also allows leveraging strong authentication from devices that do not include a FIDO 2.0 platform-attached authenticator, without assuming users are possessing a special-purpose external authenticator, e.g. a “security key”.
The distinction between cross-platform and platform-attached authenticators also requires specific attention when implementing FIDO 2.0 support. For example, if a user has a platform-attached authenticator registered, the relying party should somehow be able to tell whether the device being used for access in a given session has platform-attached credentials registered on it or not. The problem is further compounded by the fact that on some platforms, e.g. Windows, different browsers on the same device actually share platform-attached authenticators whereas in others they don’t.
Unfortunately the WebAuthn API does not offer an easy way to query for available platform-attached authenticators, so the relying party would need to somehow track this; this could involve device fingerprinting, or the use of device storage. Which in turn could occasionally fail and adequate fallbacks should be offered to users. Transmit Security, for example, employs several layers of device identification and fingerprinting mechanisms to be able to tell whether a platform-attached authenticator exists on the current device.
The time for advanced strong authentication is here: The need is stronger than ever, and the technological ecosystem is ripe for broad adoption. However, successful implementation of this technology is not without its challenges and complexity. Relying Parties should be aware of this complexity and plan ahead for the implementation. Transmit Security solves this implementation challenge instantly by incorporating FIDO2.0 within the authenticator itself. Allowing companies to securely authenticate users without having to implement or deploy additional steps. Transmit Security delivers the industry’s first app-less, strong portable authenticator that uses device-based biometrics for secure, convenient and consistent customer authentication.
