Pavel Melnichenko, CTO & Co-Founder, Airome Technologies, answers some pressing questions about FIDO2, especially for the banking and finance sector.

Many of us may know that FIDO2 is more secure than one-time passwords (OTPs), which are vulnerable to phishing attacks. The FIDO2 industry standard is more secure than OTP because it prevents man-in-the-middle attacks.

What else should we know about FIDO2? Is it suitable for any and every organization in the financial sector? Pavel Melnichenko, CTO & Co-Founder, Airome Technologies, provides some thought-provoking and controversial answers here:

What is FIDO2 all about?

Pavel Melnichenko: 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 organization that is developing and promoting the project) is seeking to encompass lots of possible fields of application (desktop, web, mobile platforms, and apps).

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

Pavel Melnichenko, CTO & Co-Founder, Airome Technologies

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.

How simple is it in reality?

Melnichenko: 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 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 (personalization, restoration of access, replacements, feedback, updates, etc.).