FIDO’s Future

In honor of World Password Day on May 5th the FIDO Alliance, together with Google, Apple and Microsoft, announced “plans to expand support for a common passwordless sign-in standard”. In other words, they (once again) publicly committed to FIDO.

This is not new. All three companies have long supported FIDO to some extent. Both Google Chrome and Microsoft Edge have had WebAuthn and CTAP2 support for a few years now. iOS also has WebAuthn support since 14.5.

The two hot new things are:

1. smartphones as roaming authenticators via Bluetooth, and
2. multi-device credentials (“passkeys”), via cloud sync. ¹

The announcement has brought some renewed attention to FIDO. Reason enough to write down my thoughts on the current state of the FIDO ecosystem!

First, I will give a short introduction/refresher about FIDO and its concepts. Then, I will go into what I think is great about FIDO, as well as some of the problems that I see.

Background

Back in the early days, there was the password. Unfortunately, people took that too literally and chose words like “password” or “qwerty” (is that a word?) as their password.

In response to that (and recalling that good passwords should be long) we collectively decided to call them passphrase instead (phrase, as in “sentence”). Surely sentences are easier to remember! But that didn’t work either – people kept chosing “letmein”.

So now, “the industry has introduced the term passkeys” (source). “The industry” meaning Apple. ^{2 3}

This is where FIDO comes in. The basic idea behind FIDO is that instead of user-chosen passwords we can use public key cryptography to authenticate users. Hence the word “passkey”.

Here is how FIDO replaces the registration and login processes (roughly speaking):

1. Upon registration, you create a public-private key pair. The server provides you with a challenge, you sign, and – bam – you are now registered. This is trust-on-first-use.
2. Upon authentication (aka login), the server again sends you a challenge. You sign it, the server verifies it, and you are logged in!

Basically, this is all that FIDO is. Public key crypto and a challenge-response protocol.

Unfortunately, you (the human) already have a hard time keeping 256-bit numbers in your head, let alone computing ECDSA signatures with those numbers. Luckily, all this cryptography is done for you by an authenticator. There are two main types of authenticators: First, platform authenticators, which are built into your device. Think Touch ID, Face ID, or Windows Hello. Second, roaming authenticators, that can “roam” around, between multiple devices. Think physical keys (YubiKeys, …). They communicate with your computer via USB, NFC or BLE (using the CTAP protocol). ⁴

In addition, there is WebAuthn. WebAuthn is the API that websites or desktop/mobile apps interact with (see the Mozilla docs). The browser or OS then handle the communication with the authenticator (either internally for platform authenticators, or via CTAP for roaming authenticators).

So overall, when people speak about FIDO or FIDO2, they mean WebAuthn and CTAP. Here is my amateur drawing of an overview of FIDO:

For a deeper dive, see this glossary and this blog post as starting points for further reading. Adam Langley also has multiple great posts on security keys. Apple’s WWDC22 video nicely shows how the UX flows can look like.

By the way, did you know that the new SwissPass can act as a roaming authenticator over NFC? Every public transport user in Switzerland now gets a security key included in their travelcard! Since it is FIDO-compliant, you can use it to log in to any website that supports WebAuthn (on your phone, or on a laptop with an NFC reader).

What’s new?

One big UX problem for FIDO so far was that keys were bound to a single device. That meant you would need to manually enroll two or more security keys (in case you loose one), or manually enroll both your laptop and your phone. What is more, you would need to manually do this for every single service where you used FIDO. Just imagine switching phones, having to manually enrol your new phone in 10+ services again.

FIDO now proposed to solve this with multi-device keys. Effectively it lifts the requirement that a key needs to be bound to a secure hardware element, and allows it to be synced. Notably, the standard does not impose any requirements (security or other) on the nature of the sync service, and instead leaves it up to the vendor (e.g. iCloud).

Yes, this lowers the high bar that you get from hardware-bound secrets. But for the average user reusing their passwords, it still a major step up. In high-security contexts, you can continue to use device-bounds keys.

