A brief history on authentication
A lot has happened in the world of authentication and security since we first introduced the YubiKey back in 2008. In this blog, we’ll review where we are in the world of open authentication standards, discuss the addition of the ‘passkey’ term, and share what the future holds for modern WebAuthn/FIDO authentication.
Creating a global standard
To bring advanced security to every person and every site, Yubico created Universal Second Factor (U2F) with Google in 2012, and moved it to the FIDO Alliance in 2013 to deliver a global standard that makes the internet safer for all. This standard brought the security of public/private key cryptography in hardware to the masses, and showed it requires little more than a USB device and port, or NFC for mobile, and a website to support it.
We continued to innovate and work with our peers in standards bodies to expand U2F into FIDO2/CTAP2 and W3C WebAuthn. These evolutionary standards support all existing U2F devices, and additionally add the option to support device PIN, biometrics, and authentication technology built into devices like phones and computers, and locally discoverable credentials to enable experiences without usernames or passwords at all.
Where are we now?
Through this work on standards and with platforms, we achieved universal support on all major desktop and mobile platforms – plus or minus a few corner cases that are currently being addressed – to create a solution that delivers phishing-resistant authentication everywhere: WebAuthn/FIDO.
Alternative multi-factor authentication (MFA) solutions like SMS, mobile push notifications, and one-time passwords (OTP) have exploitable technical flaws, or make it trivial for “man-in-the-middle” phishing attacks to trick people. This is exactly what attackers are doing today as MFA mechanisms beyond usernames and passwords become more prevalent.
Industry data says the biggest threats aren’t weaker MFA options, but instead the fact that many organizations and individuals aren’t turning on MFA at all. For example, Twitter says only 2.5% of user accounts on their platform use MFA, and even for enterprises, Microsoft Azure says only 25% of their customers use any kind of MFA. While not all MFA is created equal, everyone should at least use some sort of MFA, and strong, unique passwords created by password managers for every site and application.
The future of modern authentication
We’ve spent years working with the FIDO Alliance, the World Wide Web Consortium (W3C), and platform vendors to further enhance the experiences that are possible with WebAuthn/FIDO and we’re excited about what the future has in store. We will highlight three of these innovations and additions today:
Terminology changes
There are some terms that are changing, and these will hopefully be easier to understand for users and developers alike.
Security Keys
The phrase “Security Key” has already become the standard way to describe an external FIDO-enabled hardware device, such as a YubiKey, that contains WebAuthn/FIDO credentials. However, “WebAuthn/FIDO credential” doesn’t exactly roll off the tongue, and is almost impenetrable for non-experts.
Passkeys
“Passwords” is already a universally understood term. Because these WebAuthn/FIDO credentials can replace passwords, the industry has introduced the term “passkeys,” which was publicly referenced last year in Apple’s ‘passkeys in iCloud Keychain’ presentation and in a recent WIRED article. For the remainder of this post, we’ll use passkeys to refer to any WebAuthn/FIDO credentials, regardless of if they’re on a Security Key, bound to your device’s hardware, or even just stored in files on your device which are copied around by a cloud provider.
As this naming has begun to proliferate, we have received many inquiries from our customers and partners on defining passkeys, how these work as additional authentication options, and what expanding WebAuthn/FIDO authentication options may look like, and we cover this evolving story below.
Bluetooth improvements, and phones as Security Keys
Yubico built a prototype bluetooth authenticator and worked with others to create the first FIDO bluetooth transport. Our ultimate decision was not to ship a production bluetooth YubiKey, and that was based on what we learned during this effort:
- Bluetooth pairing has bad security and usability properties
- Batteries must be charged regularly and carefully to maintain their capacity, or be replaceable, which compromises a device’s robustness and requires replacements to be available exactly at the moment of need
- The bluetooth protocol and hardware implementations are complex, and must be kept up to date to address vulnerabilities that are discovered
- The state of bluetooth hardware, drivers, and OS support is inconsistent, and is unreliable
Our conclusion was that the only devices that make sense to use as bluetooth Security Keys are phones. Phones in particular seem suitable because they:
- almost all have cameras that can be used to ease bluetooth pairing
- are mostly charged carefully and regularly by their owners
- already have mechanisms to update their software and firmware regularly
- are likely to be with the owner much of the time
Phones as authenticators was part of our original vision, and we have been working towards this for a long time. How do we enable biometrics built into phones to be used to authenticate on other devices the same way we enabled them to be used for logging in on the same device with FIDO2? After many years of work in the standards bodies and by the platforms, we think this is almost ready. Camera-assisted bluetooth pairing is now being enabled by major browsers and OSs, the platform bluetooth quirks have been mostly fixed or worked around from years of testing, upgrades, and bug fixes, and the bluetooth+network transport is now well tested.
Here’s what this looks like today on macOS/iOS when enabled (subject to change):
This is exciting, but phones are fragile, expensive, replaced often, and are sometimes prohibited by policy or law from being used. That means the most challenging part of using Security Keys – re-registering them everywhere when they’re lost, or transitioning to a new one – are much more frequent for phones.
Because of this, we recommend a phone be configured as one of several authenticators added to your accounts.
Copyable, multi-device passkeys
To date, credentials created by Security Keys and Platform Authenticators have been single-device, i.e. bound to the hardware they are created on. These are single-device passkeys. They have good security properties and are easy to understand and build trustworthy systems around: no device, no access.
What if we added a credential that can be copied by not binding them to the hardware they were created on? These copyable “multi-device passkeys” are in beta on platforms today.
Copyable credentials can help solve some of the challenges exacerbated by using phones as Security Keys by enabling more seamless device transition and device loss/destruction recovery. However, this comes at the cost of reduced security.
Platforms will accomplish this by using the built-in password manager to copy multi-device passkeys to other devices with the same platform password manager and cloud account:
That means unless phishing resistant authentication is used to protect the account that syncs passkeys, people can still be tricked. Fortunately, phishing this type of sync mechanism must target robust account systems run by platform vendors, and can often optionally be configured in a way that people might notice something is unusual. Unfortunately, people are used to computers being unusual, and very few of these account systems can be configured to use phishing resistant authentication. We hope this situation improves in the future with more providers offering systems that allow only phishing-resistant authentication, like Google’s Advanced Protection Program.
Ultimately, for those who would otherwise use only a password, multi-device passkeys are easy to use, and are a step in the right direction that can reduce overall harm caused by using passwords alone. Because attackers already copy and misuse server or user credentials, websites can also choose to assign different levels of trust to copyable credentials versus those that are hardware bound, as appropriate to their needs.
More authentication options for different needs
We know that not everyone can use the most advanced security in all scenarios, because the world is full of complex technology, and evolving threats. Here’s our take on the tradeoffs as of today:
The YubiKey was created to make stronger authentication available and easy to use for all. That’s why it can act as a WebAuthn/FIDO authenticator, a Smart Card, an OTP device, and much more, all in one device. It’s a robust, affordable “key to many locks” that stays with you as your technology and threats change.
Internet crime is on pace to enable the largest transfer of wealth in human history, so if you’re not yet ready for a YubiKey, please do use more than just a password.
Conclusion
We hope these additional options will help more sites adopt WebAuthn/FIDO. That will benefit everyone regardless of if they’re using copyable, multi-device passkeys, or stronger solutions like YubiKeys, where passkeys are bound to the YubiKey hardware.
More options and more widespread support ultimately allows consumers or enterprises to choose which authentication methods best suit their needs. If you’d like to talk to our sales and solutions teams about what a solution involving YubiKeys might look like for your specific needs, please let us know.
Overall, we’re excited to see the standards we’ve collectively crafted reach so many, and continue to protect against modern threats. Now go turn on MFA everywhere you can!
Footnotes:
1 For logins from the same device. On some phones, early support is available to log in on other devices that support bluetooth, but it also requires an active internet connection from both devices in some current implementations.
2 On the sites where they are used, but the methods for copying them to other devices can be subject to phishing. See 7.
3 Some smartcards, like the OpenPGP Card and PIV implementations in YubiKeys, support attestation. However, smartcard attestation is mostly limited to enterprise use cases and not available to all sites.
4 Support for attestation varies, and some cover a wide range of implementations with varying security properties.
5 If attested, it’s unclear what can be attested about copyable data such as multi-device passkeys.
6 A network connection, a shared password manager implementation, and cloud account are required to sync credentials. See also 1 about using phones with other devices.
7 Systems that allow credentials to be copied can be phished unless YubiKeys or other phishing resistant technologies are the only way to access the copying mechanism.
8 Multiple registered YubiKeys allow easy and secure self recovery. It’s easier to do this with SSO or social login than with many sites.
9 Push apps need network connectivity. OTP apps require validation to be available on the system or app being accessed; typically this means an online network connection to an OTP validation service like YubiCloud, or sacrificing security by copying the shared OTP secret to more places.
