> websites which [...] also want to know how the passkey is being handled by the user’s device to keep their accounts safe
This is exactly where passkeys go too far. "to keep their accounts safe" is always the excuse used to reduce the freedoms of users. Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable. The boundary of control of a website used to stop at the interface between the site and the user. Now that boundary will extend to the devices. The idea of property and ownership is attacked again. The device is not something the user owns and has full control over but something that is a gateway to access content controlled by the big Internet companies.
Knowing this, how long until Netflix, Disney other content providers (sorry I don't know which ones are popular right now) demand use of a passkey originating form a device with a Trusted Platform (aka Untrusted User) Module ? This is part of a long plan initiated years ago with Windows TPM requirements, Microsoft account requirements. The gap between closed and open platforms will widen and the path is clearly to apply the Smartphone model where everything is closed, controlled, DRM'd, to other computers. We're lucky the IBM PC architecture was an open one but the war on that is on.
Yep the whole tpm thing and the device constrained nature they have envisioned is the major drawback.
But no they have to live in their secured enclave or on a dongle so that you can't copy them between devices because nothing ever happened to a device.
As if the rest of the users system is compromised the user can't be tricked into providing access to their account.
And no one ever "recovered" someone else's account.
The main benefit of passkeys is that they are keys you don't have to send them over the wire. The main risk of having them on disk encrypted purely in software is that a compromised system can lead to the keys getting stolen.
Their trusted platform bulshit doesn't really escape that threat though, instead of stealing your keys the attacking malware can just get access to your service and maybe even enroll their own key.
If you tried to login to a website and you got two requests to allow the use of your key one after the other would ulyou really have the wherewithal to say no wait a second I just gave permission for that key to be used, the second request is obviously from malware on this computer that's trying to gain access to my account.
That's ignoring that the malware can just read everything you are reading.
The whole tpm obsession is security theater on top of a power play
I've seen this argument many times, but I don't understand it. Can you explain a scenario where this would be an issue? So, Netflix makes me log in with a passkey that comes from their own hardware, instead of my password manager. What's the danger there, beyond the fact that this seems to me extremely unworkable because I'd just never sign in?
The danger is that you now can no longer use netflix without they're approved hardware? Of course, that's essentially already the case with netflix, but this becomes dicey when services that actually matter take this approach.
It's not really Netflix. Its Microsoft, Apple and Google.
So say goodbye to using teams on Linux. Using Microsoft365 on any hardware that is not Microsoft approved.
Or logging in to your bank without an iPhone or an android. We will surely complain but the bank will say that we only support secure devices and that means iPhones and Android, and how come you are making a big deal about it just buy one of these two everyone else has one.
> Or logging in to your bank without an iPhone or an android.
This is already possible (and common!) many banking apps, for better or worse, use device attestation features that require varyingly official copies of android. Were you already complaining about this?
Websites can choose to not accept your passkey manager ("accept" not "block" since it will obviously be enforced as whitelist). What could possibly go wrong ? If only there was a similar example with an existing system like TOTP and a big company like Steam..........
Link unrelated https://github.com/keepassxreboot/keepassxc/discussions/9591
Eventually get debanked and go live in the woods ig
Losing your device and not having any passwords is like losing your fingerprints.
>Device loss scenarios
>Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
>Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
Also requires the device allows backup of passkeys. The infamous post where keepass was threatened if they were to continue to allow users to backup their own keys.
The person there requested that KeePassXC don't let users export their keys in plaintext, which seems reasonable. He asked that the software encrypt the keys with a user-selected password before exporting, so someone stealing the files wouldn't have the keys to literally all of the user's sites. That doesn't seem unreasonable to me.
Not really dude, if I can't export in plaintext I can't pick the encryption I have to use whatever keepassxc will do. I can't pipe it to gpg and encrypt it with my key.
And on the other hand I can only load them to another keepass instance I can't switch credential managers.
If you are worried your system is running malware that will steal your plaintext keys, well bad news they can steal the encrypted keys and keylog your password.
> If you are worried your system is running malware that will steal your plaintext keys
No, I'm not worried about this since I do not and will not copy my keys.
I'm worried about my friends or family using the most secure options possible (passkeys) and still getting phished because they paste their plaintext secrets into a scam site.
Just not having the right device with you is crippling. IMO Passkeys need more work. I'd really like to see accounts support multiple passkeys. I'd prefer biometrics that are device independent. I just don't like the idea of replacing something someone can steal (a password) with something else someone can steal (a phone).
At first I read this as "Apple doesn't implement Touch ID, because they found it to be insecure", which really confused me. Was that the intent?
On second reading, I'm thinking this might mean, "since Apple only implements Face ID, biometrics on Apple devices is less secure", which makes more sense (to me).
Aren't fingerprints obsolete as biometrics? Last I remembered fingerprints can be lifted if high resolution pictures. I.e. any picture where your thumb is visible.
I agree. I use Bitwarden on my Samsung Android phone and also on my Linux desktop. Bitwarden currently supports passkeys on almost all the apps on my android including firefox. The same passkeys which i used to login on my phone can be used on my Linux desktop where i use Firefox with Bitwarden extension. What's now possible was not even possible at the start of this year. I haven't switched everything to passkeys but i can see it as an alternative to passwords now(passwords really shines in some areas too).
I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.
The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
Sorry, to clarify: Okta is not for our purposes a relying party and won't do anything to force attestation on relying parties. The second bit of what he wrote is ambiguous, but charitably, could simply mean "I used to argue against requiring attestation, but now I'm not sure". Which is fine, since he has absolutely no pull when it comes to how Okta's product works (and to be fair, I don't think he implied otherwise or even mentioned Okta).
Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC:
> The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like.
The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedbac...
Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608
Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.)
We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.
But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.
The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already.
For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.
Can you send some documentation on how? For example, I tried googling for transferring a passkey out of popular systems and it doesn't seem possible[1][2] other than through JSON export[3] which is what some sites want to block as I understand.
I don't think you're going to find it. The main vendors are hostile to this workflow. I get why, any flow that can exist to export passkeys can be used by hostile actors to walk a 75-year old millionaire grandma through handing over $$$. I think however that that's just a risk we have to make the bank and brokerages accept. It's not a problem with a technical solution.
Wasn't the discussion you responded to about how they currently can't be shared and that the vendors don't want them to be shared as it breaks their desired lock-in?
So the same passkey is being used on multiple devices, rather than different devices (actually applications) having distinct passkeys.
Doesn't that defeat one of the centrals aims of passkeys? In what ways is your setup different than random passwords in bitwarden - what's the additional security?
Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.
The password manager has become the device (and offers some assurance if the device is lost, as you can log into the manager on another device). I agree definitely isn't the original vision of passkeys (having a different passkey on every device, stored in separate password databases?), but it makes more sense for my cases.
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
> Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
The benefit to the user of a passkey is that they don't have to remember passwords ("what you have" and not "what you know"). But if you lose what you have, you're screwed. There's no straightforward way to mitigate this.
Proposed solutions I've seen just add an extra layer of "what you know," but this just changes the security back to "what you know" if it supersedes the passkey.
“Passkeys are the future of authentication” …this is not the future I hope….When Google, Microsoft and a lot of other B*G-Tech companies promote Passkeys, you know it is not done to protect your security and privacy.
For me, passkey's have made it when I can pay several different, independent providers to store them for me, and authorise the devices I can put them on.
To expand on that a bit, I don't have a problem with banks or whoever insisting they be stored securely. That means I don't have a problem win the inference that they don't trust me to store or even see my own keys.
What I do have a problem with is not being able to back them up. Which means I have a problem with Apple, Google or even Bitwarden handing me out a free they can take away at any time.
Fix that, so I can have store my identity(ies) at multiple providers, and I happy.
I'm glad that someone is at least seriously talking about these problems. A couple of them are serious enough to make passkeys a real pain in the butt for me. A big enough one that the whole scheme is a nonstarter.
Until passkeys can pass the test of "my non-technical friends and family don't call me for help about them", passkeys aren't ready. Vendors keep making assumptions about how users behave which are not safe assumptions, and that keeps blowing up the interactions of non-technical users. (I'm sure there's an "assumptions developers make about user accounts" blog out there somewhere.)
For example, my family has had to call me for help on the interaction between passkeys on Apple & Amazon multiple times. They have a shared Amazon account, which neither Amazon nor Apple seem to like. The first problem came when they didn't even know they'd been moved to passkeys - there was a popup that one of them didn't understand, they clicked OK to get it to go away, and suddenly the other partner can't log in, and neither of them can figure out how to log into Prime Video on their AppleTV. Another time one of them got "nudged" to add a fingerprint to the account, again freezing out the other person.
Until that nonsense stops happening, Passkeys aren't ready.
By that metric, passwords are even less ready, as I seem to always have to field calls for passwords getting stolen or compromised or accounts getting phished. I guess we're back to faxing ID.
I have a non-technical father with dementia, and passwords+TOTP are almost frictionless for him, with minor exceptions. We are able to share around passwords and TOTP codes without any problems so I can properly monitor his online activities to keep him out of trouble. He’s a cranky old guy with almost zero trust, so having to input all that stuff satisfies him that security is being employed.
if you really want passkeys to succeed why not implement it at the browser level. Basically everytime you visit a new website the browser has never seen before, the browser initiates a handshake of sorts with that website and secures a passkey for it which is stored. If the user wants to log in to that website, the browser can automatically patch in the details as and when required
Let's assume your vault/login has these properties:
- You have a strong unlock password that you don't use anywhere else
- You have a second factor set up for unlocking the vault (TPM in the device you're using, Yubikey, TOTP, etc.)
- The service you're logging into has good account recovery hygeine
The benefit, assuming those things, is that the passkey is phishing-resistant and social-engineering-resistant. If a user gets an email saying "omg, someone tried to transfer your paypal, click this link to log in", then when they try to log in with the passkey, the site the attacker is using won't be able to use the passkey (because the passkey is associated with a particular domain). Even if the user wanted to bypass this, there's specifically no way for them to extract the contents of the passkey.
That is very different from a user having their password stored in their vault. They could easily forget to check the domain, or get tricked by a very similar looking one, and copy/paste their password into the attacker's form.
My password manager (keepassxc) has a browser extension that only lets you autocomplete the password on a page if the url matches the one stored in the database.
Sure I could manually copy the password from the database, but in practice, this is fairly good security. It also doesn't treat the user as an always-idiot, which is a good thing in my book.
I'm struggling to think of a reason why being "treated as an always-idiot" is an actual negative in this specific example.
I use Bitwarden and when the password autofill doesn't work as expected my first assumption from many previous experiences is that it's because a website changed something slightly in their auth flow or a particular page has a weird redirect/embedded login scheme different than the primary login, or similar "modern" web weirdness.
So if I get phished and let my guard down just that one time due to panic, sleep deprivation, or whatever else I'm glad that it gives me a second layer of defense against me reflexively clicking a couple times to copy/paste the password manually. A passkey dropdown with "No passkeys saved for this site" would be a massive red flag and stop me in my tracks before trying to do something else stupid.
Passkeys do protect you from such mistakes in a way the current implementation of the browsers/password managers/web-specs don't.
But that is after 10s of millions of dollars or more have been poured into the development of passkeys, resulting in new standard specifications, diverse implementations of password managers, etc.
Now, imagine the counterfactual world where those same dollars were devoted to improving the password infrastructure. Could we have forced the average person to always password managers with long randomized passwords? Could we have build better webspecs around password entry workflows, and forced websites to fix the issues you face? I think the answer is yes.
Against this counterfactual world, passkeys are not in practice much better.
Except we already are living in that counterfactual world. Companies haven't been sitting on their hands while lamenting how bad passwords are, we've spent many times more money trying to make passwords secure than we've spent on developing passkeys.
That works for you, but the website doesn't know you use a password manager, so they'll often want you to use SMS as a second factor.
Passkeys require some kind of password manager. That's the main benefit. The adoption problems are because a lot of users don't really understand password managers.
I bet that Google+Apple+Microsoft could have gotten 95% of the world on password managers by building excellent password managers into the OS, and demanding that one can only login into their websites with passwords that have at least 100 bits of entropy.
Microsoft and Google forced organizations that were using their services to upgrade to 2FA over a few years. For a short bit it was optional, after that it's basically not possible to use these services without 2FA. Now even many grandmas are familiar with the idea that sometimes you have to copy a code from your sms to a website when logging into your bank account.
They could have done the same thing with passwords. They have 100s of millions of organizational users, who will do whatever corporate IT tells them to do. Microsoft can say, there is a password manager available on Windows. From now on, organizational users must use 100 entropy bit passwords. IT tells users - users must store passwords in the password manager and use the browser extension.
After three years of users resisting, everyone will give in. Same for university students, who will need it. After that the rest will adopt easily because it is the default thing to do.
So your real issue here is with credential managers, but I'll bite. In most cases the vault is not protected only with your master password, but with other cryptographic info that prevents the vault from being opened on untrusted devices. If one of your trusted devices is compromised, I guess you have other issues.
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
- are generated securely and so can’t be guessed
- can’t be phished
- are unique for each website you use, so if one website is compromised it doesn’t put your other logins at risk
At its core, the main drawbacks that need to be solved for them to be a viable option are imo:
* Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.
* Device loss scenario is already mentioned, although more broadly speaking a lot of the reasons people get leery is because all three major providers (Google, Microsoft, Apple) are notorious for their near black box technical support. Losing access to one of these providers on its own is already enough to heavily disrupt the average person's life. Having your login details stored with them makes this even worse.
* The FIDO Alliance Is Way Too Excited About Device Attestation And I Don't Like It. Basically the FIDO Alliance's behavior around passkeys reeks of security theater and them badgering an open source password manager for daring to let users export their passkeys in the format they preferred, rather than what the FIDO Alliance wanted (which is that passkeys must always be encrypted with a password) is telling. If they are as secure as promised, it's a bad look to start threatening device attestation as a means to get people to comply with your specific idea of security. The only real barrier right now to it outright being a thing is that Apple zeroes out the field and when Apple is the only meaningful halt to that kind of attestation, something has gone very wrong.
I think passkeys are interesting, but I just flat out don't trust the FIDO Alliance with the idea. They're way too invested in big tech being good stewards of the ecosystem, which is becoming increasingly unpalatable as more and more evidence piles up that they're really bad actors on everything else. (So why should we trust them with our credentials?) The idea genuinely has value (it's literally the same kind of mechanism as SSH keys), but the hostility towards user freedom is deeply concerning and a blocker to getting people to use it. Even non-technical people seem leery of them, just because of how aggressively big tech has been pushing it.
God if it could just be a single key that you dump to paper or titanium plate and don't worry about backing up a zoo of keys/password with a cloud. Just take my one and only public key. If you care about per service privacy, you are welcome to use multiple. I don't think there is any compromise scenario where you would leak any single specific passkey and they are not bruteforcable. Why is it not as simple as that?
> * Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.
You're kidding yourself if you think that this is something Microsoft, Apple, or Google are incentivized to solve. Microsoft is especially bad here - pushing their crappy products in Windows every chance they get. Once some marketing director gets the idea that this can improve retention in Outlook or something the UI will get more confusing and the dark patterns will get darker.
I never said they had an incentive to solve it. I said that it's one of the big blockers to getting regular adoption. It ought to be obvious that all these issues aren't a problem if you look at it through the big tech lens: why is it a problem when we're providing the service. They're a problem when you're a normal person with a healthy distrust of big tech companies.
In practice, I expect someone to figure out a way to break into/bypass the OS flow entirely with a less "big tech wants your private details" solution and that's what winds up getting adoption.
How are passkeys different from API keys or just random chains of characters?
And why can't we have the use of such keys enforced by an EU legislation so that all businesses allow users to login using such strings of random characters?
Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.
So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.
One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.
X.509 already does that, and in a better way. It also makes it unnecessary to register multiple devices, if you allow certificate chains (the server would check the certificate chain; one of the was issued by the service and contains information about which account it is associated with; the other ones you can issue to yourself, optionally with more restricted permissions, and can be revoked or expire). That would also allow you to have passworded private keys, and/or to store one private key on a separate computer that is not connected to the internet to issue the other one to yourself in order to mitigate security issues (and you can revoke the certificate and make a new one if it is compromised or expires). X.509 also is not limited to only WWW, so it can be used with other protocols too.
If you are not careful, you'll enter the random chains of characters into a phishing site.
But a phishing site can't steal your passkey and forward it to the real site, the passkey will just not work with the phishing site if you try using it there, it's locked to the authentic domain.
> How are passkeys different from API keys or just random chains of characters?
As far as I understand it, in the same way that a public/private keypair differs from a random chain of characters you are used to shoving into the "Authorization: Bearer XXXXXXX" header.
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
But afaik you still can't move Passkeys from Chrome or Safari to any other credential manager.
I was vaguely under the impression that there was a ton of push-back again import/export flows in general, that the CEP was going to be the only supported path. And it requires that your Credentials Manager have a public endpoint to send your credentials to. Which doesn't force but radically ups the challenge for individuals to self host or manage things themselves, will drive Passkeys to remain service provided only.
With governments upping their right to snoop, immoral intercept, it's hard to have too much hope that Passkeys can remain trustable & respectable. If the UK passes a law saying they can access all your keys, the odds are not in your favor that Google is going to make a Signal like stand & tell the UK to buzz off. It's unfortunate that these giant massive enterprises are so big are so many products all in one, because if there was a healthy Chrome business not tied to thousands of other profit lines, maybe Chrome would dare have some backbone & tell their majesty to go stick it where the sun don't shine. But these companies are so big that even the most immoral outrageous ridiculous laws end up being accepted. Passkeys seems like a huge painted target; maybe the next 15-20 years go by with no one trying to get in the cookie jar, but it seems inevitable that the moral rot and illegitimacy of governments will stoop down to making this good idea untenable & a joke, in a long enough time scale. Especially with the service-provider-only ecosystem that's being engineered and imposed here.
> websites which [...] also want to know how the passkey is being handled by the user’s device to keep their accounts safe
This is exactly where passkeys go too far. "to keep their accounts safe" is always the excuse used to reduce the freedoms of users. Web sites have no business deciding how things are handled on user devices but it's precisely what passkeys enable. The boundary of control of a website used to stop at the interface between the site and the user. Now that boundary will extend to the devices. The idea of property and ownership is attacked again. The device is not something the user owns and has full control over but something that is a gateway to access content controlled by the big Internet companies.
Knowing this, how long until Netflix, Disney other content providers (sorry I don't know which ones are popular right now) demand use of a passkey originating form a device with a Trusted Platform (aka Untrusted User) Module ? This is part of a long plan initiated years ago with Windows TPM requirements, Microsoft account requirements. The gap between closed and open platforms will widen and the path is clearly to apply the Smartphone model where everything is closed, controlled, DRM'd, to other computers. We're lucky the IBM PC architecture was an open one but the war on that is on.
Yep the whole tpm thing and the device constrained nature they have envisioned is the major drawback.
But no they have to live in their secured enclave or on a dongle so that you can't copy them between devices because nothing ever happened to a device.
As if the rest of the users system is compromised the user can't be tricked into providing access to their account.
And no one ever "recovered" someone else's account.
The main benefit of passkeys is that they are keys you don't have to send them over the wire. The main risk of having them on disk encrypted purely in software is that a compromised system can lead to the keys getting stolen.
Their trusted platform bulshit doesn't really escape that threat though, instead of stealing your keys the attacking malware can just get access to your service and maybe even enroll their own key.
If you tried to login to a website and you got two requests to allow the use of your key one after the other would ulyou really have the wherewithal to say no wait a second I just gave permission for that key to be used, the second request is obviously from malware on this computer that's trying to gain access to my account.
That's ignoring that the malware can just read everything you are reading.
The whole tpm obsession is security theater on top of a power play
I've seen this argument many times, but I don't understand it. Can you explain a scenario where this would be an issue? So, Netflix makes me log in with a passkey that comes from their own hardware, instead of my password manager. What's the danger there, beyond the fact that this seems to me extremely unworkable because I'd just never sign in?
The danger is that you now can no longer use netflix without they're approved hardware? Of course, that's essentially already the case with netflix, but this becomes dicey when services that actually matter take this approach.
And then suddenly you're debanked.
No, we're talking about logins, not usage. Can someone explain to me a case where logging in only with an approved authenticator would be problematic?
How exactly are you going to use a service that requires login if the login requires an authorized device you don't have?
OK, so what's the scenario? Netflix wants to make me not use their service? Surely there are easier ways to do that than to make a new auth standard?
It's not really Netflix. Its Microsoft, Apple and Google.
So say goodbye to using teams on Linux. Using Microsoft365 on any hardware that is not Microsoft approved.
Or logging in to your bank without an iPhone or an android. We will surely complain but the bank will say that we only support secure devices and that means iPhones and Android, and how come you are making a big deal about it just buy one of these two everyone else has one.
> Or logging in to your bank without an iPhone or an android.
This is already possible (and common!) many banking apps, for better or worse, use device attestation features that require varyingly official copies of android. Were you already complaining about this?
Websites can choose to not accept your passkey manager ("accept" not "block" since it will obviously be enforced as whitelist). What could possibly go wrong ? If only there was a similar example with an existing system like TOTP and a big company like Steam.......... Link unrelated https://github.com/keepassxreboot/keepassxc/discussions/9591 Eventually get debanked and go live in the woods ig
Losing your device and not having any passwords is like losing your fingerprints.
>Device loss scenarios
>Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
>Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
Also requires the device allows backup of passkeys. The infamous post where keepass was threatened if they were to continue to allow users to backup their own keys.
I hadn't heard this story. Source: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
The person there requested that KeePassXC don't let users export their keys in plaintext, which seems reasonable. He asked that the software encrypt the keys with a user-selected password before exporting, so someone stealing the files wouldn't have the keys to literally all of the user's sites. That doesn't seem unreasonable to me.
Not really dude, if I can't export in plaintext I can't pick the encryption I have to use whatever keepassxc will do. I can't pipe it to gpg and encrypt it with my key.
And on the other hand I can only load them to another keepass instance I can't switch credential managers.
If you are worried your system is running malware that will steal your plaintext keys, well bad news they can steal the encrypted keys and keylog your password.
> If you are worried your system is running malware that will steal your plaintext keys
No, I'm not worried about this since I do not and will not copy my keys.
I'm worried about my friends or family using the most secure options possible (passkeys) and still getting phished because they paste their plaintext secrets into a scam site.
Just not having the right device with you is crippling. IMO Passkeys need more work. I'd really like to see accounts support multiple passkeys. I'd prefer biometrics that are device independent. I just don't like the idea of replacing something someone can steal (a password) with something else someone can steal (a phone).
> I'd really like to see accounts support multiple passkeys
Most accounts seem to. Personally, I think I've only found one or two out of around 25 that I've added passkeys to that would not let me add more.
Would be nice, but biometrics have also been systematically made less secure. Apple, for example, no longer sells a phone with Touch ID.
At first I read this as "Apple doesn't implement Touch ID, because they found it to be insecure", which really confused me. Was that the intent?
On second reading, I'm thinking this might mean, "since Apple only implements Face ID, biometrics on Apple devices is less secure", which makes more sense (to me).
Aren't fingerprints obsolete as biometrics? Last I remembered fingerprints can be lifted if high resolution pictures. I.e. any picture where your thumb is visible.
Yeah, the latter. All kinds of reports of siblings (including fraternal twins and non-twins) being able to unlock each others phones.
https://duckduckgo.com/?origin=funnel_home_google&t=h_&q=fac...
Fingerprints are much more non-deterministic and therefore more secure.
I agree. I use Bitwarden on my Samsung Android phone and also on my Linux desktop. Bitwarden currently supports passkeys on almost all the apps on my android including firefox. The same passkeys which i used to login on my phone can be used on my Linux desktop where i use Firefox with Bitwarden extension. What's now possible was not even possible at the start of this year. I haven't switched everything to passkeys but i can see it as an alternative to passwords now(passwords really shines in some areas too).
I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
Here's an Okta employee threatening to use the attestation (anti)feature of passkeys to block open-source implementations, because they allow you to export your passkeys: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Tim Cappalli is thoroughly misguided throughout that discussion, but he's not threatening anything. Okta lets users require attestation, but it will never, ever force attestation on anyone.
The specific part that I consider a threat is "which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations".
Sorry, to clarify: Okta is not for our purposes a relying party and won't do anything to force attestation on relying parties. The second bit of what he wrote is ambiguous, but charitably, could simply mean "I used to argue against requiring attestation, but now I'm not sure". Which is fine, since he has absolutely no pull when it comes to how Okta's product works (and to be fair, I don't think he implied otherwise or even mentioned Okta).
Tim's not threatening, but he is saying quite clearly that sites on the internet (Relying Parties) might just not accept Passkeys from KeePassXC:
> The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
Tim's talking the reality of KeePassXC and the reality is that this specification is being built in a way where the user is fundamentally out of control. Where the industry at large has total control over your material, gets to say how you can store your keys, and will refuse you credential managers that they don't like.
The proposed Credential Exchange Protocol draft also does not allow you to backup your key. A credential manager will only Export the key to another credential manager service, across public endpoints on the internet. Never transiting the user's control. So you have to trust your credential manager that they actually will let you export your credentials, to someone you can trust, at a future point in time. There's an issue open for this, but no real hope this ever gets better. https://github.com/fido-alliance/credential-exchange-feedbac...
Passkeys seem designed to never be trustable by users. There's always some online service somewhere holding your materials that governments will be able to legally strongarm the service into getting access to. You won't be able to Export when you need it. The security people seem intent on making sure computers are totally controlled by corporations and governments, in the worst ways. The top post is right. https://news.ycombinator.com/item?id=45737608
Correct, individual sites could make that choice. They won't, but they could. (Love the mention in the linked comment of Netflix and Disney, two services that don't even support proper MFA.)
We're completely on the same side, to be clear. I just have zero fear of KeePassXC (which I sometimes use with Okta!) being blocked by anything consumer-facing.
Apple does precisely this for Apple account, you need to have a hardware attested passkey implementation to authenticate using passkey.
Edit: forgot to add Apple account
To authenticate to what? I have a few dozen people using passkeys on macOS without attestation, but I'll admit none of them are logging into "Apple".
> because they allow you to export your passkeys
because they allow you to export your passkeys in plaintext, for easy stealing.
"Information wants to be free" should not apply to passwords!
But open-source programs can always be modified to do that, so that's a terrible reason to ban open-source passkey managers. And besides, you shouldn't be forbidden from doing things with your own data just because they're unwise.
That's the whole point of this exercise. If export is possible it's not secure against local compromise in the way that's needed.
The point of passkeys is to protect against phishing and password reuse. You can't protect against local compromise, even if your passkeys are stored in something like a YubiKey, because once you log in to your bank with your hardware-backed passkey, the malware on your computer could use the session you started to transfer all of your money out of your account.
That’s why most banks ask you to approve transactions with an explicit reauthentication.
Then the malware will just wait until you want to do something legitimate that needs that, and then swap it out for its own thing.
But it can't maintain that compromise. That's important.
That's not quite correct. This can easily be seen by simply considering that the people who developed the passkey standard are also developing a passkey import/export standard which is nearly done and implementations are appearing in the field already.
For example Apple's Passwords app on MacOS/iOS/iPadOS 26 now supports export and import of passkeys to/from other apps that support that standard. I don't know if any other apps have yet actually released such support.
Needed for whom? As others have said, without export it's a recipe for vendor lock-in.
lock-in to which vendor?
Passkeys support transfer to any vendor you want.
I want to transfer them to a vendor that will let me export them in plain text.
Is it really "any" vendor, or is it just the big ones? Can you transfer your Apple passkeys to KeePassXC?
I can't even find documentation on how to do the simplest transfer, from Apple iCloud Keychain to Google Chrome or vice versa.
Not yet. Apple supports export using FIDO's Credential Exchange standard. KeePassXC is working on adding that.
Can you send some documentation on how? For example, I tried googling for transferring a passkey out of popular systems and it doesn't seem possible[1][2] other than through JSON export[3] which is what some sites want to block as I understand.
[1] https://old.reddit.com/r/Bitwarden/comments/1efs5d2/how_can_...
[2] https://old.reddit.com/r/Bitwarden/comments/1di8nbz/import_p...
[3] https://news.ycombinator.com/item?id=44454106
I don't think you're going to find it. The main vendors are hostile to this workflow. I get why, any flow that can exist to export passkeys can be used by hostile actors to walk a 75-year old millionaire grandma through handing over $$$. I think however that that's just a risk we have to make the bank and brokerages accept. It's not a problem with a technical solution.
Why is it more important than protecting users? They've already added a way to share them securely.
Wasn't the discussion you responded to about how they currently can't be shared and that the vendors don't want them to be shared as it breaks their desired lock-in?
So the same passkey is being used on multiple devices, rather than different devices (actually applications) having distinct passkeys.
Doesn't that defeat one of the centrals aims of passkeys? In what ways is your setup different than random passwords in bitwarden - what's the additional security?
Passkeys cannot be phished.
Other than that they shouldn't have a big advantage for a more professional user with unique, long, and random passwords. For the common user it should be a great upgrade, giving all these advantages with better UX.
Another is that passkeys are single login and sites don’t use 2FA. Not having to get out TOTP or receive SMS is worth it.
Basically, any site that does 2FA should take passkeys.
The password manager has become the device (and offers some assurance if the device is lost, as you can log into the manager on another device). I agree definitely isn't the original vision of passkeys (having a different passkey on every device, stored in separate password databases?), but it makes more sense for my cases.
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
> Backing up and synchronising passkeys with a Credential Manager makes it easier to recover access to them compared to other existing second factor options. However, this relies on the user having prepared their Credential Manager account for recovery. Users need help in understanding and implementing the right steps so they can feel ready to go passwordless and use passkeys without extra worry and hassle.
The benefit to the user of a passkey is that they don't have to remember passwords ("what you have" and not "what you know"). But if you lose what you have, you're screwed. There's no straightforward way to mitigate this.
Proposed solutions I've seen just add an extra layer of "what you know," but this just changes the security back to "what you know" if it supersedes the passkey.
“Passkeys are the future of authentication” …this is not the future I hope….When Google, Microsoft and a lot of other B*G-Tech companies promote Passkeys, you know it is not done to protect your security and privacy.
Nice read https://techrights.org/n/2025/05/02/Passkeys_Are_Vendor_Lock...
For me, passkey's have made it when I can pay several different, independent providers to store them for me, and authorise the devices I can put them on.
To expand on that a bit, I don't have a problem with banks or whoever insisting they be stored securely. That means I don't have a problem win the inference that they don't trust me to store or even see my own keys.
What I do have a problem with is not being able to back them up. Which means I have a problem with Apple, Google or even Bitwarden handing me out a free they can take away at any time.
Fix that, so I can have store my identity(ies) at multiple providers, and I happy.
I'm glad that someone is at least seriously talking about these problems. A couple of them are serious enough to make passkeys a real pain in the butt for me. A big enough one that the whole scheme is a nonstarter.
Until passkeys can pass the test of "my non-technical friends and family don't call me for help about them", passkeys aren't ready. Vendors keep making assumptions about how users behave which are not safe assumptions, and that keeps blowing up the interactions of non-technical users. (I'm sure there's an "assumptions developers make about user accounts" blog out there somewhere.)
For example, my family has had to call me for help on the interaction between passkeys on Apple & Amazon multiple times. They have a shared Amazon account, which neither Amazon nor Apple seem to like. The first problem came when they didn't even know they'd been moved to passkeys - there was a popup that one of them didn't understand, they clicked OK to get it to go away, and suddenly the other partner can't log in, and neither of them can figure out how to log into Prime Video on their AppleTV. Another time one of them got "nudged" to add a fingerprint to the account, again freezing out the other person.
Until that nonsense stops happening, Passkeys aren't ready.
By that metric, passwords are even less ready, as I seem to always have to field calls for passwords getting stolen or compromised or accounts getting phished. I guess we're back to faxing ID.
I have a non-technical father with dementia, and passwords+TOTP are almost frictionless for him, with minor exceptions. We are able to share around passwords and TOTP codes without any problems so I can properly monitor his online activities to keep him out of trouble. He’s a cranky old guy with almost zero trust, so having to input all that stuff satisfies him that security is being employed.
Passcodes just freak him out.
I think Github is basically the only good passkey implementation right now. The ideal flow should be:
* Click login button
* Window pops up asking you which passkey you want to use, you click the one you want
* You're in
Anything on top of that is just added friction, and I haven't seen many sites get it right.
Passkeys are a convenient second form of authentication that goes overlooked when accounts are hacked.
if you really want passkeys to succeed why not implement it at the browser level. Basically everytime you visit a new website the browser has never seen before, the browser initiates a handshake of sorts with that website and secures a passkey for it which is stored. If the user wants to log in to that website, the browser can automatically patch in the details as and when required
So then I should store all my passkeys in a vault that I protect with a single password, how are passkeys safer?
Let's assume your vault/login has these properties:
- You have a strong unlock password that you don't use anywhere else
- You have a second factor set up for unlocking the vault (TPM in the device you're using, Yubikey, TOTP, etc.)
- The service you're logging into has good account recovery hygeine
The benefit, assuming those things, is that the passkey is phishing-resistant and social-engineering-resistant. If a user gets an email saying "omg, someone tried to transfer your paypal, click this link to log in", then when they try to log in with the passkey, the site the attacker is using won't be able to use the passkey (because the passkey is associated with a particular domain). Even if the user wanted to bypass this, there's specifically no way for them to extract the contents of the passkey.
That is very different from a user having their password stored in their vault. They could easily forget to check the domain, or get tricked by a very similar looking one, and copy/paste their password into the attacker's form.
My password manager (keepassxc) has a browser extension that only lets you autocomplete the password on a page if the url matches the one stored in the database.
Sure I could manually copy the password from the database, but in practice, this is fairly good security. It also doesn't treat the user as an always-idiot, which is a good thing in my book.
I'm struggling to think of a reason why being "treated as an always-idiot" is an actual negative in this specific example.
I use Bitwarden and when the password autofill doesn't work as expected my first assumption from many previous experiences is that it's because a website changed something slightly in their auth flow or a particular page has a weird redirect/embedded login scheme different than the primary login, or similar "modern" web weirdness.
So if I get phished and let my guard down just that one time due to panic, sleep deprivation, or whatever else I'm glad that it gives me a second layer of defense against me reflexively clicking a couple times to copy/paste the password manually. A passkey dropdown with "No passkeys saved for this site" would be a massive red flag and stop me in my tracks before trying to do something else stupid.
Passkeys do protect you from such mistakes in a way the current implementation of the browsers/password managers/web-specs don't.
But that is after 10s of millions of dollars or more have been poured into the development of passkeys, resulting in new standard specifications, diverse implementations of password managers, etc.
Now, imagine the counterfactual world where those same dollars were devoted to improving the password infrastructure. Could we have forced the average person to always password managers with long randomized passwords? Could we have build better webspecs around password entry workflows, and forced websites to fix the issues you face? I think the answer is yes.
Against this counterfactual world, passkeys are not in practice much better.
Except we already are living in that counterfactual world. Companies haven't been sitting on their hands while lamenting how bad passwords are, we've spent many times more money trying to make passwords secure than we've spent on developing passkeys.
That works for you, but the website doesn't know you use a password manager, so they'll often want you to use SMS as a second factor.
Passkeys require some kind of password manager. That's the main benefit. The adoption problems are because a lot of users don't really understand password managers.
I bet that Google+Apple+Microsoft could have gotten 95% of the world on password managers by building excellent password managers into the OS, and demanding that one can only login into their websites with passwords that have at least 100 bits of entropy.
And it could have been done 10 years ago.
I don't think a password manager would get much adoption if it refused to save the passwords you already have?
Google's password manager does nag you about bad passwords, but it's easy to ignore.
Looks like it's been around ten years since it was introduced. It doesn't seem like enough.
Microsoft and Google forced organizations that were using their services to upgrade to 2FA over a few years. For a short bit it was optional, after that it's basically not possible to use these services without 2FA. Now even many grandmas are familiar with the idea that sometimes you have to copy a code from your sms to a website when logging into your bank account.
They could have done the same thing with passwords. They have 100s of millions of organizational users, who will do whatever corporate IT tells them to do. Microsoft can say, there is a password manager available on Windows. From now on, organizational users must use 100 entropy bit passwords. IT tells users - users must store passwords in the password manager and use the browser extension.
After three years of users resisting, everyone will give in. Same for university students, who will need it. After that the rest will adopt easily because it is the default thing to do.
The article explains the weaknesses of the password-centric approach:
> whether by phishing or exploiting the fact the passwords are weak or have been reused
1. Phishing is harder when you only ever enter your password into 1 place, and that one place is designed to be secure and consistent.
2. Much easier to have exactly 1 strong password than unique strong passwords for every website.
Is it better than a vault full of random passwords? Probably not, beyond pressuring the user into using the more secure method
So your real issue here is with credential managers, but I'll bite. In most cases the vault is not protected only with your master password, but with other cryptographic info that prevents the vault from being opened on untrusted devices. If one of your trusted devices is compromised, I guess you have other issues.
Uhhh, how does that interact with:
> Users are largely unsure about the implications for their passkeys if they lose or break their device, as it seems their device holds the entire capability to authenticate. To trust passkeys as a replacement for the password, users need to be prepared and know what to do in the event of losing one – or all – of their devices.
From the article... Passkeys:
- are generated securely and so can’t be guessed - can’t be phished - are unique for each website you use, so if one website is compromised it doesn’t put your other logins at risk
The better question is: how are passkeys safer given that the recovery flow will be the same SMS or email based approach everyone uses today?
At its core, the main drawbacks that need to be solved for them to be a viable option are imo:
* Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.
* Device loss scenario is already mentioned, although more broadly speaking a lot of the reasons people get leery is because all three major providers (Google, Microsoft, Apple) are notorious for their near black box technical support. Losing access to one of these providers on its own is already enough to heavily disrupt the average person's life. Having your login details stored with them makes this even worse.
* The FIDO Alliance Is Way Too Excited About Device Attestation And I Don't Like It. Basically the FIDO Alliance's behavior around passkeys reeks of security theater and them badgering an open source password manager for daring to let users export their passkeys in the format they preferred, rather than what the FIDO Alliance wanted (which is that passkeys must always be encrypted with a password) is telling. If they are as secure as promised, it's a bad look to start threatening device attestation as a means to get people to comply with your specific idea of security. The only real barrier right now to it outright being a thing is that Apple zeroes out the field and when Apple is the only meaningful halt to that kind of attestation, something has gone very wrong.
I think passkeys are interesting, but I just flat out don't trust the FIDO Alliance with the idea. They're way too invested in big tech being good stewards of the ecosystem, which is becoming increasingly unpalatable as more and more evidence piles up that they're really bad actors on everything else. (So why should we trust them with our credentials?) The idea genuinely has value (it's literally the same kind of mechanism as SSH keys), but the hostility towards user freedom is deeply concerning and a blocker to getting people to use it. Even non-technical people seem leery of them, just because of how aggressively big tech has been pushing it.
God if it could just be a single key that you dump to paper or titanium plate and don't worry about backing up a zoo of keys/password with a cloud. Just take my one and only public key. If you care about per service privacy, you are welcome to use multiple. I don't think there is any compromise scenario where you would leak any single specific passkey and they are not bruteforcable. Why is it not as simple as that?
> * Improving OS flows. Every passkey implementer that's also an OS gets really excited about enrolling you into their proprietary clouds, and using alternate flows to respect the users wish to use their own manager is usually hidden in confusing UI forms that don't feel consistent if you don't already know what you're doing.
You're kidding yourself if you think that this is something Microsoft, Apple, or Google are incentivized to solve. Microsoft is especially bad here - pushing their crappy products in Windows every chance they get. Once some marketing director gets the idea that this can improve retention in Outlook or something the UI will get more confusing and the dark patterns will get darker.
I never said they had an incentive to solve it. I said that it's one of the big blockers to getting regular adoption. It ought to be obvious that all these issues aren't a problem if you look at it through the big tech lens: why is it a problem when we're providing the service. They're a problem when you're a normal person with a healthy distrust of big tech companies.
In practice, I expect someone to figure out a way to break into/bypass the OS flow entirely with a less "big tech wants your private details" solution and that's what winds up getting adoption.
How are passkeys different from API keys or just random chains of characters?
And why can't we have the use of such keys enforced by an EU legislation so that all businesses allow users to login using such strings of random characters?
The world would then be a better place.
Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.
So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.
One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.
Passkeys are a private key stored on your device with the public key registered with the server.
Servers should allow multiple passkeys per user (so you can register multiple devices), but many don't.
X.509 already does that, and in a better way. It also makes it unnecessary to register multiple devices, if you allow certificate chains (the server would check the certificate chain; one of the was issued by the service and contains information about which account it is associated with; the other ones you can issue to yourself, optionally with more restricted permissions, and can be revoked or expire). That would also allow you to have passworded private keys, and/or to store one private key on a separate computer that is not connected to the internet to issue the other one to yourself in order to mitigate security issues (and you can revoke the certificate and make a new one if it is compromised or expires). X.509 also is not limited to only WWW, so it can be used with other protocols too.
That's an implementation detail users should not care about.
The bigger question is... why don't we replace the login/password combination with just a string of randomly generated characters and call it a day?
Why protect these strings of random characters from users, call them passkeys and advertise them on all street corners?
Feels like a devil's plot to strip us from all the rights to our devices.
public/private keypairs (and therefore passkeys) provide cryptographically secure anti-phishing properties that passwords cannot.
If you are not careful, you'll enter the random chains of characters into a phishing site.
But a phishing site can't steal your passkey and forward it to the real site, the passkey will just not work with the phishing site if you try using it there, it's locked to the authentic domain.
That's mumbo jumbo to me so far.
What's an authentic domain?
How is my passkey locked to it?
> How are passkeys different from API keys or just random chains of characters?
As far as I understand it, in the same way that a public/private keypair differs from a random chain of characters you are used to shoving into the "Authorization: Bearer XXXXXXX" header.
> How are passkeys different from API keys or just random chains of characters?
Passkeys are encrypyed so they can't be simply copied off your device.
So how are they better than API keys if I can not even backup them?
Passkeys are great because they get sync'ed to all your devices, which makes it really easy to share access to those websites with other people ( who have access to devices on your account ). Like a spouse.
What mechanism makes that happen?
Speaking of passkeys, could they be used to authenticate to a local application - say for unlocking a password vault (perhaps through a Yubikey)?
Probably not.
But YubiKey supports multiple protocols, one of them surely could work for your use case.
Nicely timed on the one year anniversary of FIDI Alliance's Credential Exchange Protocol and Credential Exchange Format. https://fidoalliance.org/fido-alliance-publishes-new-specifi... https://news.ycombinator.com/item?id=41847787
But afaik you still can't move Passkeys from Chrome or Safari to any other credential manager.
I was vaguely under the impression that there was a ton of push-back again import/export flows in general, that the CEP was going to be the only supported path. And it requires that your Credentials Manager have a public endpoint to send your credentials to. Which doesn't force but radically ups the challenge for individuals to self host or manage things themselves, will drive Passkeys to remain service provided only.
With governments upping their right to snoop, immoral intercept, it's hard to have too much hope that Passkeys can remain trustable & respectable. If the UK passes a law saying they can access all your keys, the odds are not in your favor that Google is going to make a Signal like stand & tell the UK to buzz off. It's unfortunate that these giant massive enterprises are so big are so many products all in one, because if there was a healthy Chrome business not tied to thousands of other profit lines, maybe Chrome would dare have some backbone & tell their majesty to go stick it where the sun don't shine. But these companies are so big that even the most immoral outrageous ridiculous laws end up being accepted. Passkeys seems like a huge painted target; maybe the next 15-20 years go by with no one trying to get in the cookie jar, but it seems inevitable that the moral rot and illegitimacy of governments will stoop down to making this good idea untenable & a joke, in a long enough time scale. Especially with the service-provider-only ecosystem that's being engineered and imposed here.