9 ms·

Don't use passkeys for encrypting user data

280 points by zdw 8mo ago

halapro 8mo ago
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?
- bensyverson 8mo ago
  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.
  - dansjots 8mo ago
    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.
    - johncolanduoni 8mo ago
      Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
  - halapro 8mo ago
    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.
    - Borealid 8mo ago
      I think there is a difference. Sites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written. Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.
- bad_username 8mo ago
  > 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.
- hrmtst93837 8mo ago
  [flagged]
deleted 8mo ago
[deleted]
SoftTalker 8mo ago
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.
- deleted 8mo ago
  [deleted]
- kgwxd 8mo ago
  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.
- bad_username 8mo ago
  The author's concern of "misgendering" an imaginary person (with ab unambiguously female name) is quite odd.
- ezfe 8mo ago
  It's obviously okay to use he or she - not sure why it wouldn't be. I'm confused why you have a problem with the author's choice not to - I don't see any clarify issues caused by it.
dchest 8mo ago
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.
- shepherdjerred 8mo ago
  The issue I think is that passkey managers don’t make it clear that deleting a passkey can cause permanent data loss
  - pmontra 8mo ago
    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!"
    - shepherdjerred 8mo ago
      yeah I feel like metadata could be attached to the passkey so the manager could surface the info
      - NekkoDroid 8mo ago
        While I in theory would love this idea, attaching arbitrary metadata to something and expecting a manager to somewhat "nicely" figure out some text to display for it is just not really scalable unless you limit what those fields can be set to. Mainly cuz just displaying keywords isn't exactly user friendly and having anything longer will also need to get translated for all/most/some languages they manager supports.
dansjots 8mo ago
I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys: https://news.ycombinator.com/item?id=46895533 https://news.ycombinator.com/item?id=46895533 This give much more conscious control to the user knowing that they are explicitly encrypting which file with which passkey. Additionally, you can just download the page and serve it via localhost so that you always have control of the relying party for your passkey. [0] https://words.filippo.io/passkey-encryption/ https://words.filippo.io/passkey-encryption/
wmf 8mo ago
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.
hedora 8mo ago
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.
- inkysigma 8mo ago
  Passkeys are an open standard? You might as well argue against SSH keys.
  - hedora 8mo ago
    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.
    - johncolanduoni 8mo ago
      The attestation actually has nothing to do with the browser, only the holder of the passkey's key material. You can satisfy the attestation by having a passkey on your Android device and doing the normal Bluetooth flow with your Firefox browser on your Framework laptop. So this mechanism is totally useless for enacting this plan. The operating system doesn't manage attestation because that's totally useless for the stated goal of the attestation system. Enterprises don't want their SaaS vendors to accept passkeys from some random employee's BitWarden, instead of the hardware keys they issued the employee. If the OS manages attestation and doesn't send anything to the relying party, then it doesn't solve anybody's problem at all.
peterspath 8mo ago
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?
- deleted 8mo ago
  [deleted]
johncolanduoni 8mo ago
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.
- bo1024 8mo ago
  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.
  - slau 8mo ago
    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).
  - johncolanduoni 8mo ago
    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.
    - deleted 8mo ago
      [deleted]
  - rcxdude 8mo ago
    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.
arjie 8mo ago
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.
- weird-eye-issue 8mo ago
  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
  - OptionOfT 8mo ago
    Embedded WebViews are a way to track you: https://news.ycombinator.com/item?id=32514793 https://news.ycombinator.com/item?id=32514793
  - mgrandl 8mo ago
    I disable them on every app that lets me. It is in every way worse UX than simply opening the browser.
  - dgxyz 8mo ago
    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.
- EnPissant 8mo ago
  You can just use bitwarden everywhere if you are ok with it in the cloud.
akersten 8mo ago
> 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.
- Someone1234 8mo ago
  Unfortunately some vendors are now REQUIRING passkeys; specific example: https://www.healthequity.com 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-faq 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...
  - buzer 8mo ago
    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.
    - saagarjha 8mo ago
      I’ve only used web and they forced me to enroll one.
  - cyanydeez 8mo ago
    side note, HSAs are also a symptom of a failed Healthcare system
kkfx 8mo ago
Trezor support FIDO2 tied on the seed phrase, so if you lost it another hardware wallet will works issueless once restored.
- miladyincontrol 8mo ago
  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.
  - kkfx 8mo ago
    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...
- deleted 8mo ago
  [deleted]
