https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/ Skip to content Ars Technica home Sections Forum Subscribe * AI * Biz & IT * Cars * Culture * Gaming * Health * Policy * Science * Security * Space * Tech * Feature * Reviews * Store * AI * Biz & IT * Cars * Culture * Gaming * Health * Policy * Science * Security * Space * Tech Forum Subscribe Story text Size [Standard] Width * [Standard] Links [Standard] * Subscribers only Learn more Pin to story Theme * HyperLight * Day & Night * Dark * System Search dialog... Sign In Sign in dialog... Sign in NOT (QUITE) READY FOR PRIMETIME Passkey technology is elegant, but it's most definitely not usable security Just in time for holiday tech-support sessions, here's what to know about passkeys. Dan Goodin - Dec 30, 2024 7:00 am | 222 Woman using her phone with the digital display message enter your PASSKEY. Sign in page, modern technology, passwordless login method. Woman using her phone with the digital display message enter your PASSKEY. Sign in page, modern technology, passwordless login method. Credit: Getty Images Credit: Getty Images Text settings Story text Size [Standard] Width * [Standard] Links [Standard] * Subscribers only Learn more Minimize to nav It's that time again, when families and friends gather and implore the more technically inclined among them to troubleshoot problems they're having behind the device screens all around them. One of the most vexing and most common problems is logging into accounts in a way that's both secure and reliable. Using the same password everywhere is easy, but in an age of mass data breaches and precision-orchestrated phishing attacks, it's also highly unadvisable. Then again, creating hundreds of unique passwords, storing them securely, and keeping them out of the hands of phishers and database hackers is hard enough for experts, let alone Uncle Charlie, who got his first smartphone only a few years ago. No wonder this problem never goes away. Passkeys--the much-talked-about password alternative to passwords that have been widely available for almost two years--was supposed to fix all that. When I wrote about passkeys two years ago, I was a big believer. I remain convinced that passkeys mount the steepest hurdle yet for phishers, SIM swappers, database plunderers, and other adversaries trying to hijack accounts. How and why is that? Elegant, yes, but usable? The FIDO2 specification and the overlapping WebAuthn predecessor that underpin passkeys are nothing short of pure elegance. Unfortunately, as support has become ubiquitous in browsers, operating systems, password managers, and other third-party offerings, the ease and simplicity envisioned have been undone--so much so that they can't be considered usable security, a term I define as a security measure that's as easy, or only incrementally harder, to use as less-secure alternatives. "There are barriers at each turn that guide you through a developer's idea of how you should use them," William Brown, a software engineer specializing in authentication, wrote in an online interview. "None of them are deal-breaking, but they add up." Passkeys are now supported on hundreds of sites and roughly a dozen operating systems and browsers. The diverse ecosystem demonstrates the industry-wide support for passkeys, but it has also fostered a jumble of competing workflows, appearances, and capabilities that can vary greatly depending on the particular site, OS, and browser (or browser agents such as native iOS or Android apps). Rather than help users understand the dizzying number of options and choose the right one, each implementation strong-arms the user into choosing the vendor's preferred choice. The experience of logging into PayPal with a passkey on Windows will be different from logging into the same site on iOS or even logging into it with Edge on Android. And forget about trying to use a passkey to log into PayPal on Firefox. The payment site doesn't support that browser on any OS. Another example is when I create a passkey for my LinkedIn account on Firefox. Because I use a wide assortment of browsers on platforms, I have chosen to sync the passkey using my 1Password password manager. In theory, that choice allows me to automatically use this passkey anywhere I have access to my 1Password account, something that isn't possible otherwise. But it's not as simple as all that. When I look at the passkey in LinkedIn settings, it shows as being created for Firefox on Mac OS X 10, even though it works on all the browsers and OSes I'm using. [linkedin-passkey-firefox-macos] Screenshot showing passkey is created for Firefox on Mac OS X 10. Why is LinkedIn indicating otherwise? The answer is that there's no way for LinkedIn to interoperate flexibly with the browsers and OSes and vice versa. Per the FIDO2 and WebAuthn specs, LinkedIn knows only the browser and OS I used when creating the credential. 1Password, meanwhile, has no way to coordinate with LinkedIn to ensure I'm presented with consistent information that will help me keep track of this. Suddenly, using passkeys is more confusing than it needs to be for there to be utility to ordinary users. Things get more complicated still when I want to log into LinkedIn on Firefox for Android, and am presented with the following dialog box. [linkedin-passkey-firefox-android] Screenshot showing a dialog box with the text: "You're using on-device encryption. Unlock your passwords to sign in." At this point, I don't know if it's Google or Firefox that's presenting me with this non-intuitive response. I just want to open LinkedIn using the passkey that's being synced by 1Password to all my devices. Somehow, the mysterious entity responsible for this message (it's Google in this case) has hijacked the process in an attempt to convince me to use its platform. Also, consider the experience on WebAuthn.io, a site that demonstrates how the standard works under different scenarios. When a user wants to enroll a physical security key to log in on macOS, they receive a dialog that steers them toward using a passkey instead and to sync it through iCloud. [webauthn] Dialog box showing macOS passkeys message. The user just wants to enroll a security key in the form of a USB dongle or smartphone and can be used when logging in on any device. But instead, macOS preempts this task with directions for creating a passkey that will be synced through iCloud. What's the user to do? Maybe click on the "other options" in small text at the very bottom? Let's try and see. [webauthn] The dialog box that appears after clicking "other options." Wait, why is it still offering the option for the passkey to be synced in iCloud, and how does that qualify as "other options"? And why is the most prominent suggestion that the user "continue with Touch ID"? It isn't until selectng "security key" that the user will see that option they wanted all along--to store the credential on a security key. Only after this step--now three clicks in--does the light on a USB security key begin blinking, and the key is finally ready to be enrolled. [webauthn] Dialog box finally allows the creation of a passkey on a security key. The dueling dialogs in this example are by no means unique to macOS. Too many cooks in the kitchen "Most try to funnel you into a vendor's sync passkey option, and don't make it clear how you can use other things," Brown noted. "Chrome, Apple, Windows, all try to force you to use their synced passkeys by default, and you have to click through prompts to use alternatives." Bruce Davie, another software engineer with expertise in authentication, agreed, writing in an October post that the current implementation of passkeys "seems to have failed the 'make it easy for users' test, which in my view is the whole point of passkeys." In April, Son Nguyen Kim, the product lead for the free Proton Pass password manager, penned a post titled Big Tech passkey implementations are a trap. In it, he complained that passkey implementations to date lock users into the platform they created the credential on. "If you use Google Chrome as your browser on a Mac, it uses the Apple Keychain feature to store your passkeys," he wrote. "This means you can't sync your passkeys to your Chrome profile on other devices." In an email last month, Kim said users can now override this option and choose to store their passkeys in Chrome. Even then, however, "passkeys created on Chrome on Mac don't sync to Chrome in iPhone, so the user can't use it seamlessly on Chrome on their iPhone." Other posts reciting similar complaints are here and here. In short, there are too many cooks in the kitchen, and each one thinks they know the proper way to make pie. I have put these and other criticisms to the test over the past four months. I have used them on a true heterogeneous environment that includes a MacBook Air, a Lenovo X1 ThinkPad, an iPhone, and a Pixel running Firefox, Chrome, Edge, Safari, and on the phones, a large number of apps, including those for LinkedIn, PayPal, eBay, Kayak, Gmail, Amazon, and Uber. My objective has been to understand how well passkey-based authentication works over the long term, particularly for cross-platform users. I fully agree that syncing across different platforms is much harder than it should be. So is the messaging provided during the passkey enrollment phase. The dialogs users see are dictated arbitrarily by whatever OS or browser has control at the moment. There's no way for previously made configuration choices to be communicated to tailor dialog boxes and workflow. Another shortcoming: There's no programming interface for Apple, Google, and Microsoft platforms to directly pass credentials from one to the other. The FIDO2 standard has devised a clever method in an attempt to bridge this gap. It typically involves joining two devices over a secure BLE connection and using a QR code so the already-authenticated device can vouch for the trustworthiness of the other. This process is easy for some people in some cases, but it can quickly become quirky and prone to failure, particularly when fussy devices can't connect over BLE. In many cases, however, critics overstate the severity of these sorts of problems. These are definitely things that unnecessarily confuse and complicate the use of passkeys. But often, they're one-time events that can be overcome by creating multiple passkeys and bootstrapping them for each device. From then on, these unphishable, unstealable credentials live on both devices, in much the way some users allow credentials for their Gmail or Apple ID to be stored in two or more browsers or password managers for convenience. More helpful still is using a cross-platform password manager to store and sync passkeys. I have been using 1Password to do just that for a month with no problems to report. Most other name-brand password managers would likely perform as well. In keeping with the FIDO2 spec, these credentials are end-to-end encrypted. Halfway house for password managers With my 1Password account running on my devices, I had no trouble using a passkey to log into any enrolled site on a device running any browser. The flow was fast and intuitive. In most cases, both iOS and Android had no problem passing the key from 1Password to an app for Uber, Amazon, Gmail, or another site. Signing into phone apps is one of the bigger hassles for me. Passkeys made this process much easier, and it did so while also allowing me the added security of MFA. This reliance on a password manager, however, largely undermines a key value proposition of passkeys, which has been to provide an entirely new paradigm for authenticating ourselves. Using 1Password to sync a password is almost identical to syncing a passkey, so why bother? Worse still, the majority of people still don't use password managers. I'm a big believer in password managers for the security they offer. Making them a condition for using a passkey would be a travesty. I'm not the first person to voice this criticism. David Heinemeier Hansson said much the same thing in September. "The problem with passkeys is that they're essentially a halfway house to a password manager, but tied to a specific platform in ways that aren't obvious to a user at all, and liable to easily leave them unable to access ... their accounts," wrote the Danish software engineer and programmer, who created Ruby on Rails and is the CTO of web-based software development firm 37signals. "Much the same way that two-factor authentication can do, but worse, since you're not even aware of it." He continued: Let's take a simple example. You have an iPhone and a Windows computer. Chrome on Windows stores your passkeys in Windows Hello, so if you sign up for a service on Windows, and you then want to access it on iPhone, you're going to be stuck (unless you're so forward thinking as to add a second passkey, somehow, from the iPhone will on the Windows computer!). The passkey lives on the wrong device, if you're away from the computer and want to login, and it's not at all obvious to most users how they might fix that. Even in the best case scenario, where you're using an iPhone and a Mac that are synced with Keychain Access via iCloud, you're still going to be stuck, if you need to access a service on a friend's computer in a pinch. Or if you're not using Keychain Access at all. There are plenty of pitfalls all over the flow. And the solutions, like scanning a QR code with a separate device, are cumbersome and alien to most users. If you're going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager like 1Password. Undermining security promises The security benefits of passkeys at the moment are also undermined by an undeniable truth. Of the hundreds of sites supporting passkeys, there isn't one I know of that allows users to ditch their password completely. The password is still mandatory. And with the exception of Google's Advanced Protection Program, I know of no sites that won't allow logins to fall back on passwords, often without any additional factor. Even then, all but Google APP accounts can be accessed using a recovery code. This fallback on phishable, stealable credentials undoes some of the key selling points of passkeys. As soon as passkey adoption poses a meaningful hurdle in account takeovers, threat actors will devise hacks and social engineering attacks that exploit this shortcoming. Then we're right back where we were before. Christiaan Brandt, co-chair of the FIDO2 technical working group and an identity and security product manager at Google, said in an online interview that most users aren't ready for true passwordless authentication. "We have to meet users where they are," he wrote. "When we tested messaging for passkeys, users balked at 'replace your password with passkeys,' but felt much more comfortable with more softened language like "you can now use a passkey to log in to your account too.' Over time, we most definitely plan to wean users off phishable authentication factors, but we anticipate this journey to take multiple years. We really can only do it once users are so comfortable with passkeys that the fallback to passwords is (almost) never needed." A design choice further negating the security benefits of passkeys: Amazon, PayPal, Uber, and no small number of other sites supporting passkeys continue to rely on SMS texts for authentication even after passkeys are enrolled. SMS-based MFA is among the weakest form of this protection. Not only can the texts be phished, but they're also notoriously vulnerable to SIM swaps, in which an adversary gains control of a target's phone number. As long as these less-secure fallbacks exist, passkeys aren't much more than security theater. I still think passkeys make sense in many cases. I'll say more about that later. First, for a bit more context, readers should know: Passkeys are defined in the WebAuthn spec as a "discoverable credential," historically known as a "resident key." The credential is in the form of a private-public key pair, which is created on the security key, which can be in the form of a FIDO-approved secure enclave embedded into a USB dongle, smartphone, or computer. The key pair is unique to each user account. The user creates the key pair after proving their identity to the website using an existing authentication method, typically a password. The private key never leaves the security key. Going forward, when the user logs in, the site sends a security challenge to the user. The user then uses the locally stored private key to cryptographically sign the challenge and sends it to the website. The website then uses the public key it stores to verify the response is signed with the private key. With that, the user is logged in. Under the FIDO2 spec, the passkey can never leave the security key, except as an encrypted blob of bits when the passkey is being synced from one device to another. The secret key can be unlocked only when the user authenticates to the physical key using a PIN, password, or most commonly a fingerprint or face scan. In the event the user authenticates with a biometric, it never leaves the security key, just as they never leave Android and iOS phones and computers running macOS or Windows. Passkeys can be stored and synced using the same mechanisms millions of people already use for passwords--a password manager such as Bitwarden, Apple iCloud, Google Password Manager, or Microsoft's cloud. Just like passwords, passkeys available in these managers are end-to-end encrypted using tried and true cryptographic algorithms. The advent of this new paradigm was supposed to solve multiple problems at once--make authenticating ourselves online easier, eliminate the hassle of remembering passwords, and all but eradicate the most common forms of account takeovers. When not encumbered by the problems mentioned earlier, this design provides multifactor authentication in a single stroke. The user logs in using something they have--the physical key, which must be near the device logging in. They must also use something they know--the PIN or password--or something they are--their face or fingerprint--to complete the credential transfer. The cryptographic secret never leaves the enclave embedded into the physical key. What to tell Uncle Charlie? In enterprise environments, passkeys can be a no-brainer alternative to passwords and authenticators. And even for Uncle Charlie--who has a single iPhone and Mac, and logs into only a handful of sites--passkeys may provide a simpler, less phishable path forward. Using a password manager to log into Gmail with a passkey ensures he's protected by MFA. Using the password alone does not. The takeaway from all of this--particularly for those recruited to provide technical support this week but also anyone trying to decide if it's time to up their own authentication game: If a password manager isn't already a part of the routine, see if it's viable to add one now. Password managers make it practical to use a virtually unlimited number of long, randomly generated passwords that are unique to each site. For some, particularly people with diminished capacity or less comfort being online, this step alone will be enough. Everyone else should also, whenever possible, opt into MFA, ideally using security keys or, if that's not available, an authenticator app. I'm partial to 1Password as a password manager, Authy as an authenticator, and security keys from Yubico or Titan. There are plenty of other suitable alternatives. I still think passkeys provide the greatest promise yet for filling the many security pitfalls of passwords and lowering the difficulty of remembering and storing them. For now, however, the hassles of using passkeys, coupled with their diminished security created by the presence of fallbacks, means no one should feel like a technophobe or laggard for sticking with their passwords. For now, passwords and key- or authenticator-based MFA remain essential. With any luck, passkeys will someday be ready for the masses, but that day is not (yet) here. Photo of Dan Goodin Dan Goodin Senior Security Editor Dan Goodin Senior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 222 Comments Staff Picks Mungus the Unhyphenated Mungus the Unhyphenated So... We've fallen into the same kind of trap with passkeys that we did with SSL certificates. A system that's fundamentally simple but is made opaque and confusing due to differing approaches to management and implementation on different platforms. Passkeys themselves aren't had to understand. The difficulty arrives when software attempts to be "user-friendly" and hides too much from the end-user, or presents the system in a way that appears different from other common, competing implementations of the same tech. The technology itself isn't the problem. It's the inconsistencies in interfaces and UI design factors that make it harder to use than it has to be. We'll have them as a very good tool in the kit, but adoption will be slow and irregular because the learning curve is artificially steep and convenience is inadvertently negated. There's probably an XKCD that fits this perfectly, but unfortunately, I have to get busy with work in a few minutes which prevents me from hunting for it... December 30, 2024 at 12:53 pm Scipio Africanus Scipio Africanus The biggest issue that still doesn't get enough mention is the vendor lock-in (clearly a feature for the big companies involved in the design..) Say you've been using 1Password for years and have hundreds of passkeys saved. Currently as far as I can see there's no easy, practical way to transfer all of those keys batch wise to a different password manager or completely different system. This for me is a complete deal breaker because I refuse to chain myself to a single corporation. The fact that it also seems impossible to provide an open source implementation that you can self-host and that will be accepted everywhere comes close second (and again clearly to the benefit of the large companies designing the spec). Passwords have a whole lot of issues, but at least it's trivial to have an offline backup that I can use on any device without prerequisite. Being worked on. https://fidoalliance.org/ fido-allia...ote-user-choice-and-enhanced-ux-for-passkeys/ December 30, 2024 at 1:21 pm D DLJD That sounds awful and trying to make that system work for my 70 year old parents seems nigh impossible. And not to forget: You now better always lug at least two devices with you whenever you travel and God forbid something happens to both of them. I don't expect most people to use 3 different syncing services, but mostly used that to illustrate how Passkeys work. For most people they'll save their Passkey to iCloud or Google, and that's that. All their passkeys are available from all their devices, and so long as they don't lose access to all their devices or their Google/Apple accounts, they're okay. This could definitely be a problem if they only use one device, because that's a single point of failure. Likewise it's a single point of failure if they're ever locked out of their Apple/Google accounts for some reason. But a lot of ordinary people have at least a phone & something else (laptop, tablet, even their old phone), and they'd be perfectly okay with Passkeys. No need to travel with all devices, all the time, any one of them has full access to all Passkeys. Indeed it's better if at least one is left behind, so there's no risk of losing all their devices at once. Not travelling with all their devices is probably what most people would do by default anyway. Setting them up is definitely more confusing than it's worth right now, especially cross-platform as the article describes, but Passkeys themselves are excellent. For what it's worth, once I set them up (where available) for my ~65 year old parents, they've worked seamlessly, and I've not had to play tech-support recovering forgotten passwords once. December 30, 2024 at 1:29 pm E ERIFNOMI Pretty much all complaints and confusion around passkeys in the comments here so far are addressed by remembering that passkeys aren't the only way you can access your account. You still have your password to fall back on, so when you lose your phone and have to set up a new one, or the first time you sign in on a new device or whatever, you can use your password if that's what you have to do. But for your day to day sign ins, a passkey is more secure, can't be traditionally phished, is easier to use, etc. etc. You're free to argue that's more complicated than passwords alone, sure. But you don't have to worry about how do you save your passkeys or migrate them between devices and what happens when you lose access to a device that holds those keys. Get back in with a password on the rare occasion it's necessary and you still greatly reduce the amount you rely on passing around a simple shared secret that can be snatched up by a nefarious third party. It's definitely more complicated than just having one password that lets you into every account you've ever made, but everyone here would agree that password reuse is a horrible idea. The question becomes do passkeys reduce the friction of having unique passwords everywhere enough to get normal people to stop using their simple to remember, simple to type, simple to lose passwords? Right now no, it probably doesn't, if you consider when they'll need to fall back to that password. Yes, day to day using a passkey will be better, but realistically you need a password manager to store the fallback password. Passkeys are without question more secure than a password. And they don't really add any friction if you're already doing things right. That means they're still safer than passwords for those kinds of users, but that's not quite good enough. I think for everyone to jump to passkeys, there's going to have to be some way to make them "just work" everywhere, on every device, without needing to use a password you'll never remember once in a blue moon. That's difficult, maybe infeasible. December 30, 2024 at 1:39 pm Comments Forum view Loading Loading comments... Prev story Next story Most Read 1. Listing image for first story in Most Read: Passkey technology is elegant, but it's most definitely not usable security 1. Passkey technology is elegant, but it's most definitely not usable security 2. 2. After 60 years of spaceflight patches, here are some of our favorites 3. 3. I keep turning my Google Sheets into phone-friendly webapps, and I can't stop 4. 4. Tech worker movements grow as threats of RTO, AI loom 5. 5. You can love or hate AI, but it's killed crappy 8GB versions of pricey PCs and Macs Customize Ars Technica has been separating the signal from the noise for over 25 years. With our unique combination of technical savvy and wide-ranging interest in the technological arts and sciences, Ars is the trusted source in a sea of information. After all, you don't need to know everything, only what's important. More from Ars * About Us * Staff Directory * Newsletters * Ars Videos * General FAQ * RSS Feeds Contact * Contact us * Advertise with us * Reprints Do Not Sell My Personal Information (c) 2024 Conde Nast. All rights reserved. Use of and/or registration on any portion of this site constitutes acceptance of our User Agreement and Privacy Policy and Cookie Statement and Ars Technica Addendum and Your California Privacy Rights. Ars Technica may earn compensation on sales from links on this site. Read our affiliate link policy. The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Conde Nast. Ad Choices