4 ms·

I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - ins

I'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run. I think that's what you're getting at in paragraph 3? There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.

Xelynega 3y ago
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
- kxrm 3y ago
  > even by the user Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why. I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
  - sodality2 3y ago
    Personally it bothers me, and I don't want to feel any different. If I can't back it up or share it, it's not something I want to use. It's different than something like TOTP where even though I can't functionally hand-calculate it, I can still move the secret anywhere I want
  - nullfield 3y ago
    No, you’re smart to feel this. See the previously linked comment from someone upset that KeyPassXC lets users export: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course. The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain. Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill. As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
- jackson1442 3y ago
  > It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices. [0]: https://w3c.github.io/webauthn/ https://w3c.github.io/webauthn/
- tsimionescu 3y ago
  > The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user). That's simply false, and there are passkey managers that allow this - KeePassXC for example.
- red_admiral 3y ago
  It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.

Xelynega 3y ago

It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).

kxrm 3y ago
> even by the user Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why. I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
- sodality2 3y ago
  Personally it bothers me, and I don't want to feel any different. If I can't back it up or share it, it's not something I want to use. It's different than something like TOTP where even though I can't functionally hand-calculate it, I can still move the secret anywhere I want
- nullfield 3y ago
  No, you’re smart to feel this. See the previously linked comment from someone upset that KeyPassXC lets users export: https://github.com/keepassxreboot/keepassxc/issues/10407 https://github.com/keepassxreboot/keepassxc/issues/10407 When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course. The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain. Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill. As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
jackson1442 3y ago
> It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves. Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices. [0]: https://w3c.github.io/webauthn/ https://w3c.github.io/webauthn/
tsimionescu 3y ago
> The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user). That's simply false, and there are passkey managers that allow this - KeePassXC for example.
red_admiral 3y ago
It feels ... suspicious ... to me that in 2024, we're designing a new authentication scheme explicitly around resident keys, but challenge-response is optional. Credentials in any new protocol should never be sent over the wire, period.