A second UX problem was the need to buy a security key. Without such a roaming authenticator that can plug into a USB port, how would you log into a new device?

This second problem is solved by specifying how smartphones can act as roaming authenticators. If you have a registered FIDO key on your smartphone, and you want to log into your email account on a workstation in a public library, you can scan a QR count on the workstation. The QR code contains information for local pairing over Bluetooth, thus proving proximity. Then your phone and the workstation will run the normal CTAP protocol, with your phone acting as a roaming authenticator. ⁵

These changes are exciting because they promise to clear the way and remove the two main blockers of mainstream adoption.

The good

The good: things that are great about FIDO and that we should do more of.

No shared secrets

One thing I love about FIDO is that it eliminates shared secrets. Instead, the secret (aka. private) key stays solely on the user’s device.

The long history of password leaks has shown that it is difficult to protect the treasure chests that password databases are. It is much easier to break into a single central server, than millions of end-user devices.

By using public key crypto we also get phishing protection: the secret never leaves the device, so there is nothing to be phished. ⁶

No human-generated secrets

With FIDO we move away from mostly human-generated secrets and towards (pseudo-)randomly generated secrets. Sure, we have mitigations like salting or special hash functions (scrypt, Argon2). But in the end, they are still band-aids working around a low-entropy source.

Industry push

Any technology can only make a difference if it has broad user adoption and widespread software support. Unfortunately, widespread adoption doesn’t just happen. Companies and people need to invest money and time. And sometimes, you need peer pressure to make a step.

We have seen this before with biometrics on laptops: Thinkpads have had fingerprint sensors for generations. Yet only after Apple pushed Touch ID on MacBooks we started seeing improved software support (imho because people know it from Apple and also demand it from other products). Even on Linux fingerprint sensors are starting to “just work”!

With FIDO we can hope for the same effect. Google, Apple, Microsoft and Mozilla laid the foundations over the past few years (and took on the initial risk of investment!).

We are still far away from people being so used to passkeys that they start demanding it from all products. But with industry leaders committing and leading the way, we can get there.

The bad

The bad: things that I think are problematic about FIDO, and that should be talked about more.

This is not to say we should throw FIDO out of the window and start anew! In fact you will see that some problems are very familiar and keep coming up in different areas of IT.

TLS client certificates revisited

First of all, why are we inventing a new protocol?

FIDO and its use of public key cryptography inherently reminds me of TLS client certificates. In both cases, the user/client holds a private key and uses it to authenticate itself to the server.

The only difference is where the server’s trust in the private key comes from (or rather, its trust in the binding from the key to a human). In FIDO, it is trust-on-first use, i.e. the server remembers the (public key, identity)-binding. In TLS client authentication on the other hand, the server derives its trust from the certificate chain that is presented alongside the public key.

Other than that, the two are pretty similar:

• Both use public key crypto.
• Both can have their secret key material either stored simply on disk or in secure hardware (YubiKeys, smartcards). ⁷
• Both have some form of freshness. This guarantees to the server that the client was recently alive (FIDO: challenge response, TLS: signing the session transcript).

Which begs the question: why are we not using TLS client certificates?

Or, in other words: if nobody outside enterprise uses TLS client certs, if no consumer site offers client certs, if client cert usability is so bad – why should FIDO succeed where client certs did not?

And, more concretely: what does FIDO do better than TLS?

I already mentioned that FIDO has hardware attestation, and TLS client certs don’t. ⁷ Also, you might argue that it makes sense to separate transport and authentication into separate protocols.

On the other hand, I would argue that having both together is beneficial, since it allows you to bind the security of your channel to an identity. That is, you can run FIDO over a TLS connection that is being MITMed (assuming the TLS client trusted the server cert, or a trusted CA has been compromised) – the server won’t notice that the connection to the WebAuthn client is not private.

Also, in terms of performance it makes sense to bind transport and authentication together. In almost all cases you need a secure channel anyway to communicate further after authentication. Why spend extra round trips with FIDO if you can integrate it into TLS? At Google-scale, the extra requests will make a difference.

I would love to hear your thoughts on this question (FIDO vs TLS client certs)!

Proprietary solutions

Open standards don’t lead to open solutions.

For Android, Google implements FIDO support in their proprietary Play Services (rather than in AOSP). That means all the CustomROMs and Android-based OSes without ties to Google won’t have FIDO support for a long while.

Meanwhile, Microsoft’s announcement on World Password Day (while everybody else was announcing their push for FIDO) used the terms “Azure”, “Windows”, “Microsoft” noticably more often than it did say “FIDO” or “Webauthn”. So far, my impression is that they are boasting with FIDO and open standards, all while pushing their proprietary Authenticator app.

Additionally, banks love to build their own 2FA apps rather than use TOTP for their online banking logins. Will they switch to FIDO?

Furthermore, how will the new multi-device credentials work? Will users be locked into the iCloud ecosystem? Or will Apple offer a way for 1Password or Keepass to plug into its FIDO APIs and function as a passkey sync provider? This is especially critical since FIDO does not specify how multi-device keys are synced. The sync services will be the Achilles’ heel for the security of users’ passkeys.

Higher complexity for developers

Implementing FIDO is more complex than username+password. For the time being, this will continue to pose a barrier for entry.

You need to parse binary messages, handle keys, verify signatures, generate challenges, adhere to a specification, and so on. Of course, all of this will be (and should be!) outsourced into libraries – after all, you also don’t implement your own TLS code.

But even with the bit-juggling abstracted away, developers still need to learn the concepts and the terminology. It is not simply a matter of new HTTPSConnection(url). The WebAuthn API seems innocent: it is just create() and get(). But you need to understand how to prepare your inputs and how to interpret the outputs.

FIDO has many options and knobs that you can configure. What’s the difference between attestation and assertion? What are PublicKeyCredentials, and which ones should I choose? What level of user verification do I want? Do I really need to verify that counter? Should I allow multi-device credentials, or only keys that reside in TPMs?

I can imagine a world where web frameworks and CMS systems offer FIDO support out of the box as part of the user management. But this will take time. Until then, developers will need to go through this learning curve. It is not impossible – but it is an barrier that I think is often neglected in the hype around FIDO.

Widespread support

With all the hype around FIDO: how good and how widespread will FIDO support actually be in reality?

On the authenticator side:

• Firefox still does not support CTAP2 on MacOS and Linux, only on Windows using Windows Hello (but they are working on it). Which means even though it has a WebAuthn API exposed to JavaScript, you cannot use features like discoverable credentials. Discoverable credentials are important because they allow usernameless signin (as opposed to “only” passwordless). They were introduced in CTAP2. In practice, this means that you still cannot use your YubiKey for passwordless sign-in to Microsoft’s ecosystem using Firefox.

  I.e. “FIDO support” in Firefox in July 2022 means “WebAuthn wrapped around CTAP1/U2F”.

• Support on the Linux desktop (for desktop apps, similar to Windows Hello) will (most likely) take a while.

• AOSP won’t support FIDO either any time soon (due to it being implemented in Play Services, see above).

On the website/client side:

• I have over 200 entries in my password manager. Only a fraction of those offers TOTP (20%). And an even smaller fraction offers WebAuthn (5%). Given FIDO’s complexity: will FIDO surpass TOTP? Will it become the password-killer?

  A real world example: ETH Zürich is planning to roll out 2FA in autumn 2022 for its single sign-on. But it will use OTP (presumably TOTP), not WebAuthn.

• Almost all consumer websites offer WebAuthn merely for 2FA. That is, they are not replacing passwords. One exception is Nextcloud, which offers it for passwordless signin. Not a single website I use offers usernameless signins via WebAuthn.

• On the upside, FIDO support is already significantly more widespread on consumer websites than TLS cert support is.

Research & academia

From an academic perspective, FIDO is a relatively new protocol, and research into it is just getting started.

There are some relatively recent papers formally modelling and formally verifying it (formal as in formal methods). One using ProVerif, another looking at the crypto in the computational model. Others are already presenting real-world attacks.

This reminds me of SSL/TLS and WEP/WPA: industry builds it, academia breaks it, industry patches it, repeat.

TLS 1.3 broke this cycle: it involved academia early on in the standardisation process. There was a lot of research into both the handshake and the record layer that was incorporated into the drafts. Also the research attacked the spec from multiple angles: proving cryptographic security computationally (as opposed to information theoretically), tool-based approaches (Tamarin, ProVerif), and formally verifying implementations.

This is not a central criticism of FIDO! FIDO is just starting out, you cannot expect dozens of researchers already jumping onto it. But if FIDO does prove itself to be there to stay and gains significant adoption, FIDO3 or FIDO4 should involve academia more early on in the process, just like TLS 1.3 did.

The name

WebAuthn has not even reached broad adoption, yet the name is already outdated: WebAuthn started out as a web standard, but with native/mobile/desktop support, it is now breaking out of the browser. Native iOS and Mac apps can use the WebAuthn protocol over native, non-browser APIs. Thus the term WebAuthn has become too narrow.

Even within FIDO (or should I say FIDO2? Or FIDO/WebAuthn?) there are legacy names that keep getting changed (e.g. resident keys aka. resident credentials aka. discoverable credentials).

In addition, it is often unclear what someone means when they talk about having “FIDO support”. Do they mean only WebAuthn? Do they mean CTAP2 as well (cf. Firefox)? What about U2F? And CTAP1? Wait, U2F and CTAP1 are the same thing.

The naming is not (yet) as messy as with USB (hello, USB 3.0 and USB 3.1 Gen 1 and USB 3.2 Gen 1x1). But it is definitely not very human friendly either – neither for consumers, nor for developers.

Will we see a broad migration from passwords to passkeys?

Mainstream adoption of passkeys depends on two questions: First: will passkeys be broadly available? And second: will users actually be willing to use them?

In terms of availability, we need both service-side and client-side support. For the service providers (social media, online shops, email providers, …) it is relatively straight-forward: just pull in a WebAuthn library, consider all my discussions above, and don’t forget to get the recovery process right. On the client-side big vendors such as Microsoft, Google and Apple are finally making a push. But even they have more work to do: the reality of syncable credentials is still very much open. It is unclear if and how third-party services (such as today’s password managers) can hook into the client and sync passkeys.

And when everything is ready, all my favourite services, and even my obscure Linux distro and my smart TV support FIDO – will users adopt it? The UX of passkeys is remarkably similar to the UX of using a password manager:

• One click to generate a new password/passkey.
• One click to auto-fill an existing password/use the passkey.
• Various features to list and manage all your passwords/keys.

Yet password managers have not taken off. If we as security professionals could never provide enough incentives to convince the broad public to use password managers – how will we be able to convince them to adopt passkey managers? How will we convince someone with an Apple iPad, a Windows laptop and an Android phone that passkeys are easier and faster than passwords?

Conclusion

Are passwords bad? Yes. Is FIDO the solution? (Some of) the industry definitely thinks so.

In reality however we are still a long way away. Even Google admits that “passwords will continue to be part of our lives” for a while. There are a lot of challenges yet to be solved.

This all sounds very pessimistic, but it shouldn’t. I am excited about replacing passwords. I am excited to see cryptography being applied to solve a real everyday problem. And I do want to be able to use my YubiKey on more than just 10 out of 200 accounts.

Apple has a history of pushing things forward, simply by adopting something and everybody else following suit. And with Microsoft and Google on board as well, there is a good chance that they can bridge the chicken-and-egg problem: website don’t offer FIDO because there is poor client support, and clients don’t offer FIDO because it is not a feature that is widely requested among websites.

For us computer scientists and engineers there are a lot of interesting challenges ahead. Naming, discussing and understanding the good things as well as the bad things, the opportunities as well as the weaknesses, is key to tackling these challenges.

Please let me know if you found this useful, have any comments, found an error, or outright disagree with me – I would love to hear your opinion!