This week, Microsoft made a big, but not surprising, announcement: frequent Practical 365 Podcast guest Alex Weinert posted a blog post on the rollout of a public preview of passkey support in Entra ID and Microsoft Authenticator. You will continue to see lots more attention paid to passkeys because Apple, Google, Microsoft, and a number of security companies are all pushing it forward. But before you can deploy or use it, there are some things you should know, which I’m going to summarize in this column. You’ll see more passkey coverage here on Practical365, such as the coverage of the Entra ID implementation of passkeys from a Microsoft 365 perspective.
Solving Phishing?
The thing that makes phishing possible is that an attacker can steal and reuse credentials. If the attacker can’t steal anything, they can’t phish. If they steal something but then can’t reuse it, again, no phishing. The combination of those two things is what makes it possible, and the possibility is what makes phishing such a lucrative crime. To reduce phishing, we don’t have a whole lot of options:
- Magically train people not to fall for phishing websites and links;
- Invent a magical credential that can’t be stolen; or
- Invent a magic authentication mechanism that can infallibly reject stolen credentials
The security industry has been working on all three of these options, with varying degrees of success. For example, Entra ID Token Protection is supposed to make Entra ID-based applications more resistant to token replay. Passkeys attack both the second and third options above, but whether or not they solve the related problems depends on several factors.
What Makes Passkeys Different
A passkey is just a credential; nothing more, nothing less. If you’ve used certificate-based authentication, you already understand the idea that an authentication credential doesn’t have to be a username/password pair. However, there are 3 things about passkeys that distinguish them from other credential types.
First, they are cryptographically strong credentials based on a public/private key pair. They aren’t liable to spray, replay, or dictionary attacks.
Second, the passkey implementation must require user interaction of some type. This can be a biometric authentication (perhaps via Windows Hello or Apple Face ID) or even a simple pushbutton—but the interaction is a way for the user to accept that, yes, I meant to accept that authorization request.
Finally, the passkey is specific to the URL, the device, and the user who generates it. If I log in to 10 different applications on 3 different machines, all using passkeys, that means I’m going to have 30 different passkeys. (This has important implications that we’ll get to in a moment).
The combination of these three aspects means that passkeys are very, very phishing-resistant. An attacker who can steal a passkey from one device can’t use it on another, and if they steal a passkey for a user for siteA, they can’t use it for siteB.
Storage and Use
One nifty feature of passkeys is that although they may be bound to a device, they may also be capable of being used across devices. For example, you can store a passkey on your iPad and use it to sign in to services when you’re logged in to your Windows desktop. If you remember the early days of Bluetooth, when audio device users found a yawning gap between the promised and actual compatibility of different devices, you might be skeptical. Today’s passkey implementations across applications and operating systems still need some work. It remains to be seen how well users will tolerate the cross-device experiences they get when mixing different vendors.
Passkeys don’t care where they are stored– you can store them in an application like a password manager, in an OS-level service, or on a dedicated hardware device. Microsoft obviously hopes that you’ll use the Microsoft Authenticator app to store your passkeys (at least the ones for Entra ID), but you can use FIDO2-compliant security keys if you prefer. While device-bound passkeys cannot be shared across devices, syncable passkeys can—so you can create a passkey for, say, the New York Times website and then seamlessly use it across all your passkey-capable devices. Today, iOS and Android offer support for syncable passkeys, and Microsoft has promised to add syncable passkey support to Windows later in 2024.
Passkeys Aren’t Perfect Yet
Just like the early days of Bluetooth, the early days of passkeys can be maddening. For example, Apple devices can store passkeys in the OS-native iCloud keychain password manager, but then you can’t access those passkeys from non-Apple devices. However, there are currently limitations on using third-party password managers with passkeys on iOS. In the same vein, some hardware security keys can store a maximum of 25-30 passkeys, meaning if you want to use a single physical token to hold all your passkeys, you can’t use many of them, as each website or service you login to will have its own unique passkey.
It’s also important to note that when you enable device-bound passkeys for a resource, if you lose access to the passkey (perhaps because you’ve lost access to the device it’s bound to), it’s g-o-n-e. You will need to prepare yourself for, and provision your users with, alternate access methods to cover this eventuality. Alex Weinert had this to say, which I think sums up the tradeoff pretty well:
Organizations that use device-bound passkeys trade the benefit of large investments that vendors such as Google and Apple have made in creating high-security, self-service passkey recovery models for the benefit of meeting strict regulatory or security requirements. They become responsible for sharing and recovering device-bound passkeys, including those hosted in Microsoft Authenticator.
It’s still very early in Microsoft’s journey to world passkey domination, and it remains to be seen how users will take to the technology—but the potential benefits of making phishing unprofitable (and maybe even impossible!) are compelling.