sandeepkd 8mo ago
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.
whyagaintango 8mo ago
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)
- lxgr 8mo ago
  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.
  - faust201 8mo ago
    > have to show them your phone number, Not always working. You can see often in google community support people lost their phone. Get a new sim card and phone. Google sends the 2FA request to old phone - without that they cannot restore data. Double whammy for people that use eSIM that gets sent to their old email address.
cadamsdotcom 8mo ago
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.
Paddyz 8mo ago
[dead]
- lxgr 8mo ago
  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.
- xg15 8mo ago
  > 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)
hbogert 8mo ago
Still android doesn't support NFC in combination with resident passkeys.
- Borealid 8mo ago
  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.
  - hbogert 8mo ago
    yeah just installed it, it's awesome!
deleted 8mo ago
[deleted]
ifh-hn 8mo ago
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.
- lxgr 8mo ago
  > 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.
  - ezfe 8mo ago
    Apple Passwords support export/import of Passkeys - 1Password amusingly does not.
- ezfe 8mo ago
  > 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. People forget and reset passwords all the time. Passkeys are no different, except now they'll lose them less.
seanieb 8mo ago
> "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.
jgb1984 8mo ago
The title could've been shorter: don't use passkeys. Period.
- ezfe 8mo ago
  Why not?
amadeuspagel 8mo ago
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.
- Telaneo 8mo ago
  > And why are they "cleaning up" their passkeys in the first place? The same reason they're cleaning up their Windows or system32 folder.
- rcxdude 8mo ago
  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).
  - pibaker 8mo ago
    > 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 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.
darkhorn 8mo ago
I don't use passkeys because I am scared that I will not be able to recover my account with my email address.
- ezfe 8mo ago
  Why wouldn’t you?
lxgr 8mo ago
So... Don't use the PRF extension for its declared purpose? I really wonder how people keep getting Passkeys wrong!
- pibaker 8mo ago
  If no one can implement a specification without causing problems here and there, perhaps we should consider the specification itself problematic. See also: Bluetooth.
DavideNL 8mo ago
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/ https://confer.to/
- ezfe 8mo ago
  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.
- peterspath 8mo ago
  Some password managers do not support the PRF extension yet. ProtonPass is one of them that does not: https://www.passkeyprf.com https://www.passkeyprf.com
daft_pink 8mo ago
The crazy thing is that for a non synced device bound passkey you are tying that user to the device forever.
- deleted 8mo ago
  [deleted]
- ezfe 8mo ago
  Yes, if you use passkey to encrypt user data - which is clearly a bad idea because passkeys are not designed for that. Obviously passkeys do not bind a user to a specific device in any other context.
OJFord 8mo ago
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!!!).)
exabrial 8mo ago
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").
- Telaneo 8mo ago
  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.
  - exabrial 8mo ago
    Agree on TOTP actually! It’s less secure (can be intercepted) but it’s still miles ahead of anything else
dennysora 8mo ago
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.
rkagerer 8mo ago
Is it possible to disable passkey support in Chromium and have it tell websites that feature is unsupported? So you no longer get prompted to create them? (On a global or per-site basis)
- rkagerer 8mo ago
  Since this is getting downvoted, let me explain: I don't want any cloud service to be my passkey provider. I'm not comfortable establishing that kind of dependence on a company I don't trust. I'd be content to keep passkeys in a datastore that I control, and which I can inspect and manage on my own (including backup, restore, and ideally even daily migration to a "hotspare" device). As more websites adopt passkeys, I find myself continually being nagged to adopt them. Although their intent is benign, the companies use dark UI patterns like not respecting my choice after I've said NO (there isn't a "Never" option, just a "Skip for now"), and they continually shove the unwanted reminders in my face every time I login. My concern is eventually I'll accidentally hit the wrong button and create an unwanted passkey that's now tied to my machine/cloud account/vendor service in a way I don't control. I'm fact, I'd bet product managers are counting on that manipulation (nag the user until they concede) to brag about adoption rates and get raises. My browser is supposed to me my agent, so I think it's a valid question - and related to this topic - to ask if there's a way to turn off the unwanted functionality.
  - timmyc123 8mo ago
    You can use any credential manager you choose. It is an open ecosystem. If you don't want to use a cloud service, don't. You can self-host many credential managers. There are also many solutions that just use a local database.
