Passkeys have way too many footguns for me. If I use my phone to sign in I'm going to accidentally create a passkey there on iOS embedded webview. When I use Google Chrome, the website won't give me any information for me to find where I stored the passkey. Was it in iOS keyring? Chrome? My Bitwarden? If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.
I'm sure it's of use to many people but it's been no end of pain for me and it has really signaled to me what it's like to grow into an old man unable to use computers when I was once a young man who would find this easy.
I like the concept of them, and I want them to work well purely so people stop using bad passwords. But nearly everywhere does it differently and weirdly and likely wrongly.
When I log into my Amazon account with a passkey, it then asks me for a 2FA code. The 2FA code is stored on the same device as a passkey, that step literally does nothing. After I do the 2FA code, it then prompts me to create a passkey. No! I have one. I signed in with one.
Some devices give me the option to use a QR code. I like that option usually, I can easily use my phone to authenticate. But sometimes i can’t get the QR code to appear. Support varies by OS, browser, and set of installed extensions. And there’s no easy way to control which of those three handles the passkey when something decides wrongly.
I had to troubleshoot something on someone else’s computer, and saw that they logged in to windows with a passkey and QR code. I’ve looked, and I can’t seem to set that up on my windows computer. There isn’t an option to and I have no idea why.
Yup. I hate them. I get the problem they're trying to solve, it just seems like I have more work to do... and I honestly don't even follow what is going on sometimes.
I recently moved to a new computer and it's just an AUTHHELLSCAPE.
Passkeys on iOS and macOS actually work quite well in that regard. They get stored in your provider of choice across the web, web views, apps etc., at least in my experience.
Mine is Bitwarden, and that's available on pretty much all platforms, natively where available (except on macOS currently), as a browser extension otherwise.
For the rare instance in which I need to authenticate using a passkey on a computer where I'm not logged into Bitwarden, there's the cross-device CaBLE flow where I can scan a QR code with my phone and use Bitwarden to authenticate. This works across OSes and browsers.
except... i store my password for work in bitwarden, so I dont want to also keep my work passkeys in the same place. For my personal stuff, that is a risk I can live with so far, but for work it seems dumb.
The main benefit is you will never put your passkey on a phishing site. Password managers provide some protections against it because if they do not work automatically on a website you know something is fishy, but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password.
The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.
The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login
I was reading your other blog post about storing them in bitwarden I have to disagree with this point:
> Unless you were forced to by some organisational policy, there’s no point setting up 2FA only to reduce the effective security to 1FA because of convenience features.
2FA both stored in your password manager is less secure than storing than separately, but it still offers security compared to a single factor. The attack methods you mentioned (RAT, keylogger) require your device to be compromised, and if your device is not compromised 2fa will help you.
To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
Also I really like the style and font of your blog.
This isn't a footgun, you just have absurd security requirements.
>It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
You simply do not need two factors with passkeys. Using passkeys is not pointless, they are vastly more secure than most combined password+2fa solutions.
There are extremely few contexts where an yubikey would be meaningfully safer than the secure element in your macbook.
> It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
I just use iOS' wallet for all of it, the only exception being if its something I 100% need to open outside of my iphone / macs. Then I go for BitWarden, turns out I dont need any apps to open outside of that sandbox, I am okay only opening these up on Mac. I can always type my password on Linux. That's what bitwarden is for anyway.
>If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.
The problem is not with passkey rather system such as iOS keeps a tight lid on how files are uploaded and retrieved from the device. There is a real disconnect between desktop and mobile file system now days.
Embedded webviews are the stupidest thing ever. Yesterday I got halfway through a checkout process, had to go back to another app to check something, and then the webview simply disappeared so I didn't bother finishing the checkout. This was on Android
Usually I open it in Chrome but for some reason I didn't realize it was a webview this time
God yes that. Our VPN client fell over the other day because the auth popup opens an embedded web browser which throws a javascript error as it's bouncing through our ID provider pages. How the fuck we got there I don't know. Everything is a gigantic Heath Robinson contraption.
I do use Bitwarden everywhere but a couple of times the passkey prompt doesn't show it. I think that's how I got the webview for one of my google accounts stored in iOS keychain.
For this reason I am avoiding it like a plague. It is an additional way to fingerprint your activity and the scenarios where you migrate your passkeys from a device to another seems not really well "oiled"
The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.
Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.
The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.
What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
> What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
This feels more like CYA/shifting the blame for me. If a service is designed so that I will lose all my data if I lose the passkey, then a "yo, don't lose that passkey, like, ever!" warning is the minimum, but doesn't solve the problem.
I found the initial suggestion "don't ever use passkeys for encryption of persistent data" more reasonable.
(Or what the sibling comment describes: Design the encryption in such a way there is an alternate key that could be used for decrypting)
I think the idea behind PRF was something like "use this as one of several keys", never as "use this the only key". I don't think this was explicitly called out in the specs, though.
> this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion
That sounds like a reasonable idea, but still doesn't help with the case of a completely deleted/destroyed authenticator, e.g. a lost Apple/Google account or Yubikey.
The only viable solution to me for mass adoption is restricting (by recommendation, since there's no way to programmatically enforce it) PRF to scenarios where it's only one out of several ways to get access back. Some password managers do this, e.g. they encrypt their master secret under a PRF-derived key, but this is not the only way/place to get to the master secret, and they also encourage printed key backups etc.
This story of a user deleting their passkey doesn't seem plausible to me. They don't remember why they have a specific passkey for a messaging app? Surely recognizing the app that stores so many memories is enough not to delete the passkey. And why are they "cleaning up" their passkeys in the first place? Yes I put "cleaning up" in quotes, this metaphor, suggesting that a long list of unused passkeys is dirty in some way is inappropriate.
If an app has a billion users, how many do you expect will delete their passkey for no reason? Is this more important then end-to-end encryption for everyone?
If deleting one's passkey for no reason was a thing, I'd expect a real story about a real user, rather then a made-up scenario.
The essay has a condescending attitude towards the normie computer user who can't possibly be expected to know, but it's precisely the normie computer user who would never get the stupid idea of "cleaning up" their passkeys in the first place -- that's something only a nerd with a neurotic attitude to their computer would do.
This past weekend I watched as my mom discovered the password manager in Chrome, and started deleting every entry she couldn't immediately recognize. "Why is this here? I don't need this"
Despite me pleading that they got there for a reason, and takes zero storage, she was confident she didn't need these passwords. So I can totally see her deleting passkeys; my mom is basically Erica, there need to be very explicit implications stated for every action presented and not assume innate understanding
I consider myself pretty sophisticated with passkeys (I wrote a toy implementation of WebAuthN once to understand them better), and yet I still get tripped up by this sometimes: Not via intentional deletion, but accidental overwriting.
As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.
Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.
It's more likely for them to accidentally be deleted (or otherwise lost access): in my experience approximately zero users actually understand where their passkeys are stored, and they can be all over the place: the number one question I get is 'why can't I log in?' because they've accepted a passkey setup dialog on one machine without really reading it and now can't log in on another. Sometimes it's on the same machine but in different contexts. No passkeys should be considered something that the average user is going to reliably hold onto (in large part because the industry has been so keen to foist them on users but not very keen at all to educate them on how they work. This also makes them a lot less useful from a security point of view because it means you can't get rid of the recovery process, which tends to be the weaker link).
Passkeys are a mystery, and no one bothers to explain what they are, what it means, how it works, what to do, what to avoid.
I'm not an average user - MA in Mathematics, Ph.D. in Computer Science, 27 years of experience as a developer. I have a vague idea that a passkey is like a password, but you don't see it and don't type it and it's stored "somehow, somewhere."
I can't make much sense of that. How is an "average user" suppose to make sense of that?
When I try to find out how passkeys work, I get some incomprehensible gibberish about self-signed certificates, public/private key pairs, challenges, and on and on. In short, a Monad is just a monoid in the category of endofunctors of X, with product (X) replaced by composition of endofunctors and unit set by the identity endofunctor. What's the big deal?
Since any device that stores a passkey can be lost or destroyed at any moment, I assume any passkey can be lost at any moment, and there had better be a way to recover from that. Is there? Who knows.
> in my experience approximately zero users actually understand where their passkeys are stored
Passkeys are designed to be hidden from the user. The author of this article even went on GitHub telling an open source implementation to not let users copy the private key.
There is a good reason for it. If you can copy and paste your passkey, then a phishing site can just ask you for it, making the phishing protection passkeys provide moot.
But the consequence is people, including many technical users on this website, cannot get a grasp on passkeys both as a concept and in a literal sense. How can you perceive, let alone understand, something that is designed to be hidden from you? It also doesn't help that it was pushed on users with little explanation and comes with many seemingly incompatible implementations.
Unless passkeys are redesigned to solve the intangibility problem, grannies will keep losing their accounts for no good reason and we will keep arguing about it on HN.
the problem so far is UI and incompatibility across devices, OSes etc.
I am a big fan of Passkeys and the idea of using PRF for E2E encryption, but I wouldn't implement that as now, there is almost zero control over where those passkeys are, how I can recover them, how I manage them. Whenever I have to switch computer (mandatory policy at work), or phone (mandatory obsolence) or if I want to work across OSes (Mac for work, Windows for fun), everything falls apart, incomprehensible interfaces, inexistent transparency and control. And I'm a pro user that has actually studied how the standard works.
I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.
Security is important, security is important, security is important — I keep emphasizing this point.
But for me, that statement only really applies to people who genuinely understand security.
I personally bought two YubiKeys, understand the associated risks, and store my credentials on those YubiKeys.
However, many people today do not realize the risks involved. They casually store these things in places like a keyring and then never manage them properly.
That does not necessarily mean they are secure. On the contrary, it can become another kind of danger, because once you start using passkeys, the level of access and authority tied to them is significant. If they are lost or leaked, the consequences can be disastrous.
I am glad to see that the industry is paying more attention to security, but at the same time, I believe these more specialized aspects should be aimed at people who actually have the relevant expertise.
Passkeys do have a learning curve. For ordinary users, they often just click through a few prompts and end up binding themselves to a system without really understanding what happened.
On top of that, with modern systems relying on encryption and TPM, once a computer runs into serious problems, many people simply have no way to recover their data.
For the average user, 2FA is already sufficient.
Mom can't figure out what they are or how to use them. They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck (yeah yeah multiple devices and paths to auth and backup codes, none of that matters). It's one further step down the attested hardware software and eyeballs path. Passwords forever, shortcomings be damned.
> As of October 2025, passkey login has been fully rolled out and is now required for members with Health Savings Accounts (HSAs) and Reimbursement Accounts (RAs) who use the HealthEquity Mobile app and web experience.
The FAQ is a little misleading by saying WHEN your account has a passkey this and that, but reality is that after October they made them completely mandatory, no bypass, no exceptions. 100% coverage.
Oh, and by the way, passkeys have been broken on PC/Linux when using Firefox for months:
> There Was A Problem: We encountered an error contacting the login service. Please try again in a few minutes.
Neat. You have to use Chrome or Edge.... For months, after making it mandatory...
That's weird, I can login to my HealthEquity account (which contains HSA) without any issues and I don't have passkey setup. I confirmed it just now just in case.
That article does say "HealthEquity Mobile and web experience" so maybe it's just for customers who use both, I only use web.
>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck
This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.
And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.
First, in relation to TFA: even if you regain access through a recovery channel, any data that was encrypted using your lost passkey will now be gone.
There are also many exciting new ways you can lose your passkey that wasn't the case with a password you can remember in your mind. The person you responded to is worrying about big tech randomly banning you and making you lose access, in the meanwhile I'm mostly worried about losing the physical device containing the key. I don't think I will forget, say, my Google password unless I got Alzheimers or got hit in the head by a hammer, at which point I will have bigger problems than a lost Google account.
And let's not pretend account recovery process is always smooth and easy. They may require evidence from your other accounts you cannot access now due to the key loss. They may demand government IDs that might have been lost alongside your device. They may also just deem your recovery attempt fraudulent and ban you for no reason (which I similar to the scenario the post you are replying to desctibed.)
Genuine question: what if the recovery asks for a 2nd factor that's e.g. the device which you lost? Is that common?
Personally I don't really trust companies to not do a whoopsie and permanently lock you out when you lose credentials. Especially when the company is big or hard to access in person.
For someone like me who already uses a password manager for everything, passkeys seem to add no security while reducing usability and control.
> A safe password and a good password manager are way better, they don't lock you into any platform.
An open, cross-platform passkey implementation does all that too, and on top of that prevents you from accidental password leaks via logs, MITM etc. by default.
> It's super sad to see all kinds of websites offering you to add a passkey when you log in.
As long as they're not forcing you to add one, what exactly is your problem with having more choice?
Personally, I am grateful for every site that doesn't require my phone number to sign up and uses passkeys for authentication instead, yet I also don't want SMS authentication banned for everybody since I understand it currently works better than Passkeys for many people.
I was planning to make use of passkeys when logging on to various services, so I ordered three physical devices, supporting passkeys (yubikey). I ordered USB C and USB A variants, with NFC support.
Is this a mistake? I am already using password manager and totp for my accounts, but I am tired of dealing with passwords.
Even when using a password manager (bitwarden in my case), it just get tedious bringing out my phone, starting auth app, locating the correct account, reading 6 digit token and logging on.
Passwords are terrible UX for old people in my experience. They try use the same password everywhere, but then password complexity requirements mean they can't use the exact same password everywhere, and then they forget which variant they used on which service, so they just end up going through the reset password flow every time they sign in. I am not convinced that's a better UX than them just using their fingerprint or face to login.
Biometric keys are still a niche techie thing that the average person probably doesn't even know exist. Most people will be using passkeys exclusively through their phones, often unintentionally. And outside the first world it is not uncommon for people do own no computing devices apart from their phones.
Backup keys and recovery codes also do not solve all cases of key loss. One thing I worry about is what happens if I am traveling in a foreign country and loses my belongings. In the past if I can convince someone to let me use his computer I can at least log into my email account as long as I remember my password. If everything is passkey then I will be locked out of all my online accounts until I make it back home, assuming that I have actually properly set up the backup device and keys. Humans are not very good at making sure that backups actually work.
Too bad the spec is stupid and requires password managers to be identifiable so servers can deny the "insecure ones".
It's already a pain to use Keepassxc for otp since they all want you to use their apps but it's still doable (the worst offender being steam where you have to hack your own app to extract the otp secret). With passkeys you won't have a choice to use The Google AuthenticatorTM etc because eventually some exec will find they can block every provider except their own to boost app download KPI.
I really like concept of passkeys, the simple fact of using asymmetric keys is so much better than giving the secret to prove you have it, but the spec is hostile and thought for vendor closing.
But didn't the author hint that this could get blocked?
My general read on passkeys and their implementers is that exportability is seen as a risky feature, and there's a push to make it as opaque as possible, likely through attestation or similar mechanisms.
Also a password could be the passkey, the passkey protocol is basically a way to send to a server an authenticated public key. The client could deterministically convert passwords to key-pairs and authenticate with those
Nothing in this post is specific to passkeys; it reads like advice to not encrypt data. There’s no way to prevent some users from losing their encryption key anyway. Whatever warnings you include, even when software doesn't connect to the internet and just encrypts local files, someone will write to support that they forgot their password and ask you to "reset" it.
Because passkey managers have no idea what a service is using its passkey for. They could warn that deleting a passkey could make all sort of bad things happen, but for most services it will be only the loss of access. What the alternative could be? "Before deleting this passkey you must contact this site and ask them what data you will loose. I give you a week. Come back here a week from now and confirm your desire to delete this passkey. I will not make you delete it before that day. See you!"
> "Even if there were explanatory text, Erika, like most users, doesn’t typically read through every dialog box, and they certainly can’t be expected to remember this technical detail a year from now."
Passkeys are a step in the right direction, ironically for the exact reason the author advises caution. We've been telling people to "store your backup key somewhere safe" for the best part of a decade now, and your average Erika hasn't got on well with that at all. Locking themselves out and losing data left, right and centre.
If you've worked at any kind of scale you'll know well that a certain percentage of users will lose their data with E2EE, full stop. It's just different from everything else they've ever used. These are the same people who'd be lost without the "forgot password" link, and there's no shame in that. That's just the reality of it. And passkeys can help people like this to not lose their keys.
If the product is truly E2EE, the best options right now are the passkey implementations baked into Chrome or Apple. Windows, as ever, needs a bit of work, but the password managers seem to be picking up the slack well enough. We also need to educate people that with true E2EE there is no "forgot password" email. Passkeys and the tooling around them still have a ways to go, but we're getting there.
How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.
Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.
I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.
That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.
Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.
This is usually due to relying party and possibly password manager bugs, but it does happen.
I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.
The issue there being there's a big usability headache with enrolling multiple devices. You really want one device to be able to enroll all your devices (including not-present and offline), but there's no mechanism to do this with the way the webauthn spec works at the moment.
None of the password managers (including but not limited to ones built-in iOS/Android) work that way. The Apple one (and I think Google is the same) keeps the private key inside the secure enclave (security processor), but it is still copied to each new device - though it is end-to-end encrypted during that transmission.
That’s how I use them. Passkeys on two Yubikeys. And I tag in my password manager which credentials have what form of auth. UP, TOTP (also stored on the two Yubikeys), Webauthn or passkeys (the former indicating 2FA).
If the user deletes passwords they're shown the same exact message. The only saving grace for passwords is that you can remember them, but are you also suggesting to not use generated passwords?
I think the distinction is that a passkey is meant to be used for authentication (logging in), and is usually not the only way you can authenticate. If you delete your password, passkey, or 2FA method, you can still go through a "forgot password" flow.
Encryption is different. If you encrypt data with a generated password and then delete it, you're toast, and passkeys are no different. I think the author is arguing that users may not even realize that the passkey itself is needed to decrypt, possibly because they're so associated with login.
for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.
Generated passwords can be useful, but they come with challenges like management and security. It's better to adopt approaches like password managers or biometrics to enhance usability while maintaining security.
Somewhat related, i recently ran into the issue, after i created an account on Confer.to [1] on my Desktop, i couldn't login on my iPad / iOS with Proton Pass and/or Bitwarden.
The error message was: "Error: "Authenticator did not return a PRF result — this passkey probably isn’t PRF-capable."
So i now have an account, but can only use it on my Desktop.
(can't change to a password login either, it's Passkeys only...)
[1] end-to-end encrypted AI, developed by Moxie Marlinspike, the founder of Signal: https://confer.to/
Sounds like the website did a shitty job at implementing passkeys. I’ve read through the guides and done it myself and yes there are a lot of gotchas and they’re all avoidable.
It is conundrum that passkeys were designed to help the majority as they are frictionless (like passwordmanagers etc) but fail in reality.
Even those that have 2 devices they don't have them all the time.
Another overlooked issue is that some banks etc don't allow for 2 devices as login or 2FA. Even if it allowed one needs to keep the spare device always updated. Either Govt needs to build a common API that one can use directly through google pay or apple pay - so that only one app is needed to be kept up to date.
to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them - but at least then if I lose the phone - and I show my ID they should allow me to setup my new phone. But that is also not possible. (I am discounting the awful AI bans)
You're thinking about hardware authenticators, not Passkeys. Passkeys are definitionally synchronized and backed up in the cloud (otherwise you just have a sparkling WebAuthN authenticator).
Proprietary clouds and sync backends create their own set of problems, but they do solve the availability issue of always having to register at least two different security keys with each service.
> to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them
That's exactly what you can do today!
> I show my ID they should allow me to setup my new phone.
You have to show them your phone number, which for better or worse is our age's "showing ID", but then you can indeed get back in.
This is why I haven't started using passkeys. Managing them is looks complicated and I don't understand the ramifcations of what I'm doing.
Also a style nit, it's OK to use "he" or "she" pronouns in a contrived narrative. The "they/their" usage really detracted from the clarity of the example.
I don't think I would have even realized why I felt tension reading if you hadn't mentioned this. They/their wasn't confusing at all but, giving the hypothetical user a name was the weird part. I realize now I was expecting some other user to enter the scenario the whole time. Alice and Bob style. When I got to the end, I felt like I missed something. If there's just one, "the user"/"they"/"their" is fine.
Passkeys to me come across as a part solution to a valid problem. Education is part of the solution. Treating the user as too dumb to understand why they need strong passwords or passkeys is important.
I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
I use passkeys from keepasxc because the native workflow for passkeys is opaque and easy to misunderstand what you are actually doing. And it's predicated on having an account with big us tech companies.
> I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
Both iOS and Android sync passkeys to their respective cloud accounts by default. (Of course, losing access to that account, sharing one across family members and causing confusion etc. are still concerns.)
The real problem is lock-in, as this effectively often prevents entire families from switching from iOS to Android or vice versa. I'd encourage anyone managing their family's tech setup to pick a platform-agnostic passkey implementation such as 1Password or Bitwarden for that reason.
I love the idea of hardware keys, and would absolutely use them for the essential stuff (email, domain registrar, bank) but they're just too expensive, while plain old TOTP 2FA is free and provides 99% of the benefits for my use case. TOTP also has a much better workflow in my experience, but this isn't that big of a problem for the things I'd consider essential, but it would be annoying if I were to use a hardware key for everything.
I can buy 6-8 physical keys for the front door of my house for the cost of one Yubikey. Even though there are options at half price, that then gets eaten into by the need to have two or three of them, since a backup is not optional for this sort of use case. I can't imagine convincing one's parents to buy 'a key for your email account' will be easy when the old way mostly 'worked fine' and was free, meanwhile the new one will cost them a non-trivial amount of money. It's an easy flow if you're their sysadmin, but I wouldn't want to throw my parents into the deep end of hardware keys and have to explain to them that they don't need the expensive one, but still have them be discouraged by the mere existence of 100+ dollar options for what should be damn-near throwaway hardware.
Passkeys somehow manages to have a worse workflow than both though.
Probably everything else is debatable, I do agree with one thing though, the cat is indeed out of the bag. It would have been probably a really good use case if the scope was limited to only hardware based security keys for enterprise users only.
Rolling it out for OS platforms, software based authenticators just muddies the water. You cannot even provide any guarantees around it being phishing resistant anymore.
I was looking into this to start using this. Because it’s quite user friendly to not let the user worry about all the details that involve encryption of data.
I guess informing them is a good way to start. Are there any other tips on how this can be improved?
On a similar note mooltipass can export an encrypted backup of passkeys.
That said platform should support multiple passkeys so if you lose access to one you arent screwed over.
Another way to say this is that you have to have an account recovery process and you need to think about how your encryption interacts with account recovery.
100% of the arguments against using passkeys for e2ee data apply to using passkeys as credentials.
(Unless they are not credentials, and you can loose them then do a password reset via a phishing prone channel like email and SMS. Supporting this eliminates any possible user benefit of passkeys.)
In addition to the arguments in the article, when used as credentials, they are an obvious trojan horse allowing large websites to completely hijack your operating system.
Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android. This is where passkeys are taking PCs, and it is their only purpose.
> Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android.
What does root detection and other device attestation have to do with passkeys? Passkeys (at least Google's and Apple's) don't support device attestation.
The standard includes a hardware attestation path.
That’s the backdoor allowing the eventual takeover of your OS.
First people use passkeys, and they become standard.
Then they become required for important accounts for security.
Then the important accounts require the attestation bit.
At that point, you cannot run web browsers on open source operating systems.
This is all boring and predictable. It is exactly what they did with Android, and exactly the same organizations are pushing passkeys.
Note: If they had good intentions, the operating system would manage any attestation, and not allow websites to query for or require attestation support.
Passkeys have way too many footguns for me. If I use my phone to sign in I'm going to accidentally create a passkey there on iOS embedded webview. When I use Google Chrome, the website won't give me any information for me to find where I stored the passkey. Was it in iOS keyring? Chrome? My Bitwarden? If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.
I'm sure it's of use to many people but it's been no end of pain for me and it has really signaled to me what it's like to grow into an old man unable to use computers when I was once a young man who would find this easy.
I like the concept of them, and I want them to work well purely so people stop using bad passwords. But nearly everywhere does it differently and weirdly and likely wrongly.
When I log into my Amazon account with a passkey, it then asks me for a 2FA code. The 2FA code is stored on the same device as a passkey, that step literally does nothing. After I do the 2FA code, it then prompts me to create a passkey. No! I have one. I signed in with one.
Some devices give me the option to use a QR code. I like that option usually, I can easily use my phone to authenticate. But sometimes i can’t get the QR code to appear. Support varies by OS, browser, and set of installed extensions. And there’s no easy way to control which of those three handles the passkey when something decides wrongly.
I had to troubleshoot something on someone else’s computer, and saw that they logged in to windows with a passkey and QR code. I’ve looked, and I can’t seem to set that up on my windows computer. There isn’t an option to and I have no idea why.
Yup. I hate them. I get the problem they're trying to solve, it just seems like I have more work to do... and I honestly don't even follow what is going on sometimes.
I recently moved to a new computer and it's just an AUTHHELLSCAPE.
Passkeys on iOS and macOS actually work quite well in that regard. They get stored in your provider of choice across the web, web views, apps etc., at least in my experience.
Mine is Bitwarden, and that's available on pretty much all platforms, natively where available (except on macOS currently), as a browser extension otherwise.
For the rare instance in which I need to authenticate using a passkey on a computer where I'm not logged into Bitwarden, there's the cross-device CaBLE flow where I can scan a QR code with my phone and use Bitwarden to authenticate. This works across OSes and browsers.
> This works across OSes and browsers.
It doesn't work for me in Firefox on Linux. I'm very curious to know how it works for you.
1 reply →
except... i store my password for work in bitwarden, so I dont want to also keep my work passkeys in the same place. For my personal stuff, that is a risk I can live with so far, but for work it seems dumb.
2 replies →
I truly don't see the advantage of passkeys over a password manager like bitwarden, with random passwords.
The main benefit is you will never put your passkey on a phishing site. Password managers provide some protections against it because if they do not work automatically on a website you know something is fishy, but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste (or even type, if pasting is disabled) the password.
The problem is whether or not the benefit outweighs the additional risks introduced — losing account access when you lose a device, furthering device lock down, difficulty transferring the passkey between devices, UX degradation due to bad implementation. In my opinion the answer is no and I am sticking with my passwords.
1 reply →
The advantage is that the password never leave the device. It has a public key and signs challenges with the private key but nothing sensitive goes over the wire on every login
11 replies →
The main advantage is how strictly limited export of the passkey secret is. It is very unlikely for it to ever be phished or copied.
They're more accessible to people who don't understand computer security?
The system always asks where you want to store it, and all passkey managers vend to the system prompt with labels so you can see where it is.
This is not an issue on iOS, I can’t tell how what you’re describing could happen.
There’s another foot gun I wrote about recently:
https://cedwards.xyz/passkeys-are-not-2fa/
I was reading your other blog post about storing them in bitwarden I have to disagree with this point:
> Unless you were forced to by some organisational policy, there’s no point setting up 2FA only to reduce the effective security to 1FA because of convenience features.
2FA both stored in your password manager is less secure than storing than separately, but it still offers security compared to a single factor. The attack methods you mentioned (RAT, keylogger) require your device to be compromised, and if your device is not compromised 2fa will help you.
To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.
Also I really like the style and font of your blog.
4 replies →
This isn't a footgun, you just have absurd security requirements.
>It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
You simply do not need two factors with passkeys. Using passkeys is not pointless, they are vastly more secure than most combined password+2fa solutions.
There are extremely few contexts where an yubikey would be meaningfully safer than the secure element in your macbook.
10 replies →
> It should be pretty obvious that using a passkey, which lives in the same password manager as your main sign-in password/passkey is not two factors. Setting it up like this would be pointless.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
Passkeys are meant to replace passwords. Not being second factors is the point.
6 replies →
I just use iOS' wallet for all of it, the only exception being if its something I 100% need to open outside of my iphone / macs. Then I go for BitWarden, turns out I dont need any apps to open outside of that sandbox, I am okay only opening these up on Mac. I can always type my password on Linux. That's what bitwarden is for anyway.
>If I had any discipline around this it would make sense but if I accidentally double tap on the screen I've got a passkey and it's stuck on my phone.
The problem is not with passkey rather system such as iOS keeps a tight lid on how files are uploaded and retrieved from the device. There is a real disconnect between desktop and mobile file system now days.
Embedded webviews are the stupidest thing ever. Yesterday I got halfway through a checkout process, had to go back to another app to check something, and then the webview simply disappeared so I didn't bother finishing the checkout. This was on Android
Usually I open it in Chrome but for some reason I didn't realize it was a webview this time
Embedded WebViews are a way to track you:
https://news.ycombinator.com/item?id=32514793
I disable them on every app that lets me. It is in every way worse UX than simply opening the browser.
God yes that. Our VPN client fell over the other day because the auth popup opens an embedded web browser which throws a javascript error as it's bouncing through our ID provider pages. How the fuck we got there I don't know. Everything is a gigantic Heath Robinson contraption.
You can just use bitwarden everywhere if you are ok with it in the cloud.
I do use Bitwarden everywhere but a couple of times the passkey prompt doesn't show it. I think that's how I got the webview for one of my google accounts stored in iOS keychain.
1 reply →
Tell that to my mom who has created a bunch of passkeys all over the place without knowing what they are. I'm trying to unwind it but it's a mess.
11 replies →
Doesn't need to be in the cloud for it work everywhere.
2 replies →
For this reason I am avoiding it like a plague. It is an additional way to fingerprint your activity and the scenarios where you migrate your passkeys from a device to another seems not really well "oiled"
How can passkeys be used to fingerprint you? The WebAuthN extension goes to pretty great lengths to avoid fingerprinting.
3 replies →
The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.
Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.
The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.
What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
> What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
This feels more like CYA/shifting the blame for me. If a service is designed so that I will lose all my data if I lose the passkey, then a "yo, don't lose that passkey, like, ever!" warning is the minimum, but doesn't solve the problem.
I found the initial suggestion "don't ever use passkeys for encryption of persistent data" more reasonable.
(Or what the sibling comment describes: Design the encryption in such a way there is an alternate key that could be used for decrypting)
I think the idea behind PRF was something like "use this as one of several keys", never as "use this the only key". I don't think this was explicitly called out in the specs, though.
> this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion
That sounds like a reasonable idea, but still doesn't help with the case of a completely deleted/destroyed authenticator, e.g. a lost Apple/Google account or Yubikey.
The only viable solution to me for mass adoption is restricting (by recommendation, since there's no way to programmatically enforce it) PRF to scenarios where it's only one out of several ways to get access back. Some password managers do this, e.g. they encrypt their master secret under a PRF-derived key, but this is not the only way/place to get to the master secret, and they also encourage printed key backups etc.
This story of a user deleting their passkey doesn't seem plausible to me. They don't remember why they have a specific passkey for a messaging app? Surely recognizing the app that stores so many memories is enough not to delete the passkey. And why are they "cleaning up" their passkeys in the first place? Yes I put "cleaning up" in quotes, this metaphor, suggesting that a long list of unused passkeys is dirty in some way is inappropriate.
If an app has a billion users, how many do you expect will delete their passkey for no reason? Is this more important then end-to-end encryption for everyone?
If deleting one's passkey for no reason was a thing, I'd expect a real story about a real user, rather then a made-up scenario.
The essay has a condescending attitude towards the normie computer user who can't possibly be expected to know, but it's precisely the normie computer user who would never get the stupid idea of "cleaning up" their passkeys in the first place -- that's something only a nerd with a neurotic attitude to their computer would do.
This past weekend I watched as my mom discovered the password manager in Chrome, and started deleting every entry she couldn't immediately recognize. "Why is this here? I don't need this"
Despite me pleading that they got there for a reason, and takes zero storage, she was confident she didn't need these passwords. So I can totally see her deleting passkeys; my mom is basically Erica, there need to be very explicit implications stated for every action presented and not assume innate understanding
This is the kind of real world example of computer use that I missed in the article.
I consider myself pretty sophisticated with passkeys (I wrote a toy implementation of WebAuthN once to understand them better), and yet I still get tripped up by this sometimes: Not via intentional deletion, but accidental overwriting.
As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.
Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.
What you describe is annoying but not an issue if the website doesn’t use the passkey for encryption - so definitely a good recommendation
It's more likely for them to accidentally be deleted (or otherwise lost access): in my experience approximately zero users actually understand where their passkeys are stored, and they can be all over the place: the number one question I get is 'why can't I log in?' because they've accepted a passkey setup dialog on one machine without really reading it and now can't log in on another. Sometimes it's on the same machine but in different contexts. No passkeys should be considered something that the average user is going to reliably hold onto (in large part because the industry has been so keen to foist them on users but not very keen at all to educate them on how they work. This also makes them a lot less useful from a security point of view because it means you can't get rid of the recovery process, which tends to be the weaker link).
This is 100% spot on.
Passkeys are a mystery, and no one bothers to explain what they are, what it means, how it works, what to do, what to avoid.
I'm not an average user - MA in Mathematics, Ph.D. in Computer Science, 27 years of experience as a developer. I have a vague idea that a passkey is like a password, but you don't see it and don't type it and it's stored "somehow, somewhere."
I can't make much sense of that. How is an "average user" suppose to make sense of that?
When I try to find out how passkeys work, I get some incomprehensible gibberish about self-signed certificates, public/private key pairs, challenges, and on and on. In short, a Monad is just a monoid in the category of endofunctors of X, with product (X) replaced by composition of endofunctors and unit set by the identity endofunctor. What's the big deal?
Since any device that stores a passkey can be lost or destroyed at any moment, I assume any passkey can be lost at any moment, and there had better be a way to recover from that. Is there? Who knows.
> in my experience approximately zero users actually understand where their passkeys are stored
Passkeys are designed to be hidden from the user. The author of this article even went on GitHub telling an open source implementation to not let users copy the private key.
https://github.com/keepassxreboot/keepassxc/issues/10407
There is a good reason for it. If you can copy and paste your passkey, then a phishing site can just ask you for it, making the phishing protection passkeys provide moot.
But the consequence is people, including many technical users on this website, cannot get a grasp on passkeys both as a concept and in a literal sense. How can you perceive, let alone understand, something that is designed to be hidden from you? It also doesn't help that it was pushed on users with little explanation and comes with many seemingly incompatible implementations.
Unless passkeys are redesigned to solve the intangibility problem, grannies will keep losing their accounts for no good reason and we will keep arguing about it on HN.
the problem so far is UI and incompatibility across devices, OSes etc. I am a big fan of Passkeys and the idea of using PRF for E2E encryption, but I wouldn't implement that as now, there is almost zero control over where those passkeys are, how I can recover them, how I manage them. Whenever I have to switch computer (mandatory policy at work), or phone (mandatory obsolence) or if I want to work across OSes (Mac for work, Windows for fun), everything falls apart, incomprehensible interfaces, inexistent transparency and control. And I'm a pro user that has actually studied how the standard works.
I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.
> And why are they "cleaning up" their passkeys in the first place?
The same reason they're cleaning up their Windows or system32 folder.
Security is important, security is important, security is important — I keep emphasizing this point. But for me, that statement only really applies to people who genuinely understand security. I personally bought two YubiKeys, understand the associated risks, and store my credentials on those YubiKeys. However, many people today do not realize the risks involved. They casually store these things in places like a keyring and then never manage them properly. That does not necessarily mean they are secure. On the contrary, it can become another kind of danger, because once you start using passkeys, the level of access and authority tied to them is significant. If they are lost or leaked, the consequences can be disastrous. I am glad to see that the industry is paying more attention to security, but at the same time, I believe these more specialized aspects should be aimed at people who actually have the relevant expertise. Passkeys do have a learning curve. For ordinary users, they often just click through a few prompts and end up binding themselves to a system without really understanding what happened. On top of that, with modern systems relying on encryption and TPM, once a computer runs into serious problems, many people simply have no way to recover their data. For the average user, 2FA is already sufficient.
> Don't use passkeys
Better title.
Mom can't figure out what they are or how to use them. They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck (yeah yeah multiple devices and paths to auth and backup codes, none of that matters). It's one further step down the attested hardware software and eyeballs path. Passwords forever, shortcomings be damned.
Unfortunately some vendors are now REQUIRING passkeys; specific example:
https://www.healthequity.com
> As of October 2025, passkey login has been fully rolled out and is now required for members with Health Savings Accounts (HSAs) and Reimbursement Accounts (RAs) who use the HealthEquity Mobile app and web experience.
https://help.healthequity.com/en/articles/11690915-passkey-f...
The FAQ is a little misleading by saying WHEN your account has a passkey this and that, but reality is that after October they made them completely mandatory, no bypass, no exceptions. 100% coverage.
Oh, and by the way, passkeys have been broken on PC/Linux when using Firefox for months:
> There Was A Problem: We encountered an error contacting the login service. Please try again in a few minutes.
Neat. You have to use Chrome or Edge.... For months, after making it mandatory...
That's weird, I can login to my HealthEquity account (which contains HSA) without any issues and I don't have passkey setup. I confirmed it just now just in case.
That article does say "HealthEquity Mobile and web experience" so maybe it's just for customers who use both, I only use web.
1 reply →
side note, HSAs are also a symptom of a failed Healthcare system
1 reply →
>They bind you to your device/iCloud/Gaia account so if it gets stolen/banned you're out of luck
This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.
And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.
First, in relation to TFA: even if you regain access through a recovery channel, any data that was encrypted using your lost passkey will now be gone.
There are also many exciting new ways you can lose your passkey that wasn't the case with a password you can remember in your mind. The person you responded to is worrying about big tech randomly banning you and making you lose access, in the meanwhile I'm mostly worried about losing the physical device containing the key. I don't think I will forget, say, my Google password unless I got Alzheimers or got hit in the head by a hammer, at which point I will have bigger problems than a lost Google account.
And let's not pretend account recovery process is always smooth and easy. They may require evidence from your other accounts you cannot access now due to the key loss. They may demand government IDs that might have been lost alongside your device. They may also just deem your recovery attempt fraudulent and ban you for no reason (which I similar to the scenario the post you are replying to desctibed.)
Genuine question: what if the recovery asks for a 2nd factor that's e.g. the device which you lost? Is that common?
Personally I don't really trust companies to not do a whoopsie and permanently lock you out when you lose credentials. Especially when the company is big or hard to access in person.
For someone like me who already uses a password manager for everything, passkeys seem to add no security while reducing usability and control.
2 replies →
I'm also completely against passkeys. A safe password and a good password manager are way better, they don't lock you into any platform.
It's super sad to see all kinds of websites offering you to add a passkey when you log in.
> A safe password and a good password manager are way better, they don't lock you into any platform.
An open, cross-platform passkey implementation does all that too, and on top of that prevents you from accidental password leaks via logs, MITM etc. by default.
> It's super sad to see all kinds of websites offering you to add a passkey when you log in.
As long as they're not forcing you to add one, what exactly is your problem with having more choice?
Personally, I am grateful for every site that doesn't require my phone number to sign up and uses passkeys for authentication instead, yet I also don't want SMS authentication banned for everybody since I understand it currently works better than Passkeys for many people.
passkeys are a great idea, but poorly implemented
I was planning to make use of passkeys when logging on to various services, so I ordered three physical devices, supporting passkeys (yubikey). I ordered USB C and USB A variants, with NFC support.
Is this a mistake? I am already using password manager and totp for my accounts, but I am tired of dealing with passwords.
Even when using a password manager (bitwarden in my case), it just get tedious bringing out my phone, starting auth app, locating the correct account, reading 6 digit token and logging on.
2 replies →
I love passkeys in my selfhosted vaultwarden, but I agree the UX for older people is not quite there.
Passwords are terrible UX for old people in my experience. They try use the same password everywhere, but then password complexity requirements mean they can't use the exact same password everywhere, and then they forget which variant they used on which service, so they just end up going through the reset password flow every time they sign in. I am not convinced that's a better UX than them just using their fingerprint or face to login.
> They bind you to your device
Isn't it why good practice is to bind at least 2 hardware passkeys and/or have recovery codes?
Sure someone can steal your phone/laptop/yubikeybio but then you can use the NitroKey you have at home in your drawer to recover your account.
Biometric keys are still a niche techie thing that the average person probably doesn't even know exist. Most people will be using passkeys exclusively through their phones, often unintentionally. And outside the first world it is not uncommon for people do own no computing devices apart from their phones.
Backup keys and recovery codes also do not solve all cases of key loss. One thing I worry about is what happens if I am traveling in a foreign country and loses my belongings. In the past if I can convince someone to let me use his computer I can at least log into my email account as long as I remember my password. If everything is passkey then I will be locked out of all my online accounts until I make it back home, assuming that I have actually properly set up the backup device and keys. Humans are not very good at making sure that backups actually work.
2 replies →
You can’t expect your grandma to go to those lengths. Heck, even most internet-native people probably wouldn’t.
2 replies →
KeepassXC has exportable passkeys, so you can avoid the stolen case at least.
Too bad the spec is stupid and requires password managers to be identifiable so servers can deny the "insecure ones". It's already a pain to use Keepassxc for otp since they all want you to use their apps but it's still doable (the worst offender being steam where you have to hack your own app to extract the otp secret). With passkeys you won't have a choice to use The Google AuthenticatorTM etc because eventually some exec will find they can block every provider except their own to boost app download KPI. I really like concept of passkeys, the simple fact of using asymmetric keys is so much better than giving the secret to prove you have it, but the spec is hostile and thought for vendor closing.
1 reply →
> exportable passkeys
But didn't the author hint that this could get blocked?
My general read on passkeys and their implementers is that exportability is seen as a risky feature, and there's a push to make it as opaque as possible, likely through attestation or similar mechanisms.
[1]: https://github.com/keepassxreboot/keepassxc/issues/10407
Also a password could be the passkey, the passkey protocol is basically a way to send to a server an authenticated public key. The client could deterministically convert passwords to key-pairs and authenticate with those
> They bind you to your device/iCloud/Gaia account
Then don't use Apple's/Google's/whatever Gaia is as your passkey provider?
> Mom can't figure out what they are or how to use them.
Then do something nice for your mom and set her up with Bitwarden, 1Password or KeepassXC, which prevents the platform lock-in.
> It's one further step down the attested hardware software and eyeballs path.
None of the synchronized passkey implementations, which big tech has been pushing lately, support attestation, so this is just FUD.
Yubikeys do, but fortunately they don't seem to have the (non-enterprise) weight to make it mandatory for all passkeys.
Nothing in this post is specific to passkeys; it reads like advice to not encrypt data. There’s no way to prevent some users from losing their encryption key anyway. Whatever warnings you include, even when software doesn't connect to the internet and just encrypts local files, someone will write to support that they forgot their password and ask you to "reset" it.
Good advice at the end, though.
The issue I think is that passkey managers don’t make it clear that deleting a passkey can cause permanent data loss
Because passkey managers have no idea what a service is using its passkey for. They could warn that deleting a passkey could make all sort of bad things happen, but for most services it will be only the loss of access. What the alternative could be? "Before deleting this passkey you must contact this site and ask them what data you will loose. I give you a week. Come back here a week from now and confirm your desire to delete this passkey. I will not make you delete it before that day. See you!"
2 replies →
There's a big difference between being kept in the dark and being informed but careless.
> "Even if there were explanatory text, Erika, like most users, doesn’t typically read through every dialog box, and they certainly can’t be expected to remember this technical detail a year from now."
Passkeys are a step in the right direction, ironically for the exact reason the author advises caution. We've been telling people to "store your backup key somewhere safe" for the best part of a decade now, and your average Erika hasn't got on well with that at all. Locking themselves out and losing data left, right and centre.
If you've worked at any kind of scale you'll know well that a certain percentage of users will lose their data with E2EE, full stop. It's just different from everything else they've ever used. These are the same people who'd be lost without the "forgot password" link, and there's no shame in that. That's just the reality of it. And passkeys can help people like this to not lose their keys.
If the product is truly E2EE, the best options right now are the passkey implementations baked into Chrome or Apple. Windows, as ever, needs a bit of work, but the password managers seem to be picking up the slack well enough. We also need to educate people that with true E2EE there is no "forgot password" email. Passkeys and the tooling around them still have a ways to go, but we're getting there.
How many people are doing a spring cleaning of unused passkeys in their password managers? We're talking like a kilobyte of data, nobody needs to delete these things in any kind of normal circumstance.
Sure, it would be great if users would store 5 copies of their encryption keys, with one in a lockbox on the bottom of the ocean. But that's just not going to happen at any kind of scale, so an automatic way of putting encryption keys in a replicated password manager makes sense. And compared to how people normally handle end-to-end encryption keys, it's going to result in a lot less loss data in practice.
I don't know about spring cleaning, but it's pretty easy to delete by accident if you connect to the browser or OS when setting up instead of the password manager.
That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.
Most password managers implementing passkeys only allow one passkey per account entry, and I've ended up with multiple passkeys per site, while the site only supports one (and deletes the others upon creating a new one), so I've been in the exact situation of not knowing which entries are safe to delete before.
This is usually due to relying party and possibly password manager bugs, but it does happen.
I thought the point of passkey security is that you don't have to send the private key around, it can stay on your device. Different passkey per device. Lose or destroy a device, delete that passkey and move on.
The issue there being there's a big usability headache with enrolling multiple devices. You really want one device to be able to enroll all your devices (including not-present and offline), but there's no mechanism to do this with the way the webauthn spec works at the moment.
1 reply →
None of the password managers (including but not limited to ones built-in iOS/Android) work that way. The Apple one (and I think Google is the same) keeps the private key inside the secure enclave (security processor), but it is still copied to each new device - though it is end-to-end encrypted during that transmission.
1 reply →
That’s how I use them. Passkeys on two Yubikeys. And I tag in my password manager which credentials have what form of auth. UP, TOTP (also stored on the two Yubikeys), Webauthn or passkeys (the former indicating 2FA).
If the user deletes passwords they're shown the same exact message. The only saving grace for passwords is that you can remember them, but are you also suggesting to not use generated passwords?
I think the distinction is that a passkey is meant to be used for authentication (logging in), and is usually not the only way you can authenticate. If you delete your password, passkey, or 2FA method, you can still go through a "forgot password" flow.
Encryption is different. If you encrypt data with a generated password and then delete it, you're toast, and passkeys are no different. I think the author is arguing that users may not even realize that the passkey itself is needed to decrypt, possibly because they're so associated with login.
for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.
1 reply →
You're just saying that the user needs to be aware that you cannot forget or delete a password, which applies just the same way to passkeys.
Passkeys are effectively just long passwords you cannot see. The mechanism is just gravy.
1 reply →
> you can remember them, but are you also suggesting to not use generated passwords?
You can remember a strong generated password if it's a pass phrase. Better "rememberability" with the same amount of entropy.
Generated passwords can be useful, but they come with challenges like management and security. It's better to adopt approaches like password managers or biometrics to enhance usability while maintaining security.
Somewhat related, i recently ran into the issue, after i created an account on Confer.to [1] on my Desktop, i couldn't login on my iPad / iOS with Proton Pass and/or Bitwarden.
The error message was: "Error: "Authenticator did not return a PRF result — this passkey probably isn’t PRF-capable."
So i now have an account, but can only use it on my Desktop. (can't change to a password login either, it's Passkeys only...)
[1] end-to-end encrypted AI, developed by Moxie Marlinspike, the founder of Signal: https://confer.to/
Sounds like the website did a shitty job at implementing passkeys. I’ve read through the guides and done it myself and yes there are a lot of gotchas and they’re all avoidable.
It is conundrum that passkeys were designed to help the majority as they are frictionless (like passwordmanagers etc) but fail in reality.
Even those that have 2 devices they don't have them all the time.
Another overlooked issue is that some banks etc don't allow for 2 devices as login or 2FA. Even if it allowed one needs to keep the spare device always updated. Either Govt needs to build a common API that one can use directly through google pay or apple pay - so that only one app is needed to be kept up to date.
to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them - but at least then if I lose the phone - and I show my ID they should allow me to setup my new phone. But that is also not possible. (I am discounting the awful AI bans)
You're thinking about hardware authenticators, not Passkeys. Passkeys are definitionally synchronized and backed up in the cloud (otherwise you just have a sparkling WebAuthN authenticator).
Proprietary clouds and sync backends create their own set of problems, but they do solve the availability issue of always having to register at least two different security keys with each service.
> to be honest, I wouldn't mind if google/Apple can take all my private data and passkeys hold them
That's exactly what you can do today!
> I show my ID they should allow me to setup my new phone.
You have to show them your phone number, which for better or worse is our age's "showing ID", but then you can indeed get back in.
This is why I haven't started using passkeys. Managing them is looks complicated and I don't understand the ramifcations of what I'm doing.
Also a style nit, it's OK to use "he" or "she" pronouns in a contrived narrative. The "they/their" usage really detracted from the clarity of the example.
The author's concern of "misgendering" an imaginary person (with ab unambiguously female name) is quite odd.
I don't think I would have even realized why I felt tension reading if you hadn't mentioned this. They/their wasn't confusing at all but, giving the hypothetical user a name was the weird part. I realize now I was expecting some other user to enter the scenario the whole time. Alice and Bob style. When I got to the end, I felt like I missed something. If there's just one, "the user"/"they"/"their" is fine.
Passkeys to me come across as a part solution to a valid problem. Education is part of the solution. Treating the user as too dumb to understand why they need strong passwords or passkeys is important.
I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
I use passkeys from keepasxc because the native workflow for passkeys is opaque and easy to misunderstand what you are actually doing. And it's predicated on having an account with big us tech companies.
> I actually despair about when my family members are forced into passkeys and then lose access to their accounts because they get a new device.
Both iOS and Android sync passkeys to their respective cloud accounts by default. (Of course, losing access to that account, sharing one across family members and causing confusion etc. are still concerns.)
The real problem is lock-in, as this effectively often prevents entire families from switching from iOS to Android or vice versa. I'd encourage anyone managing their family's tech setup to pick a platform-agnostic passkey implementation such as 1Password or Bitwarden for that reason.
Honestly we peaked at Hardware U2F keys. Passkeys were a step backwards.
They were secure, scalable, and they were simple to explain to my parents ("This is a physical key for your email account; like your front door key").
I love the idea of hardware keys, and would absolutely use them for the essential stuff (email, domain registrar, bank) but they're just too expensive, while plain old TOTP 2FA is free and provides 99% of the benefits for my use case. TOTP also has a much better workflow in my experience, but this isn't that big of a problem for the things I'd consider essential, but it would be annoying if I were to use a hardware key for everything.
I can buy 6-8 physical keys for the front door of my house for the cost of one Yubikey. Even though there are options at half price, that then gets eaten into by the need to have two or three of them, since a backup is not optional for this sort of use case. I can't imagine convincing one's parents to buy 'a key for your email account' will be easy when the old way mostly 'worked fine' and was free, meanwhile the new one will cost them a non-trivial amount of money. It's an easy flow if you're their sysadmin, but I wouldn't want to throw my parents into the deep end of hardware keys and have to explain to them that they don't need the expensive one, but still have them be discouraged by the mere existence of 100+ dollar options for what should be damn-near throwaway hardware.
Passkeys somehow manages to have a worse workflow than both though.
Don't use Passkeys.
(Or at absolute minimum don't force them on unsuspecting users, make them opt-in, not opt-out frequently at random times (Amazon!!!).)
I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys:
https://words.filippo.io/passkey-encryption/
The crazy thing is that for a non synced device bound passkey you are tying that user to the device forever.
Probably everything else is debatable, I do agree with one thing though, the cat is indeed out of the bag. It would have been probably a really good use case if the scope was limited to only hardware based security keys for enterprise users only. Rolling it out for OS platforms, software based authenticators just muddies the water. You cannot even provide any guarantees around it being phishing resistant anymore.
The title could've been shorter: don't use passkeys. Period.
I was looking into this to start using this. Because it’s quite user friendly to not let the user worry about all the details that involve encryption of data.
I guess informing them is a good way to start. Are there any other tips on how this can be improved?
So... Don't use the PRF extension for its declared purpose? I really wonder how people keep getting Passkeys wrong!
If no one can implement a specification without causing problems here and there, perhaps we should consider the specification itself problematic.
See also: Bluetooth.
Passkeys aren’t going to make it unfortunately but that’s ok.
They’ll teach us what we need to know to create something that will do what they’re trying to do.
Trezor support FIDO2 tied on the seed phrase, so if you lost it another hardware wallet will works issueless once restored.
On a similar note mooltipass can export an encrypted backup of passkeys. That said platform should support multiple passkeys so if you lose access to one you arent screwed over.
In the end we are talking about "smart-card-alike" auth, something there since decades, cheap, functional, safe and apparently ignored by most.
Curiously biometric crap is not ignored as well instead, and is pushed by any means...
Another way to say this is that you have to have an account recovery process and you need to think about how your encryption interacts with account recovery.
Still android doesn't support NFC in combination with resident passkeys.
It does if you use microg or authnkey or keepassdx.
It's Play Services that does not support this combination, likely to shepherd you towards Google acoount usage. Alternate Android apps work fine.
I don't use passkeys because I am scared that I will not be able to recover my account with my email address.
Why wouldn’t you?
100% of the arguments against using passkeys for e2ee data apply to using passkeys as credentials.
(Unless they are not credentials, and you can loose them then do a password reset via a phishing prone channel like email and SMS. Supporting this eliminates any possible user benefit of passkeys.)
In addition to the arguments in the article, when used as credentials, they are an obvious trojan horse allowing large websites to completely hijack your operating system.
Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android. This is where passkeys are taking PCs, and it is their only purpose.
So, “Don’t use passkeys” would be a better title.
> Don’t believe me? Try logging into a bank or using rideshare/parking/ev charging with degoogled android.
What does root detection and other device attestation have to do with passkeys? Passkeys (at least Google's and Apple's) don't support device attestation.
Passkeys are an open standard? You might as well argue against SSH keys.
The standard includes a hardware attestation path.
That’s the backdoor allowing the eventual takeover of your OS.
First people use passkeys, and they become standard.
Then they become required for important accounts for security.
Then the important accounts require the attestation bit.
At that point, you cannot run web browsers on open source operating systems.
This is all boring and predictable. It is exactly what they did with Android, and exactly the same organizations are pushing passkeys.
Note: If they had good intentions, the operating system would manage any attestation, and not allow websites to query for or require attestation support.
11 replies →