Okta has experienced strong growth in the enterprise market, with many customers drawn to the promise of protecting their workforce with phishing-resistant authentication. 

Okta FastPass is the fastest growing authentication method in Okta Workforce Identity. Our goal is for FastPass to be the most secure, usable, and deployable enterprise authenticator, and we are committed to maintaining a leadership position in protecting against the evolving threat landscape. 

Okta FastPass delivers a simple passwordless user experience, including zero or one-touch biometric authentication on all major operating system platforms. Okta secures this experience with device-bound, phishing-resistant authentication and device posture enforcement.

As more organizations go passwordless, Okta FastPass has benefited from the research of red teams commissioned by these customers to put the claimed security properties of FastPass to the test. Okta has also benefited from testing conducted by hundreds of researchers via a public bug bounty program. The Okta Verify client has been in scope for rewards for several years, with the FastPass method added in October 2023.

One of the reasons Okta offers public bug bounties is because very often, security research is a driver of product innovation. 

In this blog post, we summarize close to two years of FastPass innovations, many of which were driven by internal reviews conducted by Okta’s internal Product Security team, testing conducted by customer red teams, and from independent security researchers contributing to Okta’s public bug bounty programs.

The goal throughout this journey has been to narrow the range of opportunities for an adversary that targets a user protected by FastPass.

Most research falls into one of the following categories: 

• Bypassing Enforcement of Phishing Resistance,

• Attacking Factor Enrollment and Recovery;

• Bypassing User Verification;

• Local Attacks on a Previously Compromised Device.

Bypassing Phishing Resistance

The most popular phishing-resistant method of user sign-in requires an authenticator that won’t issue credentials to any other site than a trusted origin established during user enrollment. 

Using Okta FastPass, a user’s credential is cryptographically bound to a specific Okta Org (tenant). This binding mitigates the most common means by which user credentials get stolen: when users are tricked into sharing them via a malicious phishing site or some other form of social engineering. 

As this 2022 deep dive on Okta FastPass explains, the methods (or probing schemes) by which any given operating system (Android, iOS, MacOS and Windows) can support phishing resistance varies. Okta’s first engineering challenge was how to deliver a consistent, phishing-resistant experience on all four major OS platforms and browsers. 

Some of the most useful early research into FastPass identified how an attacker might exploit scenarios in which a probing scheme that supports phishing resistance would fall back to a scheme that doesn’t. 

To trigger these conditions, attackers typically required human interaction: that is, these conditions could only be exploited if the attacker first convinced a user to perform a desired action.

In response, Okta introduced a policy configuration option that would only allow authentication requests from phishing-resistant flows and deny all others (see below).  

Today, claims that phishing resistance can be “bypassed” tend to rely on a customer configuration in which phishing resistance is not enforced in policy.

Attacking Factor Enrollment and Recovery

The phishing resistance offered by FastPass eliminates the threat posed by a huge range of credential-based attacks. Naturally, we have observed security research shift to targeting enrollment and recovery flows, where phishing resistance cannot as easily be guaranteed. 

The fundamental problem to solve was that the methods by which most users would verify their identity before enrolling a phishing-resistant factor were not themselves phishing resistant. This could be described as a “chicken and egg” problem.  

At first, Okta solved this by requiring two factors of authentication to verify a user identity before enrolling another factor. With this step in place, adversaries would need to achieve a lot within the space of a few minutes: 

• Convince a target to start (but not complete) a FastPass enrolment process, 

• Convince the target to share their Okta credentials (or obtain credentials by other means, such as credential stuffing or phishing), 

• Start their own FastPass enrollment (on an adversary device), and then 

• Convince the target to accept a Push notification issued or share an OTP initiated by the attacker. 

This set the bar for interaction with the target very high, but we could foresee scenarios in which voice calls or instant messaging services could be utilized to make the attack effective. Some customers used a combination of MFA enrolment policies and Workflows to account for these risks. Once again, ongoing security research drove Okta to further harden our enrollment process.

Okta administrators can now make use of several phishing-resistant factor enrollment policy options. These include an ability to exclude low assurance factors from enrollment flows, or to require verification of a user’s identity via a phishing resistant factor before the user can enroll in any other new factor. 

Additionally, organizations can now pre-enroll users in roaming FIDO2 security keys via Okta’s integration with Yubico, and can also use features in which FastPass can be installed on a new device if it is within physical proximity of an existing registered device. 

