Follow ZDNET: Add us as a favorite source On Google.
ZDNET Highlights
- Passkeys are more secure than passwords for authentication with online accounts.
- Working with Passkey requires an authenticator and other technologies.
- Roaming authenticators may be the most complex – and secure – type of authenticator.
let’s face it. When it comes to passwords, we really are our own worst enemy. Too harsh? I don’t think so. We are doing everything we can to make it easier for threat actors to do their worst – from exfiltrating and distributing our sensitive information to draining our bank accounts. Given how often end-users continue to unwittingly enable these hackers, we’ve practically joined the other side.
In fact, research now shows that, despite receiving some deep and comprehensive cybersecurity training, 98% of us are still being duped by phishers, smishers, quishers, and other threat actors who attempt to trick us into accidentally revealing our secret passwords.
Also: How to Prepare Your Company for a Passwordless Future – in 5 Steps
Realizing that training and education were clearly pointless, the tech industry decided on an alternative approach: eliminate passwords altogether. Instead of a login credential that requires us to input (aka “share”) our secret to an app or website (collectively known as a “trusted party”), how about an industry-wide passwordless standard that still involves a secret, but which never needs to be shared with anyone? Not even legitimate trusted parties, let alone threat actors? In fact, wouldn’t it be great if we, the end users, didn’t even know what that secret was?
In short, this is the basis of Passkey. There are three big ideas behind Passkey:
- They can’t be guessed (just as passwords can be — and often are) guessed.
- The same passkey can’t be reused across different websites and apps (the way passwords can).
- You can’t be tricked into giving away your passkeys to malicious actors (the way passwords can).
Easy peasy, right? Well, not so fast. While 99% of today’s user ID and password workflows are easy to understand, and don’t require any additional purpose-built technology from you to complete the process, the same can’t be said for passkeys.
Like anything cybersecurity related, with a passkey, you have to exchange some convenience for increased security. As I’ve detailed before, that tradeoff is worth it.But that agreement also involves some complexity that will take time to get used to.
Behind the scenes with passkeys
Every time you create a new passkey or use it to log in to a relying party, you’ll be connected to an assortment of technologies – your device’s hardware, the operating system it’s running, the operating system’s native web browser, the relying party, and the authenticator – designed to interoperate with each other to generate an ultimate and hopefully friction-free user experience. Some of these technologies overlap in such a way that the boundaries between them become blurred.
Also: How Passkey Works: The Complete Guide to Your Inevitable Passwordless Future
The word “paskie” is actually a nickname for FIDO Alliance FIDO2 Credential SpecificationWhich itself is essentially a merger of two other open standards: World Wide Web Consortium (W3) WebAuthn standard For web (HTTP) based passwordless authentication with a trusted party FIDO Alliance’s Client-to-Authenticator Protocol (CTAP)As far as the “authenticator” in “Client-to-Authenticator Protocol” is concerned, WebAuth distinguishes between three different types of authenticators: platformVirtual, and roaming.
The topic of this fourth and final part of ZDNET’s series on passkey authenticator technologies is roaming authenticators.
Roaming Authenticator Limitations
As its name suggests, a roaming authenticator is a physical device, such as a USB stick (commonly known as a security key), that can be carried in your pocket. Yubico’s Yubikeys And Google’s Titan There are two common examples of roaming authenticators. However, roaming authenticators can come in the form of other devices, including smartphones and smart cards.
Yubico offers a wide variety of roaming authenticators, most of which vary based on their ability to connect to a device. For example, the YubiKey 5C NFC can be physically connected to a device via USB-C or wirelessly via Near Field Communication (NFC). But roaming authenticators are also small and easy to misplace or misplace, which is why you need at least two – one for backup.
yubiko
Currently, when you use a specific roaming authenticator to support the passkey registration function for a given relying party, the passkey is created and stored in encrypted form on the roaming authenticator in such a way that it cannot be distinguished from the physical device. For this reason, passkeys created with roaming authenticators are considered “device-bound”. In other words, unlike Apple’s iCloud Keychain, the password manager in Google Chrome, and most virtual password managers, a passkey that is created and stored on Roaming Authenticator is also a non-syncable passkey. It cannot be extracted from the underlying hardware, cannot be synchronized to the cloud, and cannot be synced from there to the user’s other devices.
Also: Best Security Keys: Expert Tested
This limitation of roaming authenticators also reflects the current state of affairs with Windows Hello, where users have the option of creating a passkey tied to the underlying Windows system. In such a case, the resulting passkey is cryptographically tied to the system’s security hardware, also known as its Trusted Platform Module (TPM). Every modern system has a cryptographically unique TPM that serves as a hardware-based root of trust to which the passkey and other secrets can be inextricably linked.
With this in mind, a roaming authenticator can, in some ways, be thought of as a roaming root of trust; It is essentially a portable TPM. Whereas a passkey that is tied to a TPM embedded in the circuitry of a computer or mobile device can never be separated from the device, a passkey that is saved to a roaming authenticator is still cryptographically tied to the hardware-based trust root, but can then be shared across multiple devices, allowing the roaming authenticator to be linked. For example, a passkey saved in a USB-based YubiKey can be used to support the passkey-based authentication function on any device into which the YubiKey can be inserted (for example, a desktop computer, smartphone, tablet, or gaming console).
syncable passkey
The main advantage of this approach is that you get the multi-device benefits of a software-based, synchable passkey, without having to save the passkey anywhere other than the roaming authenticator. It is not saved to any of your computing devices, nor does it pass through any online cloud to be synchronized and used from your other devices. Instead of syncing the passkey through the cloud, you simply connect the Roaming Authenticator to a device that needs it for an authentication function with a trusted party.
However, roaming authenticators differ significantly from their platform and virtual counterparts as they do not come packed with any password management capabilities. You can’t save a user ID or password in Roaming Authenticator the same way you can save a passkey in one. This presents a bit of a conundrum because password managers still come in handy for their non-passkey-related capabilities, such as creating unique, complex passwords for each relying party and then automatically filling them into login forms when necessary. If your credential management strategy includes both a password manager and a roaming authenticator, you will basically end up with two authenticators – one virtual (as an integral part of the password manager) and the other roaming, which in turn will require you to decide and then remember which authenticator to use for which relying party.
Also: Syncable vs. Non-Syncable Passkeys: Are Roaming Authenticators the Best of Both Worlds?
Fortunately, there is a clear use case where having a roaming authenticator in addition to the platform or virtual authenticator makes perfect sense. As explained in this report about a recent partnership between Dashlane and Yubico, password managers involve a bit of a paradox: If you need to log into your password manager to log into everything else, how do you log into your password manager?
The best strategy is to do this with a roaming authenticator. After all, your password manager holds the keys to your entire empire. The thought of a hacker breaking into your password manager should strike a healthy fear into anyone’s heart. But when the only way to authenticate with your password manager is through something you physically have – like a roaming authenticator – there’s no way for a malicious hacker to socially engineer you to your password manager’s credentials. Perhaps the most important point of that Dashlane news is how you can completely eliminate the user ID and password as a means of logging into your Dashlane account.
But once you start down this path, the next complication arises.
Here’s the problem: For trusted parties where your only matching passkeys are the passkeys on your roaming authenticator, you’ll need a second roaming authenticator on which you can store your backup passkey. A third roaming authenticator – a backup for backup’s sake – wouldn’t hurt either. Unlike a user ID and password, you should be able to create multiple passkeys for each relying party that supports the passkey – each of them unique from the others. If you have three roaming authenticators, you will want to register three different passkeys for each relying party (a unique passkey for each roaming authenticator).
Also: What if your passkey device is stolen? How to manage risk in our passwordless future
If you really think about it, the main idea behind passkeys is this get rid of passwordOnce a trusted party opts out of authenticating with a user ID and password, you have to be very careful to avoid losing your passkey (and have a roaming authenticator Very It’s easy to lose). Some trusted parties, like GitHub, do not offer account recovery plans for accounts protected by Passkey – and rightfully so. If you are a relying party and one of your users chose to secure an account on your system with a passkey, you have to assume that they did so for a reason so that there is no other way to login.