Pesthuf 8mo ago
Maybe we could add an extension to webauthn that adds a reason to a passkey. Then, the credential manager can warn the user better why deleting the passkey would be a bad idea.
JCharante 8mo ago
Who is deleting passkeys? It’s like 1 kb of data

280 points by zdw 8mo ago

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?

bensyverson 8mo ago
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.
- dansjots 8mo ago
  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.
  - johncolanduoni 8mo ago
    Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.
- halapro 8mo ago
  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.
  - Borealid 8mo ago
    I think there is a difference. Sites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written. Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.
bad_username 8mo ago
> 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.
hrmtst93837 8mo ago
[flagged]

deleted 8mo ago

[deleted]

SoftTalker 8mo ago

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.

deleted 8mo ago
[deleted]
kgwxd 8mo ago
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.
bad_username 8mo ago
The author's concern of "misgendering" an imaginary person (with ab unambiguously female name) is quite odd.
ezfe 8mo ago
It's obviously okay to use he or she - not sure why it wouldn't be. I'm confused why you have a problem with the author's choice not to - I don't see any clarify issues caused by it.

dchest 8mo ago

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.

shepherdjerred 8mo ago
The issue I think is that passkey managers don’t make it clear that deleting a passkey can cause permanent data loss
- pmontra 8mo ago
  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!"
  - shepherdjerred 8mo ago
    yeah I feel like metadata could be attached to the passkey so the manager could surface the info
    - NekkoDroid 8mo ago
      While I in theory would love this idea, attaching arbitrary metadata to something and expecting a manager to somewhat "nicely" figure out some text to display for it is just not really scalable unless you limit what those fields can be set to. Mainly cuz just displaying keywords isn't exactly user friendly and having anything longer will also need to get translated for all/most/some languages they manager supports.

dansjots 8mo ago

I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys: https://news.ycombinator.com/item?id=46895533 https://news.ycombinator.com/item?id=46895533 This give much more conscious control to the user knowing that they are explicitly encrypting which file with which passkey. Additionally, you can just download the page and serve it via localhost so that you always have control of the relying party for your passkey. [0] https://words.filippo.io/passkey-encryption/ https://words.filippo.io/passkey-encryption/

wmf 8mo ago

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.

hedora 8mo ago

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.

inkysigma 8mo ago
Passkeys are an open standard? You might as well argue against SSH keys.
- hedora 8mo ago
  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.
  - johncolanduoni 8mo ago
    The attestation actually has nothing to do with the browser, only the holder of the passkey's key material. You can satisfy the attestation by having a passkey on your Android device and doing the normal Bluetooth flow with your Firefox browser on your Framework laptop. So this mechanism is totally useless for enacting this plan. The operating system doesn't manage attestation because that's totally useless for the stated goal of the attestation system. Enterprises don't want their SaaS vendors to accept passkeys from some random employee's BitWarden, instead of the hardware keys they issued the employee. If the OS manages attestation and doesn't send anything to the relying party, then it doesn't solve anybody's problem at all.

peterspath 8mo ago

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?

deleted 8mo ago
[deleted]

johncolanduoni 8mo ago

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.

bo1024 8mo ago
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.
- slau 8mo ago
  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).
- johncolanduoni 8mo ago
  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.
  - deleted 8mo ago
    [deleted]
- rcxdude 8mo ago
  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.

arjie 8mo ago

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.

weird-eye-issue 8mo ago
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
- OptionOfT 8mo ago
  Embedded WebViews are a way to track you: https://news.ycombinator.com/item?id=32514793 https://news.ycombinator.com/item?id=32514793
- mgrandl 8mo ago
  I disable them on every app that lets me. It is in every way worse UX than simply opening the browser.
- dgxyz 8mo ago
  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.
EnPissant 8mo ago
You can just use bitwarden everywhere if you are ok with it in the cloud.

akersten 8mo ago

> 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.

Someone1234 8mo ago
Unfortunately some vendors are now REQUIRING passkeys; specific example: https://www.healthequity.com 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-faq 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...
- buzer 8mo ago
  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.
  - saagarjha 8mo ago
    I’ve only used web and they forced me to enroll one.
- cyanydeez 8mo ago
  side note, HSAs are also a symptom of a failed Healthcare system

kkfx 8mo ago

Trezor support FIDO2 tied on the seed phrase, so if you lost it another hardware wallet will works issueless once restored.

miladyincontrol 8mo ago
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.
- kkfx 8mo ago
  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...
deleted 8mo ago
[deleted]

sandeepkd 8mo ago

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.

