State of emergency

On May 7, 2021, the DarkSide, a hacking group likely based in Eastern Europe, installed ransomware on the computers of Colonial Pipeline, the largest pipeline for refined oil in the United States. Fearing an attack on its control systems, Colonial shutdown operations, thereby depriving the Southeastern United States of its main fuel supply. Service stations started running out of gas. A week after the attack began, close to 90% of the stations in the nation’s capital were empty. President Joe Biden declared a state of emergency.

In response to this crisis, President Biden issued Executive Order 14028 for “Improving the Nation’s Cybersecurity.” The order specifically calls out the importance of multi-factor authentication (MFA). One of the main culprits in the ransomware attack was the lack of MFA in Colonial’s IT infrastructure. The President’s order called for the implementation of MFA by organizations that work with the federal government.

Okta releases Desktop MFA

The government has not been the only voice calling for MFA. More insurance companies are requiring MFA for all network access and workstation access. Likewise, IT administrators increasingly recognize that stolen laptops can represent a significant security risk. In the case of the Colonial attack, a re-used password taken from an entirely separate security breach allowed the attackers access to a Colonial VPN. The same password reused on a stolen laptop could be devastating.

To help customers address these urgent security and compliance use cases, Okta has released Desktop MFA as part of its Okta Device Access offering. Desktop MFA requires that a user present a second factor for authentication when signing on to their desktop machine. The software is easily deployed and provides a friendly user enrollment process. Most significantly, the humble password is no longer the only line of defense for corporate devices.

Admin deployment

Okta Admin console

An administrator can deploy Desktop MFA in a matter of minutes. In the Okta Admin console, they choose the Desktop MFA app from the Application Catalog and configure it as they would any other OpenID Connect (OIDC) application.

Desktop MFA is only available for managed devices. Admins should deploy the software to an end-user’s device through a Mobile Device Management (MDM) along with an MDM profile.

Policies

Okta provides the admin with fine-grained controls over the behavior of Desktop MFA via the MDM profile deployed to the user device. Admins can access a number of configuration policies, including the following:

• Grace period during which the user can skip enrollment after MDM deployment
• Period during which the user can rely on offline factors alone (e.g. a user might go 48 hours without an online authentication)
• Factors that allow for authentication (more on this below)
• How to restrict access to online factors

The complete list of available policies can be found in our documentation for Windows and macOS.

User experience

Prerequisite: online factor enrolled with Okta Verify

In order to use Desktop MFA, the user must have an Okta account within their organization’s Okta tenant. Prior to enrollment on their desktop, they must enroll a second factor (such as Okta Verify push). After the user has done this, they are ready for enrollment.

Enrollment for Desktop MFA

After Desktop MFA has been deployed to a user’s device, the user will be prompted to enroll. On macOS, for example, the user will see the following screen.

On both platforms, the user can opt to skip enrollment for a limited period of time. However, once that grace period has ended, they will no longer have access to their machine until they enroll.

The enrollment process is straightforward. The user begins by creating an “offline” factor using the Okta Verify app. Then, they use Oka Verify to scan a QR code presented to them during the enrollment process. 

On Windows, for example, the user would be prompted to scan the code as shown:
 

Scanning the code sets up a new account on the Okta Verify app on their phone. That account shows a device access code (a temporary one-time password) that they can use as a second factor without being connected to the internet (hence the term “offline” factor).

User sign-on

Users log in to their machines as they normally do by presenting their username and password. In the case of macOS, the credentials are immediately checked by the operating system. Next, the user is prompted to enter a second factor of their choosing. 

If they choose Okta Verify push, they will be prompted to send a push notification to their phone.

Once they confirm the push, Okta will quickly tell their machine that the second factor has been verified. In the case of macOS, both factors will be confirmed and the user will be granted access. For Windows users, their username and password entered earlier will be verified by Active Directory before access is granted.

Factors

As mentioned above, Desktop MFA supports two broad classes of factors: online factors, which require an internet connection, and offline factors, which do not. Both platforms support temporary one-time passwords (TOTP) as an offline factor and Windows additionally supports an offline security key (such as Yubikey). For online factors, both platforms support Okta Verify push and TOTP and macOS also supports FIDO2 Yubikey.

A user can authenticate with an offline factor even if they don’t have an internet connection. This is crucial for all users because even in our highly connected world, internet connectivity is not guaranteed everywhere. We don’t want a business traveler, for example, to be unable to use their computer simply because they’re on a plane without internet access.

That said, we do require that users periodically authenticate with an online factor. Requiring online factors adds that additional layer of security that is valuable to system administrators. Online factors put a time limit on access to a corporate laptop. Once the user is deprovisioned, access to their laptop will cease as soon as they are prompted to reauthenticate (which can be as short a period as the admin desires). A laptop that doesn’t get returned becomes much less of a vulnerability.

Admins also have the ability to restrict which factors are available. For example, they can require online factors only. Or, they can limit which factors can be used (e.g. only FIDO2 Yubikey is allowed as an online factor). Specifying which factors are allowed is currently available on macOS and will be available on Windows in the near future.

Sign-on flows

The following diagram captures the flow for authentication using an online factor.
 

The process is similar, albeit somewhat simpler, for authentication using an offline factor.

Passwordless on Windows

Windows users also have a passwordless option.

Under the hood

On Windows, Desktop MFA is built using the Credential Provider framework. The Credential Provider architecture allows us to define user interface elements that the LogonUI.exe process displays to the user. Our custom Credential Provider receives factor input from the user and then communicates that information to another Okta process on the machine. That background process then validates the input locally or with the Okta back end.

macOS authenticates users with a pipeline model and allows for custom code to be injected into that pipeline using Apple’s Authorization Plugin framework. We wrote our own authorization plugin mechanisms and placed our custom code to run after the operating system prompts for username and password. The placement of custom code within the authorization pipeline is done by updating Apple’s security database.

Conclusion

For Colonial Pipeline, all it took was an orphaned account with a compromised password for a security nightmare to begin. The Colonial attack vividly demonstrates the need for layered security. Okta Device Access is a powerful, configurable way to add that additional layer. Admins can use Desktop MFA to enforce strong security hygiene among their users; that stolen laptop halts the thief with a second factor. Additionally, organizations that are concerned about compliance with federal regulations or renewal of their cybersecurity insurance policies can consider Desktop MFA.

Desktop MFA is a platform in which Okta is continuously innovating. In the near future, we look forward to releasing more innovative tools. This will provide true single sign-on from the moment the user logs into their device.  Learn more about Okta Device Access. 

This blog and any recommendations within are not legal, privacy, security, compliance, or business advice. This blog intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials.