Hacker News Reader

Comment by arjie | Hacker News Reader

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.

View on HN

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.

Passkeys IMO will only work with dedicated U2F/FIFO keys like Yubikeys.

Beware that Passkey storage is limited though and I don't think you can reuse one for multiple sites. My Yubikey 5 NFC stores up to 32 and you should have some redundancy if you ever lose it. You also can't export them. I only use passkeys (in Bitwarden) for things I don't care about.

As someone who's looking into possibly getting a YubiKey 5 NFC actually, I would like to ask: if you can't export the entries, if you make a backup of the YubiKey (perhaps with the magic of buying two of them), then how would one ensure redundancy?

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.

Yeah, definitely don’t mix work and personal credentials. But many password managers allow using different accounts/vaults on one machine.

Your Bitwarden should enforce the necessary 2-Factor auth for this scenario, but if you’re worried just make sure to be careful when registering that single passkey.

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

Does their Firefox extension not inject its own WebAuthN implementation into every visited site on Linux? It does for me on macOS (i.e. it overrides the OS/browser-provided one).

Is this really how password managers extensions work? They inject arbitrary javascript in every page you visit?

I would have naively thought that there'd be a better and safer API for it, considering that all browsers already have the infrastructure in place to handle login autocomplete.

Yes. This is mandatory for all browser extensions. There's no API behind a separate permission, even if would be the best way to handle this.

As someone that uses a YubiKey for WebAuthN - I really wish Bitwarden didn't do this. I know I can turn it off, but it's a bad default.

The problem with passkeys is that they aren’t exportable (at least from Bitwarden).

They are easily exportable from Apple and 1Password AFAIK. Bitwarden seems to be doing some interesting lock-in, and while I have loved them, I no longer have a commercial password manager that I trust (leaving me with only Apple's as a high-functioning, high-trust option). I'm worried about effects of private equity pressure on groups like 1Password, Bitwarden, and LastPass (I strongly recommend against LastPass these days).

Bitwarden's format is at least implicitly documented via their open-source clients, and as a sibling comment already has mentioned, their data export includes all private/secret key material.

Actually, if you export your vault as JSON, the passkeys are there in plain-text.

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.

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

My only "good" solution for passkey UX is to make sure all my devices are Apple. Apple's password/keychain integrates reasonably well enough with Chrome, I can share passkeys with my cofounder easily in shared folder (he is also all-in on Apple ecosystem) and I can share passkeys with my work computer (different AppleID) for low-stakes things like news websites or Amazon.com (I work in IT security for the org, so I know exactly how much I can trust my employer)

I do also use Linux and Windows personally, and the passkey story is much worse there, particularly for Linux which doesn't seem to play well with my Yubikeys. Luckily, a lot of websites seem to have a "Scan this QR code with your iPhone" feature to complete the passkey authentication.

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.

> To slip into opinion mode, I consider my password manager being compromised to be mostly total compromise anyway.

But how is that no the entire point? If your 2FA is a proper device, like a Yubikey, the attack surface is tinier than tiny and the device ensures that your secret never leaves the device.

We did see cases of passwords managers getting compromised. We haven't seen yet a secret being extracted from a Yubikey.

So where you say you consider that your software (password manager) getting compromised is total compromise, we're saying: "as long as the HSM on a Yubikey does its job, we have actual 2FA and there cannot be a total compromise".

You're right, I should have been more clear in that I meant a local compromise of the machine running the password manager client, not the server running the password manager itself. If my sessions and all of my data can be intercepted, the yubikey 2fa seems like it's only saving me from a token "nobody can login remotely to this one service" which at that point seems pretty moot

Yubikey offers a false sense of security in that regard, unfortunately, because if your device is thoroughly 0wned and you don't know it, the attacker "just" has to wait for the victim to do something that would trigger the yubikey, and then swap in their forged request instead. Eg if the victim uses the yubikey to log into bank1 and to crypto wallet, but bank1 accounts have no money, instead of waiting for the customer to log into their crypto wallet with the yubikey, the attack software waits for the victim to log into bank1, but swaps in a request to the crypto wallet instead.

Not sure I understand your point. Under WebAuthn / FIDO2 you can't impersonate a RP

Could you explain better?

If the user's computer is pwned, you can wait for the user to log in to their bank account, then blank the screen while you send yourself all their money.

WebAuthn assumes the browser is secure. If the browser is compromised, then impersonation becomes possible, so the user, thinking they're authorizing adding a new ssh key on GitHub.com by touching their yubikey, gets their money stolen by the hacked web browser because it has an invisible hidden window with bank.com waiting for yubikey authentication.

Passkeys are meant to replace passwords. Not being second factors is the point.

Someone gotta tell all these SaaS about that if so, because currently everyone is treating Passkeys as an alternative to 2FA. Take a look at how GitHub handles it for example when you use TOTP, they'll ask you to replace TOTP with passkeys.

Many do what you describe, probably because some manager somewhere needs to tick some checkbox.

But GitHub, specifically, allows you to sign in with a passkey. On the sign-in page, there's a "sign in with passkey" link. It activates my 1Password extension, asking if I want to use my passkey. I say yes, and I'm in, I don't type anything. This also works the same way with my YubiKey.

They are an alternative to 2FA. Which means they aren't 2FA. If they were 2FA, they wouldn't be an alternative to 2FA. They'd just be 2FA.

Anyway, passkeys and FIDO broadly aren't the same thing. You can read the definition of passkeys at https://fidoalliance.org/passkeys/ or look at any of the marketing, which invariably talks about how great it is that you don't have to futz with passwords anymore.

FIDO credentials in general can obviously also be used as second factors. This is baked into the name of the original standard: U2F, Universal 2nd Factor. The specific point of passkeys though is that they're the single factor.

Passkeys can absolutely constitute two factors. At least the iOS and Android default implementations back user verification (which the website/relying party can explicitly request) with biometric authentication, which together with device possession makes them two factor.

That's not what two-factor means. Forget about passkeys -- if you use a password manager, and that password manager has a biometric lock, your accounts don't thereby have a biometric lock as a second factor. The transitive property doesn't apply here.

I’d say it does apply transitively, but only if the weakest link itself is also strong enough, and passwords are not.

And even a passkey on a phone that doesn't require authentication is immune to remote phishing and cloning.

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.

2FA is more secure than 1FA even if that one has a high security level

if 2fa is "use the second factor that's on same device as first factor" (like when using phone apps in many cases, password + 2fa from email/sms/authenticator app on same device), I disagree.

If I get your password, and you use 2fa that's stored on your phone, does that improve your security position or not

Are you saying that two weak factors are more secure than one strong factor?

Not who you are replying too. But a yubikey is not a weak factor.

In fact, it’s not even meaningfully more secure than passkey (as passkey is designed) - passkey is, however, more convenient.

So it’s more ‘one weak factor + (really times) one medium/strong factor’ vs ‘one medium/strong factor’.

Which yes, the first one is better in every way from a security perspective. At least in isolation.

The tricky part is that passkeys for most users are way more convenient, meaning they’ll actually get used more, which means if adopted they’ll likely result in more actual security on average.

Yubikeys work well if you’re paying attention, have a security mindset, don’t lose them, etc. which good luck for your average user.

If they are on totally isolated hardware then maybe

Nonsense, depends entirely on the value of the authentication factor.

To be clear. Proper 2FA, via something like a smartcard or any truly external device is still much more secure. You could have one of those factors be a passkey, that's fine, and may be a good idea.

But there are UX issues with passkeys as well, that aren't all well addressed. My biggest gripe is that there is often no way to migrate from one passkey provider to another, though apparently there may be a standard for this in the works?

How is it not 2FA? It's MacBook + Fingerprint.

It's not 2fa if you assume some catastrophic exploit chain that allows an attacker to dump your macbooks secure element.

I don't think that's a reasonable assumption for most people, and you're screwed in that situation even if you use yubikeys.

You missed this:

>which lives in the same password manager

I'm not talking about Apple passkeys here, which are NOT stored in the Secure Element to my knowledge anyway.

I don't see passkeys as a 2FA replacement. If they're only secured in software and live in memory, as is often the case with password managers, they're too easy to compromise.

> 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 truly don't see the advantage of passkeys over a password manager like bitwarden, with random 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

It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.

is it fair to say all passkey implementations have this advantage while only some password implementations can match?

It is absolutely unfair to say it. Just like passwords stored in a password manager, passkeys can be copied out of the device for safekeeping. Because you can copy them out, a user can be induced to give them to someone.

I saw passkey boosters go very, very rapidly from "Passkeys are immune to phishing!" to "Passkeys are phishing resistant!" when lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.

> passkeys can be copied out of the device for safekeeping

You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations.

> lots of real-world people started using passkeys and demonstrated that you absolutely must have a way to back them up and move them around.

Millions of people use them without being able to move them around in the way you describe.

> You can't copy them out on at least the iOS, Android, and (to my knowledge) Windows default implementations.

Pardon? The official support docs disagree with you [0][1][2]. They absolutely leave the device.

Other passkey managers let them leave the device in a way that you control, but even the default ones copy them off the system they were created on.

[0] <https://support.google.com/accounts/answer/6197437?hl=en&co=...>

[1] <https://support.apple.com/guide/iphone/passwords-devices-iph...>

[2] Examine the "Can I use passkeys across multiple devices?" Q and its A here: <https://support.microsoft.com/en-us/windows/passkeys-frequen...>

Yes, they're synchronized, but I wouldn't call that "copying them out", as that to me implies somehow getting access to the raw private key or root secret bytes.

Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.

> ...as that to me implies somehow getting access to the raw private key or root secret bytes.

When passkeys were first introduced, they were 100% stuck to the device that they were created. There was absolutely no real way to copy them off. This is when proponents were -correctly- making the claim that they were immune to phishing.

When lots of users (who -notably- were not supported by whole-ass IT departments who set up and run systems that handle provisioning and enrolling new devices) started using passkeys, the correctness of the thing that many non-boosters were screaming ("You have to have a way to back these up and move them between devices!") became abundantly clear. Passkeys became something that could be copied off of devices, and proponents -correctly- switched to the claim "Passkeys are phishing resistant".

Once things switched around so that passkeys were no longer stuck on a single device, third-party managers got the ability to manage and copy passkeys. [0]

Hopefully it's now clear that the shift from "they never leave the device" to "they do leave the device" (and the consequences of this change) is what I'm talking about.

[0] At least, they will for the next five, ten years until the big players decide that it's okay to use attestation to lock them out to "enhance security".

It sounds like part of the problem is that two rather separate standards of "phishing" are getting conflated:

1. "Hi, I'm your bank, log in just like you normally do." (Passkeys immune.)

2. "Hi, I'm your bank, do something strange I've never ever asked you to do before by uploading some special files or running this sketchy program." (Passkeys just resist.)

The problem with the expansive definition is it basically starts to encompass every kind of trick or social-engineering ever.

That qualifies as "immune to phishing" as far as I'm concerned. No reasonable person using a reasonable implementation will ever be successfully victimized in that manner.

We need to stop pretending that padded cells for the criminally incompetent are a desirable design target. If you are too stupid to realize that you are being taken for a ride when asked to go through a manual export process and fork over sensitive information (in this case your passkeys) to a third party then you have no business managing sensitive information to begin with. Such people should not have online accounts. We should not design technology to accommodate that level of incompetence.

If you can't stop driving your car into pedestrians in crosswalks you lose your license. If you can't stop handing over your bank account number to strangers who call you on the phone you lose all of your money. If you eat rotten food you get sick and possibly die. If you hop a fence and proceed to fall off of the cliff behind it you will most likely perish. To some extent the world inherently has sharp edges and we need to stop pretending that it doesn't because when we do that it makes the world a worse place.

Sure, but then you still need a protocol between user agent and website. If you just do this in Javascript, you're not protected against phishing sites just forwarding the password entered directly.

Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain

> Sure, but then you still need a protocol between user agent and website.

Yes of course. Just like you do for passkeys.

> Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain

No, not quite. It's written on there:

> "Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)

That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.

But attestation for passkeys is dead. Neither Apple's, nor Google's implementation (with negligible exceptions) support it anymore, so any site demanding attestation will immediately disqualify > 99% of all potential users.

Some still might, e.g. for corporate or high security contexts, but I don't think it'll become a mass-adopted thing if things don't somehow drastically change course.

It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.

> It's still in the standard.

Yes, because hardware authenticators (like Yubikeys) still commonly support it, and it makes sense there.

I guess they could add an explicit remark like "synchronized credentials must not support attestation", and given the amount of FUD this regularly seems to generate I'd appreciate that. But attestation semantics seem to be governed more by FIDO than the W3C, so putting that in the WebAuthN spec would be a bit awkward, I think.

Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.

Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

In other words, you have a principal-agent problem: Users doing custom software passkey acrobatics and the banks liable for any funds lost.

Preferably, use of attestation should be limited to these (and enterprise) scenarios, and I do share the concern of others starting to use them as weak proofs of humanity etc.

> Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".

But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.

> Seems like an absolutely rare edge case to me.

Bank and payment card transactions are arguably a pretty big part of everyday life to most people.

> I doubt there is a law that says that.

Reg E/Z in the US and PSD2 in the EU pretty firmly put the burden for these types of situations/losses on the bank/PSP. They don't specifically mandate the "how", but for better or worse, industry perception and common practice is for that to include root detection, blocking VoIP numbers from receiving SMS-OTPs etc.

> That means the law should be changed.

The law that makes banks liable for most cases of account compromise? I'm actually quite happy with that, even if it comes with some unfortunate externalities.

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.

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

Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.

> but sadly many websites have botched their password input so even with a password manager you may still need to manually copy and paste

Exactly this. I use KeePassXC and the number of sites where auto-input doesn't work even if the URL is 100% correct in the entry properties is _frustratingly_ high.

They're more accessible to people who don't understand computer security?

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.

The benefit is that they aren't phishable.

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.

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.

You can just use bitwarden everywhere if you are ok with it in the cloud.

Doesn't need to be in the cloud for it work everywhere.

True. You can self-host.

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.

Anytime you save to your iOS keychain you’re doing so through the system prompt and Bitwarden should be included as a target option in that prompt.

If it’s not, that’s a Bitwarden issue. 1Password shows up in the system UI regardless of context on iOS.

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.

Passkeys are an antipattern in UX design. You want to make it simple for the users? Great! But stop treating them as too stupid to decide anything on their own. Stop locking them out of the decision loop and doing things behind their back. This is practically the corporate design philosophy of the past two decades. You can see this a lot in smartphone design.

I keep asking what advantages passkeys offer over TLS self-signed client certificates. I haven't got any answers so far. Perhaps increase the security by encrypting the private key with a password or an external token. This is safe, like SSH and unlike regular passwords, because no secrets are sent to the server. TLS certs and (encrypted) keys are more tangible and easier to manage.

Perhaps passkeys do offer some advantages over TLS certs. But can't those be added to TLS, rather than rollout an entirely new system? The infuriating part is that this facility exists in browsers. They just let it rot to an extend that it's practically unusable. Meanwhile, Gemini browsers are using it quite successfully (for those who use Gemini).

Passkeys ARE self-signed certs. You can store their private key on a hardware token, but you don't have to.

Their only difference is the automated provisioning.

> Passkeys ARE self-signed certs.

So they took something that works well and created a bad UX around it, while ignoring the working, yet languishing UI/UX that was already around?

Self-signed certificates are in the 'barely working' state. They operate on a wrong protocol level, and they can't be provisioned by the website itself.

If you try to describe how you _want_ the TLS client certificate UI to work, you'll end up with passkeys.

Okay. So they took a solution that was in a barely-working state due to their deliberate neglect, and still managed to give a bad new UX when they got the opportunity to rework it?

> "they can't be provisioned by the website itself."

It's funny, we used to have a html tag that would exactly that: <keygen />

You can't be seriously claiming that self-signed PEM certificates were working well. I've been using them for years in various contexts, and they're an absolute nightmare.

Despite all their faults, for the average user, Passkeys are still leagues ahead of GnuPG card, PIV, PKCS#15 etc.

You can't be seriously claiming that self-signed PEM certificates were working well. I've been using them for years in various contexts, and they're an absolute nightmare.

Despite all their faults, for the average user, Passkeys are still miles ahead of GnuPG card, PIV, PKCS#15 etc.

Please check how the client certificate interface of Lagrange, the Gemini browser, works. It's nowhere as complicated as you make it out to be. No passkey interfaces I've seen is as clear as this one. It automatically provisions the certificate (optional. You can share certs among services if you prefer) and associates it with the correct service. So no complicated stuff. It prompts you at the correct time for permission in the clearest way possible. It's like an integrated password manager where your credentials are just files - sort of. That's all that a regular user needs to know about them. It can be exported, imported, backed up, synced, and what not.

Gemini strives to finish an entire request in a single transaction. So TLS certs are really the only option for authentication. That's how I learned the elegance of TLS client authentication workflow and started asking why this is so neglected in web browsers.

TLS based authentication is even worse. It’s the wrong layer in today’s Internet, given Cloudflare, load balancers etc.

Not everybody trusts whatever first hop terminates TLS to also do authentication, and it completely falls flat at non-repudiation for transaction approval.

“All of the place” meaning where? There’s only a few places you can put them and they’re all more secure than passwords so it sounds like not a huge issue.

I like them but I must be the owner of them. Not Google, Apple or Microsoft. And be able to save the private keys for safekeeping, something the fido alliance doesn't really want me to do. We finally have bit warden but there's still some usability issues with that.

Right now most sites that I use that allow them have conditions that make it impossible to use for me. For example PayPal only allows them in chrome and edge.

So yeah I'll wait for them to become actually open and usable.

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.

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

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.

Don't they get associated to a particular device?

Yes, but they're used, by design, to authenticate you.

Even revealing the fact that a given passkey exists on your device requires your active confirmation according to the spec, so unless you actually want to authenticate and click the corresponding button, the site learns nothing about you (other than that your browser theoretically supports WebAuthN, which most do these days, so that's significantly less than one bit of fingerprinting data on you).

In other words, you can't be fingerprinted by WebAuthN, unless there's a (pretty severe) bug in an implementation.

No, they can be synced.

TIL, thanks

Reply on news.ycombinator.com