How simple is it in reality?

FIDO2 is a remarkable project that has been driven by IT industry giants all over the world for several years now. Describing what exactly the project is in a concise manner is rather difficult since the FIDO Alliance (the organisation that is developing and promoting the project) is seeking to encompass lots of possible fields of application (desktop, web, mobile platforms, and apps), if not all of the aforementioned.

In general terms, FIDO2 is a combination of a set of principles (the framework), standards (WebAuthn), protocols (CTAP2), and hardware requirements.

FIDO2 describes in intricate detail how these things combine with one another. The goal of implementing all of these, however, is to make reliable authentication methods (and by that, we mean ones that are passwordless) simple, accessible, and understandable for users and, no less importantly, for developers too.

When we talk about reliable, passwordless authentication, we automatically end up referring to some kind of "gadget" that will authenticate a user in various services using cryptographic systems. That is to say, this "gadget" has to save the user's keys (not passwords, but cryptographic keys) and use them when interfacing with services. How this "gadget" interacts with the user themselves (requesting their PIN code, fingerprint, or a facial or retinal scan) doesn't really matter. What is important is that, after jumping through a whole bunch of hoops, it has to interact with the service and persuade it that the user can be allowed to progress further.

Let's imagine that a web service developer is filled with a sudden enthusiasm for security and decides to implement this highly reliable form of authentication. What does he need to do in order to achieve this?

The developer is creating a web service. That is, he's using a browser as a runtime environment and as an environment for interacting with the user. In order to interact with a new "gadget" from a browser, he needs an API. There are tons of browsers, and it wouldn't be a bad idea to have a uniform API for interacting with these authenticator "gadgets". With this goal in mind, FIDO2 has created the WebAuthn standard (an API that is provided using JavaScript), which should be implemented by browser developers for working with authentication devices.

When browser developers start implementing WebAuthn, they are faced with a question: what exactly are these "gadgets"? What can they do? How can one interact with them? The answer to the first of these questions is provided by the CTAP2 protocol, which is a protocol for interfacing with authenticators that the user has at their disposal.

The second issue will be solved by the manufacturers of these very authenticators. They look at the protocol and get an approximate understanding of its functionality and of the methods for connecting authenticators to computers and other devices belonging to the user, but they focus on hardware requirements.

Thus, it would seem, the FIDO Alliance has provided a wake-up call to both gadget manufacturers and browser developers and has also described all the principles and algorithms for working within a common framework for the benefit of web developers. However, the need to carry out server-side authentication checks for web apps still remains. In this regard, the FIDO Alliance has also described everything, and security solution providers are offering their own FIDO2-compatible server-side components for managing authenticators and for carrying out authentication processes.

That is to say, the fairly simple task of user log-in is nonetheless converted into:

1. Integration with server solutions for managing authenticators and for handling the authentication process.
2. Integration with browser-side (user) devices.
3. The creation of processes for managing authenticators (personalisation, restoration of access, replacements, feedback, updates, etc.).

What FIDO2-compatible devices are there?

This is one of the most interesting questions.

The pioneer that is on everyone's lips when it comes to FIDO2-compatible devices is Yubico. They're fantastic devices that, for the most part, connect via USB. Whether this is convenient and practicable, only time and user feedback will show, but many people believe that this can be achieved more straightforwardly. Yubico represents manufacturers of portable authenticators, including Bluetooth devices.

Windows-based laptop and desktop PC manufacturers have learned to link integrated platform-based mechanisms (so-called Trusted Platform Modules (TPMs)) to FIDO2 services. The Windows Hello feature functions as an interface for interacting with a TPM module. A fingerprint or face recognition scan is used to access the authenticator built into the laptop or desktop PC.

Apple, who are, as usual, ahead of everyone else, use their own Secure Enclave, which is visible to users as TouchID and FaceID.

Android smartphones have Android Keystone and TouchID.

And that's all well and good, but it is worth directing your attention at this point to the third challenge faced by service developers: creating processes for managing authenticators. Take a look...

How do you bring together a service and a FIDO2 device?

The process of registering an authenticator in a FIDO2 service consists of the mutual exchange of keys and data concerning the account between the server and the authenticator. In 99% of cases, the process looks like this:

-        The user logs-in to the service (in the normal way, using a username and password).

-        The user presses the "I want to log in without a password" button.

-        Magic happens (the authenticator - the Yubico key/Windows Hello/Apple FaceID/Google TouchI does its work).

