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.
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.
I recently moved to a new computer and it's just an AUTHHELLSCAPE.
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.
It doesn't work for me in Firefox on Linux. I'm very curious to know how it works for you.
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.
Unfortunately, it’s exactly those websites that I think would be unlikely to support passkeys at all.
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
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.
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.
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.
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.
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...>
Both Apple and Google have pretty elaborate ceremonies for adding a new device to an existing account in a way that synchronizes over passkeys.
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".
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.
This is not an issue on iOS, I can’t tell how what you’re describing could happen.
> 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.
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".
Could you explain better?
>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.
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?
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.
I don't think that's a reasonable assumption for most people, and you're screwed in that situation even if you use yubikeys.
If your password manager is itself protected by two factors, I'd still call this two-factor authentication.
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.
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.
Usually I open it in Chrome but for some reason I didn't realize it was a webview this time
If it’s not, that’s a Bitwarden issue. 1Password shows up in the system UI regardless of context on iOS.
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).
Their only difference is the automated provisioning.
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?
Despite all their faults, for the average user, Passkeys are still miles ahead of GnuPG card, PIV, PKCS#15 etc.
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.
Not everybody trusts whatever first hop terminates TLS to also do authentication, and it completely falls flat at non-repudiation for transaction approval.
Despite all their faults, for the average user, Passkeys are still leagues ahead of GnuPG card, PIV, PKCS#15 etc.
If you try to describe how you _want_ the TLS client certificate UI to work, you'll end up with passkeys.
It's funny, we used to have a html tag that would exactly that: <keygen />
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.
Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.
The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.
What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.
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)
> 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.
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.
Despite me pleading that they got there for a reason, and takes zero storage, she was confident she didn't need these passwords. So I can totally see her deleting passkeys; my mom is basically Erica, there need to be very explicit implications stated for every action presented and not assume innate understanding
As far as I understand, there are several ways to enforce per-account passkey uniqueness via WebAuthN, but every once in a while, some site will somehow not realize that I have a passkey for them available already, they will offer to create a new one for me, and my password manager (Bitwarden) will do this by overwriting the old/existing passkey.
Now consider a synchronization hiccup (updating my password manager storage and the relying party's backend is not atomic), and I could totally see my passkey get lost.
Passkeys are a mystery, and no one bothers to explain what they are, what it means, how it works, what to do, what to avoid.
I'm not an average user - MA in Mathematics, Ph.D. in Computer Science, 27 years of experience as a developer. I have a vague idea that a passkey is like a password, but you don't see it and don't type it and it's stored "somehow, somewhere."
I can't make much sense of that. How is an "average user" suppose to make sense of that?
When I try to find out how passkeys work, I get some incomprehensible gibberish about self-signed certificates, public/private key pairs, challenges, and on and on. In short, a Monad is just a monoid in the category of endofunctors of X, with product (X) replaced by composition of endofunctors and unit set by the identity endofunctor. What's the big deal?
Since any device that stores a passkey can be lost or destroyed at any moment, I assume any passkey can be lost at any moment, and there had better be a way to recover from that. Is there? Who knows.
Passkeys are designed to be hidden from the user. The author of this article even went on GitHub telling an open source implementation to not let users copy the private key.
https://github.com/keepassxreboot/keepassxc/issues/10407
There is a good reason for it. If you can copy and paste your passkey, then a phishing site can just ask you for it, making the phishing protection passkeys provide moot.
But the consequence is people, including many technical users on this website, cannot get a grasp on passkeys both as a concept and in a literal sense. How can you perceive, let alone understand, something that is designed to be hidden from you? It also doesn't help that it was pushed on users with little explanation and comes with many seemingly incompatible implementations.
Unless passkeys are redesigned to solve the intangibility problem, grannies will keep losing their accounts for no good reason and we will keep arguing about it on HN.
I'm afraid that it'll take some few more decades before we will get rid of passwords, if ever.
The same reason they're cleaning up their Windows or system32 folder.
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.
> As of October 2025, passkey login has been fully rolled out and is now required for members with Health Savings Accounts (HSAs) and Reimbursement Accounts (RAs) who use the HealthEquity Mobile app and web experience.
https://help.healthequity.com/en/articles/11690915-passkey-f...
The FAQ is a little misleading by saying WHEN your account has a passkey this and that, but reality is that after October they made them completely mandatory, no bypass, no exceptions. 100% coverage.
Oh, and by the way, passkeys have been broken on PC/Linux when using Firefox for months:
> There Was A Problem: We encountered an error contacting the login service. Please try again in a few minutes.
Neat. You have to use Chrome or Edge.... For months, after making it mandatory...
That article does say "HealthEquity Mobile and web experience" so maybe it's just for customers who use both, I only use web.
This is the biggest myth/misconception I see repeated about passkeys all the time. It's a credential just like your password. If you forget it, you go through a reset flow where a link is sent to your email and you just setup a new one.
And if it happens to be your Gmail account that you're locked out of, you need to go through the same Google Account Recovery flow regardless of whether you're using a password or a passkey.
There are also many exciting new ways you can lose your passkey that wasn't the case with a password you can remember in your mind. The person you responded to is worrying about big tech randomly banning you and making you lose access, in the meanwhile I'm mostly worried about losing the physical device containing the key. I don't think I will forget, say, my Google password unless I got Alzheimers or got hit in the head by a hammer, at which point I will have bigger problems than a lost Google account.
And let's not pretend account recovery process is always smooth and easy. They may require evidence from your other accounts you cannot access now due to the key loss. They may demand government IDs that might have been lost alongside your device. They may also just deem your recovery attempt fraudulent and ban you for no reason (which I similar to the scenario the post you are replying to desctibed.)
Personally I don't really trust companies to not do a whoopsie and permanently lock you out when you lose credentials. Especially when the company is big or hard to access in person.
For someone like me who already uses a password manager for everything, passkeys seem to add no security while reducing usability and control.
One advantage of passkeys is that they’re phishing resistant. They’re bound to the website that you created them for, it’s impossible to use them for a different website.
Instagram does something similar. If you have no logged in device and you reset your password, good luck getting in, cuz it wants you to log in a device "it recognizes" else it won't let you log in.
It's super sad to see all kinds of websites offering you to add a passkey when you log in.
An open, cross-platform passkey implementation does all that too, and on top of that prevents you from accidental password leaks via logs, MITM etc. by default.
> It's super sad to see all kinds of websites offering you to add a passkey when you log in.
As long as they're not forcing you to add one, what exactly is your problem with having more choice?
Personally, I am grateful for every site that doesn't require my phone number to sign up and uses passkeys for authentication instead, yet I also don't want SMS authentication banned for everybody since I understand it currently works better than Passkeys for many people.
Is this a mistake? I am already using password manager and totp for my accounts, but I am tired of dealing with passwords.
Even when using a password manager (bitwarden in my case), it just get tedious bringing out my phone, starting auth app, locating the correct account, reading 6 digit token and logging on.
My plan was to continue using bitwarden for passwords as well, but more as a break-glass mechanism that I really use. I want to use passkeys mostly for convinience.
Isn't it why good practice is to bind at least 2 hardware passkeys and/or have recovery codes?
Sure someone can steal your phone/laptop/yubikeybio but then you can use the NitroKey you have at home in your drawer to recover your account.
Backup keys and recovery codes also do not solve all cases of key loss. One thing I worry about is what happens if I am traveling in a foreign country and loses my belongings. In the past if I can convince someone to let me use his computer I can at least log into my email account as long as I remember my password. If everything is passkey then I will be locked out of all my online accounts until I make it back home, assuming that I have actually properly set up the backup device and keys. Humans are not very good at making sure that backups actually work.
Is it? Maybe I'm in a bubble but feels like most people I know unlock their phone with biometrics. Sure few do that on their laptop, even less on their desktop, but I imagine that explaining it's "like unlocking your phone" would help those very numerous people (if you have metrics on biometrics on phone, please do share, genuinely curious) see that it's basically doing what they already do on more devices.
Assuming your 2FA tokens are generated by phone, of course. But I think that's by far the most common way.
It honestly takes a minute to add a key and it's just that, a physical key.
IMHO what's risky in terms of UX and habits is precisely that most workflows do not highlight this. So people rightfully are scared of losing that 1 precious key, so they don't activate 2FA because of that. Meanwhile if the UX when they activate 2FA would clarify that they only have 1 key stored, adding a 2nd one or saving codes (most do propose that option for 2FA authenticators but not hardware passkey AFAIK) is what will make them both safe against attacked but also against their own accident (shit happens) then maybe behaviors would change.
Anyway, yes, you're right, most people don't do that or aren't even aware of it but arguably as more and more important and intimate part of our lives are online, it becomes crucial for one owns sanity to better understand how this all works.
Even for this, for grandma, this is probably still asking for a lot.
Grandma's bank will have a recovery option even if she's tossed her phone, computer and hardware token in the ocean, and then had a stroke which made her forget any passphrases or whatever: You can call the bank and physically authenticate yourself with a passport, driver's licence or some other ID. It's a bitch to do, you may have to go to an actual bank branch, but grandma will get access to her money again. Meanwhile, her access to physical mail doesn't stop just because she's forgotten some passphrase or lost her phone.
Even techy people get caught out by Google forcing 2FA, while casuals don't even consider the possibility of losing access to their email. While both the rhetorical you and grandma both should probably have a bulletproof recovery option for their email, since it will be the foundation of their digital identity, getting them to acknowledge the problem is going to be hard, and the solution, paying for a Yubikey or some other house of cards solution, is a tough sell.
But didn't the author hint that this could get blocked?
My general read on passkeys and their implementers is that exportability is seen as a risky feature, and there's a push to make it as opaque as possible, likely through attestation or similar mechanisms.
[1]: https://github.com/keepassxreboot/keepassxc/issues/10407
Then don't use Apple's/Google's/whatever Gaia is as your passkey provider?
> Mom can't figure out what they are or how to use them.
Then do something nice for your mom and set her up with Bitwarden, 1Password or KeepassXC, which prevents the platform lock-in.
> It's one further step down the attested hardware software and eyeballs path.
None of the synchronized passkey implementations, which big tech has been pushing lately, support attestation, so this is just FUD.
Yubikeys do, but fortunately they don't seem to have the (non-enterprise) weight to make it mandatory for all passkeys.
Good advice at the end, though.
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.
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.
That said, I've been assuming I could have multiple passkeys per site and that's turning out to not always be something websites behave sanely about.
This is usually due to relying party and possibly password manager bugs, but it does happen.
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.
Passkeys are effectively just long passwords you cannot see. The mechanism is just gravy.
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.
You can remember a strong generated password if it's a pass phrase. Better "rememberability" with the same amount of entropy.
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/
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)
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.
Also a style nit, it's OK to use "he" or "she" pronouns in a contrived narrative. The "they/their" usage really detracted from the clarity of the example.
I 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.
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.
They were secure, scalable, and they were simple to explain to my parents ("This is a physical key for your email account; like your front door key").
I 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.
(Or at absolute minimum don't force them on unsuspecting users, make them opt-in, not opt-out frequently at random times (Amazon!!!).)
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.
I guess informing them is a good way to start. Are there any other tips on how this can be improved?
See also: Bluetooth.
They’ll teach us what we need to know to create something that will do what they’re trying to do.
Curiously biometric crap is not ignored as well instead, and is pushed by any means...
It's Play Services that does not support this combination, likely to shepherd you towards Google acoount usage. Alternate Android apps work fine.
(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.
What does root detection and other device attestation have to do with passkeys? Passkeys (at least Google's and Apple's) don't support device attestation.
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.
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.
Also, as I understand it, sites can whitelist credential hardware.
If not, then the attestation is security theater. I (or an attacker on your machine), can just make a sw emulator of a hw attestation device, and use that to protect my choice of OS, (and skim your credentials).
If a whitelist exists, then my “hijack your OS” plan works: Require the builtin macos/windows/signed chrome on signed os password managers. That’s 90% of the market (and dropping) right now.
It talks about whatever you used to authenticate and the platform can manipulate (or omit) it.
Yes, and iOS and Android's Passkey implementation does not support it, since doing so would be lying about a given credential being hardware-backend when it's actually not (due to being cloud-synced and often recoverable via some process).
Attestation is only for hardware authenticators, either dedicated ones like Yubikeys or non-synchronized Android WebAuthN credentials. (iOS only supports them in MDM contexts anymore, I believe.)