Twitter has a fascinating blog post describing transitioning all of their employees to YubiKey FIDO hardware keys for multi-factor authentication for internal systems. This is especially interesting because Twitter deprecated other 2FA systems for employees–the YubiKey devices are the only valid 2FA method deployed by the company.
Flipping the Switch. Our final step was to disable legacy 2FA methods and mandate the use of security keys across our internal systems. We set a cutover date, which was shared with the entire company a month in advance. We reached ~90% security key enrollment by the deadline and were able to hit 100% within a month of cutting over, as folks returned from vacation or leave.
Twitter also has some good observations about ways the current security key experience can be improved.
– Key Rotation/Replacement. Today, replacing a security key is a significant usability challenge, requiring users to keep track of every service they’ve registered a security key with and individually visit each service, remove the old key, and add the new key. At Twitter, we issued all employees two keys to start, one primary and one backup. This ensures a fallback option in the event that the primary key is lost. We also used SSO to minimize the number of systems on which a user needs to register their keys. But we wish there were better ways to help users add and remove security keys across services. While there are efforts underway to simplify registering backup security keys, it’s still difficult for users to track where they have registered a specific security key or to replace keys when necessary. This remains an open challenge.
– Security Key UX. The usability of WebAuthn interfaces is key to their wider adoption. Services that support security keys should provide basic features like the ability to rename keys to make it easier for users to differentiate them. We’ve also found it helpful when platforms allow users to specify their default 2FA method so that users don’t have to click around to use their security key on each login.
Cloudflare is testing a system to allow users to use FIDO keys to skip CAPTCHAs.
From a user perspective, a Cryptographic Attestation of Personhood works as follows:
1. The user accesses a website protected by Cryptographic Attestation of Personhood, such as cloudflarechallenge.com.
2. Cloudflare serves a challenge.
3. The user clicks I am human (beta) and gets prompted for a security device.
4. User decides to use a Hardware Security Key.
5. The user plugs the device into their computer or taps it to their phone for wireless signature (using NFC).
6. A cryptographic attestation is sent to Cloudflare, which allows the user in upon verification of the user presence test.
Completing this flow takes five seconds. More importantly, this challenge protects users’ privacy since the attestation is not uniquely linked to the user device. All device manufacturers trusted by Cloudflare are part of the FIDO Alliance. As such, each hardware key shares its identifier with other keys manufactured in the same batch (see Universal 2nd Factor Overview, Section 8). From Cloudflare’s perspective, your key looks like all other keys in the batch.
Cloudflare says it is primarily interested in reducing the amount of time users spend on CAPTCHAs, which it estimates currently take up 500 years of user time every day.
CAPTCHAs are certainly frustrating, and anything that can be done to replace them while still mitigating brute force and DDOS attacks is great. But it would also be great to see FIDO keys become more accepted and normalized across the Internet.
On January 30, 2020, Google announced it was creating OpenSK, an open source FIDO/U2F implementation, in the hopes of spurring broader research and implementation of the security technology.
Today, FIDO security keys are reshaping the way online accounts are protected by providing an easy, phishing-resistant form of two-factor authentication (2FA) that is trusted by a growing number of websites, including Google, social networks, cloud providers, and many others. To help advance and improve access to FIDO authenticator implementations, we are excited, following other open-source projects like Solo and Somu, to announce the release of OpenSK, an open-source implementation for security keys written in Rust that supports both FIDO U2F and FIDO2 standards.
By opening up OpenSK as a research platform, our hope is that it will be used by researchers, security key manufacturers, and enthusiasts to help develop innovative features and accelerate security key adoption.
Of course after I buy a half-dozen YubiKey 4 keys, the company goes and releases the YubiKey 5 series with FIDO2/WebAuthn support. 🙂
Single-Factor Authentication (Passwordless) with the YubiKey 5 Series – The YubiKey 5 security keys can be used alone for strong single-factor authentication, requiring no username or password to login — just tap or touch to authenticate.
Second-Factor Authentication with the YubiKey 5 Series – Used alongside a username and password, the YubiKey 5 series offers a strong second factor of authentication. This is the YubiKey integration that exists today with services like Google, Twitter, and Facebook, and it is most familiar to our users.
Multi-Factor Authentication (Passwordless + PIN + Touch) with the YubiKey 5 Series – The YubiKey 5 series can be used in conjunction with a PIN for user verification. In this case, the PIN unlocks the device locally and touch is still required for the YubiKey to perform the authentication.
Really looking forward to seeing what the uptake is on the passwordless single-factor authentication turns out to be, especially as Google’s recently released hardware authentication key also supports it.
I had some concerns about physical security with the passwordless authorization, but it appears that users can add a pin to the authentication keys in that setup if desired.