Bypassing User Verification

One reason signing in with FastPass is so “fast” is because the cryptographic relationship between a user device and the Okta service established at enrollment counts as a possession factor in an authentication flow. 

If the user can efficiently verify their identity to the device using an inherence factor (biometric) or knowledge factor (device passcode or PIN), they can subsequently satisfy two passwordless factors in 2-3 seconds.

Distinct from the conversation about whether an authentication method is phishing resistant, we must also account for how the user validates their identity to their device. User verification checks protect against local attacks in which an adversary gains physical access to a target’s device. If, for example, a user in a shared office doesn’t lock their device, and leaves it unattended, there needs to be a means of preventing a colleague from accessing resources on the absent user's behalf from the unattended device.

The focus for security researchers has been how to force a user verification process to fallback from a biometric challenge to a verification method an attacker could more easily defeat. 

To account for this, Okta’s policy engine considers FastPass as only a single (possession) factor of authentication if a biometric check fails or is abandoned by the user.

Okta administrators can decide what methods of user verification meet their requirements for any given application. Authentication policies can be configured to require biometrics only, a choice of biometrics or PIN/passcodes, or to make user verification optional.

Local Attacks on Compromised Devices

Over two years in the market, security research (and the ongoing efforts of Okta’s engineering teams) have effectively isolated opportunities to attack FastPass down to a final remaining category: the abuse of a FastPass from a malware-compromised user device.

There are many perspectives on what role an Identity Provider can play in this scenario. 

To be clear: Okta is not an endpoint security company, meaning there are limits to what an authenticator can do in the context of a compromised device.

The same applies to FIDO2 authenticators, which offer similar qualities as FastPass. The specifications for FIDO2 (and its predecessors) state clearly that the security claims of phishing-resistant authentication should not be expected to withstand a malware-compromised host.  

The applications involved in a FIDO operation can be relied on as “trustworthy agents of the user”, the alliance says, up until the point of malicious computation on the user’s device.

“Malicious code privileged at the level of the trusted computing base can always violate [FIDO 2 security properties]”.

Arguably, if your authentication method can isolate attacker opportunities down to the compromise of a user endpoint, defenders are winning!

But that’s not to say we shouldn’t all aim higher. At Okta, we love a challenge. This is an area where, once again, our response to security research is driving innovation in Okta products. 

Today, Okta’s policy engine gives administrators the ability to restrict access to any given resource based on whether a device is registered, managed and/or demonstrating compliance with a security baseline.

In the early days of testing these device management features, Okta’s internal testing revealed that a user with root access to a managed device could remove and transfer its non-hardware bound certificate to an unmanaged device. Similarly, session identifiers used to identify whether a mobile device was managed could also be accessed and replayed from an unmanaged device.

Addressing these issues inspired several features that further expanded FastPass capabilities, including:

• Device Assurance checks for “jailbroken” or “rooted” devices. Today, Okta Identity Engine administrators can write policies that approve or deny access to a resource based on these checks. These checks are performed by FastPass.

• FastPass Silent Context Rechecks, through which a user session is terminated if a user accesses an application from a new device mid-session (assuming device context is evaluated in the authentication policy for that app.)

Our next challenge is to ensure that FastPass can’t be invoked by malware running in a user context on a device.

To date, Okta’s response has included:

• EDR/XDR Integrations allow FastPass to check the security posture of an endpoint as evaluated by the customer’s choice of endpoint security tools at the point of authentication.

• Trusted App Filters: an ability for administrators to allowlist a specific binary that is authorized to call the Okta Verify client.

• Okta Verify also includes self-tampering protection on supported platforms, to prevent reverse engineering and unauthorized modifications of Okta FastPass. 

Okta's North Star is to ensure malware cannot compromise FastPass authentication without root access to the device.  

Anticipating future attacks against FastPass

Okta has made great progress on hardening FastPass in a relatively short period of time using threat-informed product development. We are very grateful to the security researchers inside and out of Okta for helping get it there.

Still, we know threat actors will continue to innovate. Okta will continue to strive to compress the feedback loop between security research and product innovation.

Given recent investments Okta has made to constrain session tokens and API tokens (by client or location), it’s prudent to anticipate that adversaries will see a need to again pivot to malware-based attacks.

We hope this short history of FastPass hardening illustrates Okta’s determination to bring best-in-class security to phishing resistant, passwordless authentication.