whyagaintango 8mo ago

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)

lxgr 8mo ago
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.
- faust201 8mo ago
  > have to show them your phone number, Not always working. You can see often in google community support people lost their phone. Get a new sim card and phone. Google sends the 2FA request to old phone - without that they cannot restore data. Double whammy for people that use eSIM that gets sent to their old email address.

cadamsdotcom 8mo ago

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.

Paddyz 8mo ago

[dead]

lxgr 8mo ago
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.
xg15 8mo ago
> 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)

hbogert 8mo ago

Still android doesn't support NFC in combination with resident passkeys.

Borealid 8mo ago
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.
- hbogert 8mo ago
  yeah just installed it, it's awesome!

deleted 8mo ago

[deleted]

ifh-hn 8mo ago

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.

lxgr 8mo ago
> 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.
- ezfe 8mo ago
  Apple Passwords support export/import of Passkeys - 1Password amusingly does not.
ezfe 8mo ago
> 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. People forget and reset passwords all the time. Passkeys are no different, except now they'll lose them less.

seanieb 8mo ago

> "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.

jgb1984 8mo ago

The title could've been shorter: don't use passkeys. Period.

ezfe 8mo ago
Why not?

amadeuspagel 8mo ago

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.

Telaneo 8mo ago
> And why are they "cleaning up" their passkeys in the first place? The same reason they're cleaning up their Windows or system32 folder.
rcxdude 8mo ago
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).
- pibaker 8mo ago
  > 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 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.

darkhorn 8mo ago

I don't use passkeys because I am scared that I will not be able to recover my account with my email address.

ezfe 8mo ago
Why wouldn’t you?

lxgr 8mo ago

So... Don't use the PRF extension for its declared purpose? I really wonder how people keep getting Passkeys wrong!

pibaker 8mo ago
If no one can implement a specification without causing problems here and there, perhaps we should consider the specification itself problematic. See also: Bluetooth.

DavideNL 8mo ago

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/ https://confer.to/

ezfe 8mo ago
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.
peterspath 8mo ago
Some password managers do not support the PRF extension yet. ProtonPass is one of them that does not: https://www.passkeyprf.com https://www.passkeyprf.com

daft_pink 8mo ago

The crazy thing is that for a non synced device bound passkey you are tying that user to the device forever.

deleted 8mo ago
[deleted]
ezfe 8mo ago
Yes, if you use passkey to encrypt user data - which is clearly a bad idea because passkeys are not designed for that. Obviously passkeys do not bind a user to a specific device in any other context.

OJFord 8mo ago

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!!!).)

exabrial 8mo ago

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").

Telaneo 8mo ago
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.
- exabrial 8mo ago
  Agree on TOTP actually! It’s less secure (can be intercepted) but it’s still miles ahead of anything else

dennysora 8mo ago

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.

rkagerer 8mo ago

Is it possible to disable passkey support in Chromium and have it tell websites that feature is unsupported? So you no longer get prompted to create them? (On a global or per-site basis)

rkagerer 8mo ago
Since this is getting downvoted, let me explain: I don't want any cloud service to be my passkey provider. I'm not comfortable establishing that kind of dependence on a company I don't trust. I'd be content to keep passkeys in a datastore that I control, and which I can inspect and manage on my own (including backup, restore, and ideally even daily migration to a "hotspare" device). As more websites adopt passkeys, I find myself continually being nagged to adopt them. Although their intent is benign, the companies use dark UI patterns like not respecting my choice after I've said NO (there isn't a "Never" option, just a "Skip for now"), and they continually shove the unwanted reminders in my face every time I login. My concern is eventually I'll accidentally hit the wrong button and create an unwanted passkey that's now tied to my machine/cloud account/vendor service in a way I don't control. I'm fact, I'd bet product managers are counting on that manipulation (nag the user until they concede) to brag about adoption rates and get raises. My browser is supposed to me my agent, so I think it's a valid question - and related to this topic - to ask if there's a way to turn off the unwanted functionality.
- timmyc123 8mo ago
  You can use any credential manager you choose. It is an open ecosystem. If you don't want to use a cloud service, don't. You can self-host many credential managers. There are also many solutions that just use a local database.

Pesthuf 8mo ago

Maybe we could add an extension to webauthn that adds a reason to a passkey. Then, the credential manager can warn the user better why deleting the passkey would be a bad idea.

JCharante 8mo ago

Who is deleting passkeys? It’s like 1 kb of data