I only need one provider. A portable open source encrypted database I'm in control of and can back up and secure as needed. It's what I have now, and have had for years, in my password manager. I won't be at the mercy of a company or a device to access my digital life.
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.
The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.
Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials.
Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
Are there any examples of any widely-used sites that are enforcing attestation?
- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)
- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
Certainly a password manager like keepass would be no more complicated than trying to explain to her that she can no longer access her account because she broken her phone.
I think the whole point of yubikeys is to make this impossible.
IIUC basically these devices contain one single immutable random secret that is stored in a tamper proof hardware and can never leave the device nor be written into another device.
When you "create" new keys what actually happens under the hood is that a new value gets stored in flash memory which is the _combined_ with the hard secret with some key derivation scheme and the resulting secret is then the one used to perform cryptographic operations
Yes, but nothing prevents someone from making a hardware security token that has a copyable memory. Some people will have a threat model where this is acceptable.
The recommendation is to use two keys or to always have an additional backup method configured. So you should never be in a position where a migration is required.
Hardware tokens are physical objects that are subject to mechanical wear and tear and can be lost. Hardware tokens are also subject to ending up on a hardware attestation blacklist because of security weaknesses.
I have already had to replace two Yubikeys for the aforementioned reasons, so FIDO hardware token migration is a very real scenario that desperately needs to be addressed.
Also mind that there are too many services that allow you to only use one FIDO token, or even worse, only one primary 2FA method in addition to backup codes.
Does this include a way for a technically-savvy user to 'repatriate' their passkeys into their own infrastructure? (i.e. If I want to be my own provider)
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
That might be the company going bankrupt, a physical or digital disaster, geopolitical firewalls, or simply a Kafka-esque bureaucracy where your entire account has been deleted without appeal because the company decided it was easier than figuring out the truth behind some moderation issue.
Can you not just set up a new passkey using a different provider (eg. Bitwarden)? It is a bit inconvenient, since it has to be done manually for every site.
How does this suddenly become a problem when as the user I want access to my keys, but it isn't a problem when corporations copy my keys between them, which is what this post is about?
> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.
> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.
> In the end, they control every protocol, become the gatekeepers for the web.
I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(
It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.
KeepassXC actually supports passkeys and can be a passkey provider in a desktop browser.
And Android 14 seems to allow changing the passkey provider in the android system as well. With that, the only thing left would be a KeepassXC-compatible app that can serve as provider on android, using the same database as the desktop.
With that setup, I'd be willing to use passkeys exclusively (my phone is still Android 13 and I don't know about app support). I already can't login anywhere (important) without access to my password manager.
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
Idk I just set up both - email&password which live in my password manager and then passkeys for convenience - I can just hit a button without thinking and I’m in.
It’s probably different for everyone but in case I have strictly separate devices- so a laptop where I have my work accounts and a desktop for games and some personal stuff.
I don’t really use anything on a regular basis that needs accounts on my personal devices, but that’s probably very weird nowadays…
I already hit a button (the Bitwarden icon in my browser toolbar) so I do not see what passkeys buy me, except a terrible hassle the day I want to change password manager.
It is a solution designed to lock people in the Apple/Google walled gardens, and I don't see why everybody is pushing for it.
> I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
There seems to be a lot of misunderstanding of passkeys indeed. They're in no way different than that random password stored in your password manager and can be (with this standard you're commenting on) moved around wherever you want them.
All passkey sites also support fallbacks to just password or other auth mode.
>> All passkey sites also support fallbacks to just password or other auth mode.
Is this a guaranteed thing? Are we saying any account I create cannot be Created with just a pass key; and that no site or service is able to discontinue the password option?
AFAIK, you can register your passkeys using your own provider (eg. Bitwarden). I’ve not personally used it too much, but the option is there.
The remaining issue is moving the credentials between providers, which is an annoying limitation. But you can always add a different passkey to the site using the provider you want, so although annoying it is not the end of the world…
The original limitation is similar to the usability of actual physical security keys, which (depending on the setup mode) are deliberately designed such that the private key material is not recoverable. Software based keys don’t HAVE to share the same limitation, but it seems more like a missing feature than attributing malice to the creators of the spec.
Do you use the same SSH keys on multiple devices? I certainly don't. If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
> Do you use the same SSH keys on multiple devices?
Yes. For example, when upgrading or reinstalling a system
> If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
`scp -r`
> the "provider" is the OS, same as with my SSH keys.
And you have full access to ~/.ssh and you can move copy update rename delete them however you like. Without a "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)" to move between blackboxes of third-party providers
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.
Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.
The idea that this should have been “extremely simple” is just standard hubris.
> The idea that this should have been “extremely simple” is just standard hubris.
Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.
The hint of why this may be just slightly complicated is in that final phrase.
> The hint of why this may be just slightly complicated is in that final phrase.
The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.
ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.
It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org
Unlike your photo collection, passkeys aren’t precious. They’re just meaningless data. You can and should generate additional ones for each password manager you use, so you have multiple independent ways of getting into an account. As long as you can do that, everything is replaceable and there’s no lock-in.
Similarly, I wouldn’t copy a private key for ssh to a new laptop. I generate a new one and copy the public key instead. It makes it easier to revoke access to the old computer.
I do think this new spec will sometimes be useful for populating a new password manager, though.
I know you’re applying the same model as for SSH keys (and functionally they are very similar) … but I also think 1 SSH key/device is impractical if you have many services to log into and many devices to log in from - which is just the reality nowadays.
Imagine having to use a specific password for each service/device combination.
Instead we don’t tie passwords to devices, but to users, to avoid this complexity.
The proposal that any time o create an account o need multiple physical tokens or multiple password managers running is unbelievably stupid & fantastical. This whole project is doomed doomed doomed of this is the model.
I've never seen a single sight suggest this either. Many have set up passkeys, but not one has prompted me to create a second. I have downloaded a lot of backup keys though.
Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically; the current proposal that users need to gather all their security tokens & add each one is an absolute promise this technology is going to flop.
I bring it up because people claim there is lock-in and it’s not true.
Apple and Google both replicate between devices, so there is some replication, within ecosystems. I only need to create a passkey twice per account so I can use both. It’s not a big deal, though replicating between them would be better.
And so I am clearly not locked in. (Not because of passkeys, anyway.) If people think they’re locked in then it’s a “can’t be bothered” sort of lock-in.
> Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.
I only need one provider. A portable open source encrypted database I'm in control of and can back up and secure as needed. It's what I have now, and have had for years, in my password manager. I won't be at the mercy of a company or a device to access my digital life.
That's cool, but the last thing I would want my mom to have to manage is a portable open source encrypted database shes's in control of and can back up and secure as needed.
Great; but, as long as a system supports the open solution, anyone can provide for you the closed one, while the opposite isn't the case.
And Passkeys is an open solution, what are you all going on about?
There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.
The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.
The original thread:
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.
The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.
Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.
Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.
The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.
The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.
Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials. Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.
Passkeys are just resident webauthn tokens with a fancy name.
Where's the lockin?
The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.
The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).
Are there any examples of any widely-used sites that are enforcing attestation?
Two comes to mind:
- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)
- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)
My mum has a password notebook which is locked away in a drawer in her house, she knows to use either passphrases or random string that her browser generates for her. For her threat model this is better than any software thing.
Certainly a password manager like keepass would be no more complicated than trying to explain to her that she can no longer access her account because she broken her phone.
OK. Let me know when I can migrate FIDO credentials from old Yubikeys to new ones.
Earlier this year I almost lost a domain because $REGISTRAR forced 2FA and I had forgotten to add them to my key spreadsheet.
I think the whole point of yubikeys is to make this impossible.
IIUC basically these devices contain one single immutable random secret that is stored in a tamper proof hardware and can never leave the device nor be written into another device.
When you "create" new keys what actually happens under the hood is that a new value gets stored in flash memory which is the _combined_ with the hard secret with some key derivation scheme and the resulting secret is then the one used to perform cryptographic operations
Yes, but nothing prevents someone from making a hardware security token that has a copyable memory. Some people will have a threat model where this is acceptable.
you can technically do that but that would be a very confusing use of the name "hardware security token".
You can already use your phone today to store secrets with an acceptable threat model.
Yeah whole point of YubiKey is that the physical key is REQUIRED and can't be cloned. So no, you won't be able export anything off of it.
You're correct about how key creation works as well AFAIK.
The recommendation is to use two keys or to always have an additional backup method configured. So you should never be in a position where a migration is required.
Hardware tokens are physical objects that are subject to mechanical wear and tear and can be lost. Hardware tokens are also subject to ending up on a hardware attestation blacklist because of security weaknesses.
I have already had to replace two Yubikeys for the aforementioned reasons, so FIDO hardware token migration is a very real scenario that desperately needs to be addressed.
Also mind that there are too many services that allow you to only use one FIDO token, or even worse, only one primary 2FA method in addition to backup codes.
Yes. My other Yubikey is in a bank vault.
I do not want a remote "authentication provider".
If you want a Webauthn credential that you can "copy", don't use a Yubikey. Use something like KeepassXC, BitWarden etc. instead.
Does this include a way for a technically-savvy user to 'repatriate' their passkeys into their own infrastructure? (i.e. If I want to be my own provider)
I would also be concerned about whether you can recover when a provider becomes unusable or hostile, and there is no cooperative migration path.
That might be the company going bankrupt, a physical or digital disaster, geopolitical firewalls, or simply a Kafka-esque bureaucracy where your entire account has been deleted without appeal because the company decided it was easier than figuring out the truth behind some moderation issue.
At a minimum we will see if KeePass is a provider that is supported; they seem to be the only pw manager in town that respect user freedom.
Can you not just set up a new passkey using a different provider (eg. Bitwarden)? It is a bit inconvenient, since it has to be done manually for every site.
A bit is understatement. If this passkeys become widespread, we are talking about like 100 sites.
If you go for passkeys, start putting them in your own provider from the start? Vaultwarden is a nice option.
There shouldn't be. Secure enclaves aren't secure if they can be copied
How does this suddenly become a problem when as the user I want access to my keys, but it isn't a problem when corporations copy my keys between them, which is what this post is about?
I had hope for passkeys, with all the interop-promises.
It turned out that no (mainstream) passkey provider allows backups however, making them infinitely worse than just using passwords.
Maybe this will help, but fuck me, it’s all complicated, especially for a damn foundational security mechanism!
It could be so simple, just look at SSH keys, which I think largely use the same principle.
You can create backup keys by creating more passkeys.
I came across an opinion I largely agree with: https://mastodon.social/@lapcatsoftware/113308133338196824 and https://mastodon.social/@lapcatsoftware/113308273654667583
> These big tech companies will do anything possible to prevent users from ever actually being able to access their own passkeys.
> Export and import should have been extremely simple. Instead, they took years to come up with some convoluted system where the only possibility is to transfer from one vendor lock-in to another vendor lock-in.
> With passkeys, the big tech companies are executing a coup d'état of authentication, just like they did for HTML itself.
> In the end, they control every protocol, become the gatekeepers for the web.
So it's not just me!
I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
If I show up naked, I can login to the system via password but I am conpletely useless with a pass key. And for somebody like myself who uses multiple devices daily (two phones, two tablets, several laptops and desktops), it seems a nightmare to set them all up or maintain:-(
It feels a system designed for those who live by their phone and trust some specific service provider with their life. I'm not in either of those categories :-(. I still don't understand what the "Keepass, "little black notebook", and "good memory" equivalents are.
KeepassXC actually supports passkeys and can be a passkey provider in a desktop browser.
And Android 14 seems to allow changing the passkey provider in the android system as well. With that, the only thing left would be a KeepassXC-compatible app that can serve as provider on android, using the same database as the desktop.
With that setup, I'd be willing to use passkeys exclusively (my phone is still Android 13 and I don't know about app support). I already can't login anywhere (important) without access to my password manager.
Can confirm: Using Android 14 and Bitwarden, I can sign in to github.com using my passkey. It pops up a system dialog where I can select Bitwarden and then my Github username.
Last time I checked, the Bitwarden Vault export included the whole FIDO credential including the private key.
Idk I just set up both - email&password which live in my password manager and then passkeys for convenience - I can just hit a button without thinking and I’m in.
It’s probably different for everyone but in case I have strictly separate devices- so a laptop where I have my work accounts and a desktop for games and some personal stuff.
I don’t really use anything on a regular basis that needs accounts on my personal devices, but that’s probably very weird nowadays…
I already hit a button (the Bitwarden icon in my browser toolbar) so I do not see what passkeys buy me, except a terrible hassle the day I want to change password manager.
It is a solution designed to lock people in the Apple/Google walled gardens, and I don't see why everybody is pushing for it.
Passkeys work fine with password managers like 1Password, KeePassXC, Bitwarden and others, why do you keep repeating this walled garden shtick?
They're literally a cryptostring stored in your password manager just like your other passwords.
> They're literally a cryptostring stored in your password manager just like your other passwords.
So I can copy paste them somewhere or move them around without "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)"?
You can copy paste them using those formats. What are you arguing about here actually?
With Keepass you can, at least. Other ones not so much.
> I feel like I either misunderstand pass keys or live in some twilight zone where they're ok even though I cannot wrote them down or memorize them, I can only have invisible magic stuck on my phone.
There seems to be a lot of misunderstanding of passkeys indeed. They're in no way different than that random password stored in your password manager and can be (with this standard you're commenting on) moved around wherever you want them.
All passkey sites also support fallbacks to just password or other auth mode.
>> All passkey sites also support fallbacks to just password or other auth mode.
Is this a guaranteed thing? Are we saying any account I create cannot be Created with just a pass key; and that no site or service is able to discontinue the password option?
They are different from passwords in that they are never send over the web. They are a private key used to sign a challenge from the site.
> They're in no way different than that random password stored in your password manager
Except in all the ways that matter: they are not accessible to users, they are tied to third-party vendors.
That's an outright lie now, isn't it?
The second one is particularly pertinent:
> Passkeys are essentially site-specific cryptographic keypairs, which are fine, combined with big tech company paternalism, which is intolerable.
AFAIK, you can register your passkeys using your own provider (eg. Bitwarden). I’ve not personally used it too much, but the option is there.
The remaining issue is moving the credentials between providers, which is an annoying limitation. But you can always add a different passkey to the site using the provider you want, so although annoying it is not the end of the world…
The original limitation is similar to the usability of actual physical security keys, which (depending on the setup mode) are deliberately designed such that the private key material is not recoverable. Software based keys don’t HAVE to share the same limitation, but it seems more like a missing feature than attributing malice to the creators of the spec.
> AFAIK, you can register your passkeys using your own provider (eg. Bitwarden).
Why should we even need a third-party provider? Imagine needing a third-party "provider" for your own ssh keys.
If you only want first-party, you can presumably implement the spec yourself and do whatever you want with the data?
My example was only to point out that there exist self-hostable passkey providers.
Do you use the same SSH keys on multiple devices? I certainly don't. If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
When I use passkeys on a single device, the "provider" is the OS, same as with my SSH keys.
> Do you use the same SSH keys on multiple devices?
Yes. For example, when upgrading or reinstalling a system
> If you need or wanted to (you don't) you'd need some way to sync them across multiple devices securely.
`scp -r`
> the "provider" is the OS, same as with my SSH keys.
And you have full access to ~/.ssh and you can move copy update rename delete them however you like. Without a "Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF)" to move between blackboxes of third-party providers
This is an exceptionally cynical take. WebAuthn is an open standard; this new credential transfer spec is the opposite of “big vendor lock-in”. It’s standardising the export-import.
Standards are slow and expensive to create and evolve. They involve endless meetings, discussion and design. However, the outcome is freedom.
The idea that this should have been “extremely simple” is just standard hubris.
> This is an exceptionally cynical take.
> However, the outcome is freedom.
This is an exceptionally naive take.
> The idea that this should have been “extremely simple” is just standard hubris.
Why? Export-import of passwords is extremely simple and can be done with copy-paste or CSV. The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.
> FIDO Alliance’s credential exchange specifications define a standard format for transferring all types of credentials in a credential manager including passwords, passkeys and more in a manner that is secure by default.
The hint of why this may be just slightly complicated is in that final phrase.
> The hint of why this may be just slightly complicated is in that final phrase.
The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.
ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.
It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org
> The only thing preventing this with passkeys is the paternalistic idea that users of passkeys should not be allowed to access them directly.
This is, of course, also the thing that makes passkeys uniquely unphishable.
That's a bit like saying a house fire is what makes your deleted files uniquely safe from recovery.
The sentence is true, as far as it goes... But it's uniquely excessive, rather than the unique minimum sufficient for the task.
Unlike your photo collection, passkeys aren’t precious. They’re just meaningless data. You can and should generate additional ones for each password manager you use, so you have multiple independent ways of getting into an account. As long as you can do that, everything is replaceable and there’s no lock-in.
Similarly, I wouldn’t copy a private key for ssh to a new laptop. I generate a new one and copy the public key instead. It makes it easier to revoke access to the old computer.
I do think this new spec will sometimes be useful for populating a new password manager, though.
I know you’re applying the same model as for SSH keys (and functionally they are very similar) … but I also think 1 SSH key/device is impractical if you have many services to log into and many devices to log in from - which is just the reality nowadays.
Imagine having to use a specific password for each service/device combination. Instead we don’t tie passwords to devices, but to users, to avoid this complexity.
It’s certainly not my reality. I have a desktop computer and a laptop that I use ssh from. How many computers do you have?
The proposal that any time o create an account o need multiple physical tokens or multiple password managers running is unbelievably stupid & fantastical. This whole project is doomed doomed doomed of this is the model.
I've never seen a single sight suggest this either. Many have set up passkeys, but not one has prompted me to create a second. I have downloaded a lot of backup keys though.
Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically; the current proposal that users need to gather all their security tokens & add each one is an absolute promise this technology is going to flop.
I bring it up because people claim there is lock-in and it’s not true.
Apple and Google both replicate between devices, so there is some replication, within ecosystems. I only need to create a passkey twice per account so I can use both. It’s not a big deal, though replicating between them would be better.
And so I am clearly not locked in. (Not because of passkeys, anyway.) If people think they’re locked in then it’s a “can’t be bothered” sort of lock-in.
Clearly not fantastical since I’m doing it.
> Sorry to be on blast here but every time passkeys come up the "use multiple keys" gets said & it's a joke. There needs to be a flow where I can create a passkey & have it replicate to a bunch of devices automatically
Choose a passkey provider that supports this then. I use bitwarden. Other people use iOS keychain. Both work great.