-        And that's that.

The process for restoring access in case of a lost authenticator or it’s damage can either be exactly the same or a little more complex (via SMS or email).

The general idea is that registration and restoration of access are carried out "as usual," using a password and via SMS.

That is to say, the "regular" use of FIDO2 doesn't cover scenarios of account theft or account data leak via procedures for restoring access. Nonetheless, it does cover scenarios related to the constant submission of passwords during normal use.

But what exactly constitutes non-normal use? For portable devices such as Yubico keys, offline personalisation scenarios are a possibility, whereby the key and the service are brought together somewhere beyond the framework of the user's work with the service. That is to say, the user is provided with a key that is already familiar with the service, and the user doesn't need to log-in using a username and password the first time. Obviously, this is less convenient and isn't always feasible. But scenarios such as this are necessary for people to whom security is crucial.

However, such scenarios are fairly difficult to implement for integrated authenticators like Apple FaceID, Android TouchID, or Windows Hello.

But what about customisation and additional security requirements?

Long story short, this is something of a grey area.

The issue is that FIDO2 is aimed at solving tasks for the maximum number of ordinary services and eliminating the need for passwords. These ordinary services aren't developed by security specialists, but by regular developers. As far as they are concerned, all this terrifying "cryptography" should be simplified as much as possible and outlined in sample code that can be copied and pasted. However, this approach does not leave any room for manoeuvre in terms of customisation and the implementation of additional requirements.

Our company specialises in creating authentication and transaction confirmation solutions for the finance sector, where every client has their own individual requirements and scenarios. We want to share some real queries and ideas related to the issue of "how can we combine these requirements with FIDO2?" succinctly and concisely.

Case study 1 — What about anti-fraud measures?

Any client who is moving to a passwordless solution for authentication and transaction confirmation understands the risks related to the initial log-in and restoration of access. Nonetheless, the usage scenarios satisfy their business requirements. Security department is addressed by connecting an anti-fraud system for establishing operation with a new device, the initial connection, and the restoration of access on a device that has already been used.

FIDO2 mechanisms are simply not capable of collecting the device information in order to detect the relevant anomalies and events.

In this regard, the level of security that is offered by FIDO2 has proven to be insufficient.

Case study 2 — A mobile app and offline personalisation

A client decides that, given its processes, it does not have the capacity to offer users the ability to manually link a device to their account. At the same time, it operates using just a mobile app, to which a USB key cannot be connected. What's more, the client does not wish to use any additional devices (such as a Bluetooth authenticator), due to the latter being inconvenient and expensive.

There are no scenarios of this kind with FIDO2. Unfortunately.

Case study 3 — PKI integration

The client needs to use a unified solution for authentication and document signing. Document signing should be performed using public key certificates (PKIs). The solution has to work in a mobile app.

FIDO2 is simple and elegant, which cannot be said of PKIs. It is not suitable for the above requirements.

Case study 4 — Legal significance

If we're talking about the financial sector and about remote access to accounts, then the legal basis for the processes involving authentication, the usage of different devices, and the confirmation of user actions is an essential element.

The client's lawyers took the preparations for their own defence against potential conflicts rather seriously and concluded that FIDO2 mechanisms would not constitute an adequate evidence base for a court regarding whether actions had been carried out by a legitimate user.

Case study 5 — a telephone operator

The client has a scenario whereby the user carries out actions in the system via telephone, simply by dictating them to the operator. The user should subsequently receive a notification on their mobile phone. They should then read the outcome (whether the operator has correctly specified the relevant details) and confirm it. With authorship and integrity control.

How this can be achieved with FIDO2 without any further support is not entirely clear.

This is just a small sample of the questions that arise when working through individual scenarios for a large service, where real people's money depends on a combination of convenience and security.

Moreover, FIDO2's mechanisms offer the same integration pathway as other services for solving tasks related to authentication and transaction confirmation: server-side integration, client-side integration, and the creation of management processes. One positive thing about FIDO2 integration is that, theoretically, a client can replace one server with another or start using new authenticators. I say "theoretically" because implementing standards always has its intricacies.

As for now, the main trend is a shift to mobile and apps. If you've got a service that's slightly more complex than an online store, you can always convert your mobile app into an authenticator. It allows to confirm log-in and transactions content in the service, regardless of the channel that is being used: the web, telephone, a messenger or a mobile app.