Building Windows Offline
When our customers came to us with a desire to support offline multi-factor authentication for Windows, we started off by focusing on the fundamental technical problem to be solved. How can we trust enrollment and continued authentication from a device that is offline?
Fortunately, we were not starting from the ground floor. We already had a broadly-used framework of Windows Logon to build upon. Windows Logon is our third most installed application integration with the eighth most users. Windows Logon relies upon the credential provider framework. By relying on an existing Microsoft Windows framework, it helps both our development team and our customers in terms of supportability.
Offline Enrollment
One of the first decisions we made was requiring an initial online authentication to prove the user’s identity before allowing an offline authentication. This paradigm correlates with our requirement for enrollment within the Duo Prompt, where we require an authentication (via Duo Push, Universal 2nd Factor or U2F, passcode, etc.) prior to allowing end users to add a new device or manage other authentication methods.
Our First Authentication Method
We looked at a number of authentication methods to support offline in conjunction with the Duo Labs R&D team. Duo Push was untenable because that requires either the Apple Push Notification Service (APNS) or Google Play services to speak to our service and request an authentication. Since that laptop or desktop is offline, there’s nothing that can invoke a call out to the internet to start that process. There is the same limitation with phone callback or SMS-based passcodes, since there’s not an initial step from the laptop or desktop to start authentication.
We also looked at proximity-based authentication via technologies like Bluetooth or Wi-Fi, but came to the conclusion that there were too many variables outside of our immediate control associated with these types of technologies. For example, with Bluetooth, although it’s ubiquitously available on laptops and desktops at this point, the pairing process for a mobile device to a Windows 7, 8.1 or 10 device is challenging. And it’s a user experience that Duo couldn’t meaningfully improve.
Wi-Fi-based proximity had too many variables over signal maintenance and quality - especially for cases in which the user is flying on a plane. That’s not even mentioning the variable of the smartphones that customers use, where we see well over 200 different types of Android devices with minor or major differences in settings, operating system versions and UX.
Not only did we have the benefit of an existing Windows Logon integration, we also had Duo Mobile widely used by millions of users. While Duo Mobile could not support us with push notifications due to the offline device requirement, Duo Mobile also supports one-time passcode (OTP) token storage. We could create an enrollment event using a QR code, similar to how we enroll applications into Duo Mobile, by which we can use Duo Mobile to share secrets from the laptop to create an OTP token. As this is a completely separate enrollment from the online Duo credential, even in a worst-case scenario in which that device was compromised, the lost secret would only be for that local login to that endpoint.
Why Security Keys?
Customers told us that they also needed to be able to use hardware tokens for offline MFA, for a number of reasons:
- For users that may choose not to use their mobile device for work authentication
- For users that won’t have access to their mobile device due to rules at company sites or restrictions around on-site vendor visits
Initially, we went to the existing D-100 tokens that we sell. This is a common solution set for legacy authentication tools in the marketplace. But there were a number of downsides to using these traditional keys. For one, we would need a mechanism to share OTP seeds stored in our Duo online database to the local laptop or computer. If that local OTP seed was stolen or used, then that token would be compromised and worthless for any other purposes.
With Duo Mobile, we were creating an enrollment event through a QR code communications mechanism. D-100s and other hardware tokens don’t have any sort of interface with a computer. This was a security challenge without a good solution that would require a potentially risky mechanism for user enrollment. Second, our customers have been loud and clear about the fact that the hardware token authentication experience from other products is what made them switch to Duo.
We wanted to help customers with a hardware token solution, but we needed a stronger solution. One that had stronger security properties and made security easy for end users.
Here at Duo, we are strong advocates of FIDO security keys and have deployed them broadly. First of all, the U2F token guarantees user presence at point of login because of the capacitive touch step. Secondarily, because the U2F standard relies upon asymmetric cryptography like Duo Mobile, it means that we limit the risks stated above in regards to leaked seeds. The private key is stored on the hardware itself and only a unique public key is shared with the endpoint.
In the worst case of a compromised endpoint, all that is lost is the multi-factor credential unique to that local login, similar to our solution using Duo Mobile. For example, if the same security key is used for local offline login and online login, those two credentials are separate, so losing the offline credential would not constitute a loss of the online credential.
Finally, and just as importantly, it’s a much better user experience. Instead of typing in a multi-digit code that rotates through, all the user needs to do is tap the capacitive touch token.
The combination of stronger security properties and a better user experience is part and parcel to how Duo approaches and develops solutions to customer problems. Plus, it helped that we validated the solution with the 40 customers that we were working with throughout the beta. Many of these customers in banking, energy, medicine and technology were, in fact, in the process of trialing security keys and used this opportunity to test them for more use cases.
Storing Local Seeds
When the endpoint is able to reach out to our service, we can deal with the challenge of securing seeds within our cloud infrastructure. Since this is the first product we’ve released that will be offline at the point of authentication, we needed to develop a mechanism to store offline MFA credentials on the endpoint.
Luckily, endpoints have become increasingly secure over time. Ever since fall 2015, all Intel-based Windows devices ship with a Trusted Platform Module (TPM). The TPM provides a tamper-proof storage mechanism for encryption keys. Windows 10 provides APIs for relying on the TPM for encryption, so we used it to encrypt the credentials that are stored in the registry for local access. By design, software is not able to save arbitrary data to the TPM, so we weren’t able to store the seeds in the TPM.
In enterprise environments, we know that hardware refreshes take a few years. So for devices that do not contain a TPM, we are using Windows software encryption to write the encrypted key in the registry.
With security keys, a unique benefit is that the private key is embedded on the security key hardware itself and not shared with the endpoint. All that is stored locally is the unique public key to facilitate verification of the U2F token response.
Other Configurations
We thought we’d use this opportunity to share lessons from working with 40 customers during the beta timeframe in regards to securing local Windows endpoints. The first recommendation we heard from our customers is to start by encrypting the hard drive. Bitlocker is the built-in Microsoft solution for hard drive encryption, but there are also third-party solutions that customers will choose to leverage. Encrypting the hard drive has the added benefit of restricting safe mode access for savvy users that are attempting to work around credential providers like Windows Logon.
The second lesson is around managing administrative permissions by disabling administrative rights. Many customers went a step beyond that and leveraged Privileged Identity Management tools like CyberArk, which is a Duo Select Partner, to manage temporary permissions escalations.
Finally, security keys come in a number of form factors. Yubico provides keys that can be left embedded in the device in the nano form factor as well as the more standard key fob-sized devices. Our customers were split as to which form factor they would choose to use, and it depends on your reading of NIST 800-53’s definition of multi-factor authentication.
Some customers interpret it as stating that the authenticator for MFA must be completely separate from the access device, so they’ve chosen to use the key fobs that users will need to plug in and pull out. Other customers view that as long as they are distinct devices, it’s acceptable to use the nano form factors that stay in the device.
Ultimately, it is our view that customers are positioned to choose the types of devices that best fit their particular risk profile and use case. Some customers choose to support only Duo Mobile, others choose to only allow security keys, and the majority will offer both as options. We leave the choice up to you.
Summary
We started this project because customers had a problem: securing access for an increasingly mobile workforce that isn’t always connected to the internet.
The journey to delivering Windows Offline began just about a year ago today and would not have been possible without contributions across the entire organization.
It started with our Duo Labs R&D team and Windows Engineering teams, then grew to include the Product Design and Mobile Engineering teams. Then we expanded to work with our 40 beta customers for input and feedback from the initial front-end designs and architectures to the first piece of beta software.
We want to thank everybody that made this feature possible and look forward to your continued use and feedback. Looking forward to the next evolution of Windows Logon, we are planning on adding support for Security Key authentication when the device is online.