What are some FIDO2-compatible devices out there?

Melnichenko: This is an interesting question.

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 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 personalization 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.

What about customization and additional security requirements?

Melnichenko: Long story short, this is something of a gray 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 manoeuver in terms of customization and the implementation of additional requirements.

Any organization 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 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 to detect the relevant anomalies and events. In this regard, the level of security that is offered by FIDO2 has proven to be insufficient: