A vision for Passkeys on the Linux desktop

31st January 2024

 

Introduction

Passwords are a scourge on the modern web, a relic of another time. I’m an advocate of FIDO2 and WebAuthn, and I believe that they will play a crucial role in the future of authentication. I’m excited to see the industry move towards more secure and user-friendly alternatives such as Passkeys.

However, the Linux desktop has lagged behind other platforms in adopting these technologies. I launched xdg-credentials-portal in 2020 with the goal of bringing FIDO2 authentication to the Linux desktop.

In this post I’ll discuss my vision for FIDO2 on Linux, and the main challenges that lie ahead.

A bit of history

Skip this section if you’re familiar with FIDO2, WebAuthn, and the limitations surrounding their use in Flatpak apps.

FIDO Universal Second Factor (FIDO U2F)

FIDO Universal Second Factor (U2F) was the first, widely-adopted open standard for two-factor authentication (2FA) on the web.

This allowed users to authenticate to websites using a physical security key, in addition to their password. The security key could be connected via USB, NFC, or Bluetooth Low Energy (BLE).

FIDO2 and Passkeys

FIDO2 builds on the success of U2F. It improves upon the original spec in a number of ways. Although it still supports the original use cases of U2F, its main focus is on enabling passwordless authentication scenarios - using a private-key credential as the sole factor for authentication.

FIDO2 comprises of two specifications:

The FIDO Alliance has selected the term Passkeys to describe the public-key credentials which can be used through these APIs. It’s worth noting the specs predate the term passkey, and use different terminology to refer to credentials.

For more details on Passkeys, see:

The advancements in the specs above which power the passkey experience are the following:

  1. CTAP2 Hybrid Transport, previosuly known as Cloud-assisted Bluetooth Low Energy (caBLE v2). This transport builds on BLE - allowing for secure pairing, and proximity detection - but adds a standardised, and more convenient internet-based transport for subsequent communication. This allows phones to receive energy-efficient push notifications, rather than relying on slower, and occasionally less reliable, BLE.

  2. WebAuthn Discoverable credentials, previously known as Resident keys. This allows credentials to be stored on the authenticator or client, rather than by the relying party (ie. the website).

  3. Multi-device FIDO Credentials. This is a relaxation of the requirements on authenticator devices which no longer need to store private keys in Trusted Platform Modules (TPMs). Because of this, software implementations of authenticators can backup credentials to the cloud, as well as sync them across multiple devices.

Linux and Containerisation

Containerisation technology such as Flatpak and Snap have become increasingly popular on Linux. Containerisation promises to make software distribution easier, and more secure, by isolating applications from the host system.

However, in order to reap the security benefits, software must be distributed with the minimum set of permissions required to function. This is a challenge for software which requires access to sensitive resources, such as the user’s USB security keys.

To allow a Flatpak application to access a USB security key, the user must grant the application access to all devices (see Flatpak device access docs). This has two major security drawbacks:

  1. It allows the application to access all USB devices on the system, not just the security key.
  2. The application communicates with the security key directly, which allows it to bypass origin scoping: an application can use credentials for any website.

See flatpak/xdg-desktop-portal issue 989 for more details and discussion.

A vision for FIDO2 on Linux

This sections sets out a vision for FIDO2 on Linux, and discusses the challenges that lie ahead.

Prioritizing Passkey support

Passkeys are likely to be the most popular form of FIDO2 authentication by far. The convenience of passkeys being automatically synced across devices, and the fact that they don’t require specialised hardware, will make them the go-to choice for the vast majority of users.

For this reason, I believe that it’s crucial to prioritize passkey support. This means focusing on the CTAP2 Hybrid Transport, and the WebAuthn Discoverable Credentials, above other transports (eg. USB, NFC, etc).

Mozilla’s authenticator-rs currently solely targets USB security keys, and will need significant work to support additional transports such as BLE and Hybrid (CABLE).

Envisioning a Windows Hello experience on Linux

Windows Hello

The goal of xdg-credentials-portal, or any other FIDO2 credentials portal on Linux, should be to provide a user experience similar to:

The responsibilities of this portal should include:

Bridging FIDO2 with Password Providers

Most users are likely to use Google Password Manager or iCloud to store their Passkeys. Others will prefer third-party password manages with support for passkeys such as BitWarden, Lastpass, and so on. Novel products with even better security guarantees will inevitably appeal to privacy-savy users.

The Linux desktop should allow users to choose their preferred password managers, and use passkeys created on other devices.

This is the same approach chosen for Android’s Credential Manager APIs - whenever an application requests the user to authentication, the platform is responsible for querying all registered providers and collect available passkeys. The user will then be presented with a dialog to choose their preferred credential amongst all those available.

Android enumerating Passkeys

The application requesting authentication should not have visibility as to which providers are configured, or the origin of the selected passkey.

This will require defining an interface between the Linux desktop component and pluggable providers, similar to the Android Credential Provider APIs. This interface is necessarily more complex that the WebAuthn and CTAP specs, as it includes enumerating and discovering credentials.

Delegating Passkeys to the platform

Applications, especially browsers, tend to come with their own implementation of passkey management. This is a problem for a number of reasons:

  1. It couples password managers to specific applications. For example, Google Password Manager is only available in Chrome.
  2. It’s a security risk. Applications accessing specialised hardware directly may not be as secure as the platform, and may leak credentials to the application developer, or to other websites and applications.
  3. It’s a poor user experience. Users are forced to reauthenticate to each application, and to reconfigure their password manager for each application.

If history is any indication, Google may refuse to provide a Google Password Manager integration outside of the Chrome browser, and Apple may refuse to provide any iCloud integrations outside of its own operating systems.

FOSS groups should insist on a platform-level integration, and participate in adequate forums to ensure that their voices are heard.

Both Chrome and Firefox already delegate password management to the platform on Windows and macOS. Both browser vendors should be engaged to ensure that they do the same on Linux.

My limited attempts to engage with Mozilla on this issue have not proven successful so far. Google have informally indicated they are open to delegating FIDO2 to the platform.

The challenge of origin scoping

The WebAuthn spec requires that credentials are scoped to the origin of the website. This means that a credential created for https://example.com cannot be used by https://example.org. This is a crucial security guarantee, as it prevents a compromised or malicious website from using credentials to impersonate the user on other websites.

As Linux desktop applications request access to credentials, they must be forbidden from accessing credentials belonging to other applications. Two challenges need to be solved for this enforcement to occur: identifying allowed origins for an app, and authenticating the app.

Identifying allowed origins

Two modes of operation can be identified when accessing WebAuthn credentials:

  1. Restricted scope, for most applications that are allowed access to credentials scoped to their respective origin. User interaction is only required for verification purposes, or selecting between credentials when multiple exist.
  2. Privileged access, for applications that act on behalf of other origins, such as web browsers and remote desktop applications. An additional user interaction step must be required to validate the application should be able to access credentials for the specific origin.

Privileged access

Privileged access scenarios is the easiest mode to implement without compromising credential security - although this may sound counter intuitive at first.

The choice of allowing the web browser to access a specific credential can be given to the user, who should be able to easily identify whether the request is legitimate. I propose including user interaction in two key flows:

  1. Granting privileged access at install time. The user acknowledges the privileged status of the app, for example by granting a “permission to access credentials for all apps and websites” - or other wording to the same effect;
  2. Granting access to the specific origin. The platform requires the user to mediate access to credentials, explicitly indicating which origin the credential belongs to, for example: “Firefox is trying to use a credential for https://example.org.”. The user may choose for this preference to be remembered, ie. “Always allow for this website”.

A relevant example is provided by the Android FIDO2 APIs. On Android, different subsets of these APIs are available to privileged (Fido2PrivilegedApiClient) and non-privileged applications (Fido2ApiClient). Only applications that have the necessary web browser permissions can access the privileged APIs. Google reviews applications declaring this permission to verify they are indeed web browsers, before allowing them to be listed on Google Play Store. This solution effectively delegate trust to the distribution platform, which may not be desirable on the Linux desktop.

Restricted scope

In order to use the requirement for the user to validate the scope of the request, it must be possible to automatically validate an origin for a given application.

A basic approach is that of requiring origin owners to enumerate application identifiers to be allowed access to their credentials. Android employs a manifest published at a well-known URI (.well-known/assetlinks.json) for this very purpose, although DNS could be used as well.

The platform may retrieve the manifest, or perform a DNS query, at the time of the request. However, this has two disadvadvantages:

  1. It doesn’t allow for offline (or limited connectivity) scenarios. This would be quite unfortunate as WebAuthn can be useful in offline scenarios, such as using the PRF extension for symmetric data encryption.
  2. Requests can be tracked. The application owner can determine when the user is using their application, and which origin they are accessing. This may be undesirable for privacy reasons.

These problems can be mitigated by the platform caching the origin validation information. However, this is not a perfect solution, as the application owner can still determine whether the user is using their application, and it doesn’t provide a good user experience for offline scenarios.

A better approach is to delegate the origin validation to the distribution platform. For example, Flathub could validate the allowed origins for a given application, and provide this information to the platform in a way that can be verified cryptographically. This would allow for offline scenarios, and would prevent the application owner from tracking the user.

The downside of this approach is that it requires the distribution platform to be trusted. This may not be desirable for some users, and may be a blocker for some distributions.

It’s unclear to me what approach is used on Android.

Avoiding the good-enough trap

A privileged mode is the easiest to implement, and may be good enough for many use cases. However, it’s important to ensure that a restricted mode is not forgotten, and that it’s implemented as soon as possible.

I fear that if the privileged mode is implemented first, applications that do not require privileged access may never be updated to use the restricted mode. This would be a major setback for the security of FIDO2 on Linux.

Authenticating the app

The solutions proposed in the section above assumes that the user can be presented with a dialog that includes the origin of the credential, and the application requesting access to it, e.g.:

Firefox is trying to use a credential for https://example.org

This requires the platform to be able to authenticate the application, and to verify that the application is indeed the one requesting access to the credential.

On Android, each application has a unique identifier and a signing key. FIDO2 requests are signed by the application, and the platform can verify that the application requesting access to the credential is indeed the one that created it, and that it’s not a malicious application impersonating the original one.

On Linux, this may be trickier to implement. D-Bus requests are not signed but may it may be possible to trace them back to the process that created them (eg. via GetConnectionUnixProcessID).

It would then be necessary to map the process ID to the Flatpak application, and in turn to the list of allowed origins (or a privileged status). This may be possible via existing Flatpak APIs, or by extending them.

What next?

Development for xdg-credentials-portal has been slow, partly because of the changing nature of the FIDO2 specs. However, I’m optimistic about the future of FIDO2 on Linux. FOSS groups have a strong track record of collaborating to solve complex problems, and for-profit contributors are bound to emerge as the technology becomes more popular.

If you’re interested in the cause, but you’re unsure where to start, please get in touch.

Engaging with the FIDO Alliance, Mozilla, Google, the GNOME Foundation, and other stakeholders is going to be crucial to ensure that the Linux desktop is not left behind. If you represent an organisation that may be interested in contributing to this effort, please consider reaching out to me, and I’d be happy to help you get started and connect you with the right people.

Feedback

If you have any feedback, please reach out to me on GitHub, LinkedIn, or via e-mail.