5 ms·

> A passkey is a synced, discoverable WebAuthn credential. This is my fundamental problem with passkeys: I don't want to use any syncing service. To be clear,

by lapcat 2y ago

> A passkey is a synced, discoverable WebAuthn credential. This is my fundamental problem with passkeys: I don't want to use any syncing service. To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors. It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.

ylk 2y ago
Just use a password manager that doesn't sync by itself then https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
- g_p 2y ago
  The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA. The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials. That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts. I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).
  - ylk 2y ago
    I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware. https://www.yubico.com/blog/empowering-enterprise-security-at-scale-with-new-product-innovations-yubikey-5-7-and-yubico-authenticator-7/ https://www.yubico.com/blog/empowering-enterprise-security-a... However, I don't know whether it's possible to delete only a single resident key you no longer need.
    - g_p 2y ago
      Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution). This adds another step needing considered for a user, as finite storage means a whole edge case to consider (can't register as slots full), and no simple actionable step to take ("which account would you like to never be able to log into again?" or "sorry you need to wipe this key and lose everything, or buy another one") I feel there is a usability aspect of FIDO2 (for non-resident MFA) that is being overlooked - the paradigm was simple - a physical key you don't lose, and you can have multiple keys. The gotcha was no way to replicate backup keys, which becomes fairly difficult for users. But hey - passkeys launched with no export or migration process between closed device ecosystems! From my perspective though, I won't use passkeys until I get sufficient control over them to be allowed to decide if I want to make them "resident" or not. (I don't want resident keys!!) I want to use non-resident keys everywhere as a hardware-backed second factor that is phishing resistant, without capacity limitations (so zero cognitive burden on whether to use or not). It feels like a regression for passkeys to be forgetting about what (for me at least) was the core basic use-case of FIDO2 - as a highly secure second factor for someone who already can manage storage of secrets in software, and just wants high assurance phishing resistant MFA during their conventional login process.
      - formerly_proven 2y ago
        > Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution). You can, it’s part of CTAP2 and various apps like Yubico Authenticator are available to do it. It’s not user-friendly, but it is possible.
- lapcat 2y ago
  There's no browser extension available for Safari: https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_browser_integration https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_b...
  - lxgr 2y ago
    For macOS/iOS, you could give Strongbox a try: https://strongboxsafe.com/ https://strongboxsafe.com/ I haven't really looked into it myself, but it seems to be using the same database format as KeePass, and it hooks into macOS's "FIDO provider" API, which makes it accessible to not only Safari but all browsers that use it (which includes Firefox and Chrome on macOS, and probably everything on iOS), without requiring any browser-side extension.
amlozano 2y ago
This is the exact reason I self host vault warden. I get all the convenience of syncing passkeys, but know that I am the only one with access to the back-end. I am also slightly paranoid as a security engineer, and admit that whole heartedly.
- g_p 2y ago
  I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move. I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA. Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...
  - briHass 2y ago
    I'm also waiting for a password manager that tightly integrates with a hardware device to protect passwords individually and in-memory. I wrote a quick PoC using certificates to encrypt a password, with the cert private key 'stored' in the TPM, with a PIN. This is pretty easy on Windows, which exposes the TPM as a special crypto provider.
    - g_p 2y ago
      That's a pretty neat solution. I like that idea. If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used. If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs. That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.
deleted 2y ago
[deleted]
lxgr 2y ago
> The vendors claim that this is to make phishing impossible They do? I don't see how, since non-discoverable WebAuthN credentials make phishing just as impossible. The only thing discoverable credentials allow on top of non-discoverable ones is avoiding having the user type in their username or email address.
- drhuseynov 2y ago
  yes, that is for "usernameless" login, in addition to passwordless. Does not increase security, improves usability a bit
Elucalidavah 2y ago
Not to mention that a better security would involve a master key, and revocable subkeys signed with it, one for each device, instead of syncing. Not to mention n-of-m requirements. And sure, I understand that most people need the paternalistic form, whey they are not given any guns and are also unable to export their keys from some service. For example, with TOTP, the key is given to the user in the QR code, but common authenticator apps are unable to export the same data after it was imported. But not all; and the only bad thing about this is that the export restriction is a surprise to those who didn't expect it.
somat 2y ago
I was messing with implementing webauthn the other day, mainly because I like public key authentication. I was hoping for something sort of like ssh keys. and they were close, so close, to having something good that could replace password auth. and then they break it by requiring a hardware token, Yes, a hardware token is better, but I am not going to require users get a hardware token. there are working software token systems built into the browser but they are gated behind dev tools, again something I am not going to ask of users. and just to spit in whatever goodwill they have left, to make it really unusable, there is this weird mandated "no user interface" policy in the standard. making near impossible to manage keys. The keys are critical in a public key auth system. but "no, we are disallowed, by the standard, to give you an easy mechanism to back up and restore keys" If I were more conspiracy minded, I would suspect some sort of agent provocateur ruining our standards. However, I am unable to come up with a profit motive, so my only conclusion is incompetence.
- formerly_proven 2y ago
  You used to be able to generate X.509 client authentication certificates (well technically CSR) right in the browser with the since removed <keygen> tag. Ergonomics weren’t that bad, until a user forgot they had a certificate on their broken PC.
  - lxgr 2y ago
    As somebody that used to use them for a while: The ergonomics of TLS client authentication in the browser were abysmal. And that's to say nothing about the privacy consequences.
    - formerly_proven 2y ago
      iirc managing them was buried super-deep in the browser settings (just like managing resident keys, browsers don’t even do that), but enrollment was fairly simple from a user PoV - submit a form and the server sent back the certificate, iirc you had to confirm a scarily worded dialog (or maybe import it manually? Not sure). Login was smooth if I remember it - just a pop-up if you want to use the installed certificate. Privacy should be fine with TLS 1.3 but would’ve been nonexistent with the contemporary SSL/TLS versions of course.
no_wizard 2y ago
At some point, you have to trust something. Thats how I feel about WebAuthN and syncing services. Ideally, some of this could actually be solved by having a government organization that provides this and is regularly updated / audited etc. but in the US at least, we are not in any place for that to happen, so you need to pick a provider. Apple is reasonably good at this, if you're in their ecosystem. Can't speak for Google. 1Password has been very good to me as well, and there are Yubikeys too. Nothing is perfect, but this is a far, far far better state than were it was heading before WebAuthN
- lapcat 2y ago
  > At some point, you have to trust something. If by "something" you mean an internet syncing service, then no, I don't. I do trust my own backup methodology.
  - no_wizard 2y ago
    Some service. I’m not saying you have to trust what I trust. Personally I’m a big 1Password fan and have been in the Apple ecosystem for a very long time as well. Most security folks I trust also vouch for them, as far as practices and effectiveness goes of their software. But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases. The one thing I really like about Yubikey is it doesn’t require a network connection at all to work, but it never caught on generally for that model to be widespread supported so I have found while I do use my Yubikey a fair amount there are still things that don’t accept it that I wish did
    - lapcat 2y ago
      > But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases. Again, no, I don't, and you still haven't explained why. Unless you mean that the big tech companies will force me to use a sync service whether I want it or not. Moreover, you've ignored my point about paid subscriptions.

by lapcat 2y ago

ylk 2y ago

Just use a password manager that doesn't sync by itself then https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys

g_p 2y ago
The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA. The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials. That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts. I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).
- ylk 2y ago
  I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware. https://www.yubico.com/blog/empowering-enterprise-security-at-scale-with-new-product-innovations-yubikey-5-7-and-yubico-authenticator-7/ https://www.yubico.com/blog/empowering-enterprise-security-a... However, I don't know whether it's possible to delete only a single resident key you no longer need.
  - g_p 2y ago
    Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution). This adds another step needing considered for a user, as finite storage means a whole edge case to consider (can't register as slots full), and no simple actionable step to take ("which account would you like to never be able to log into again?" or "sorry you need to wipe this key and lose everything, or buy another one") I feel there is a usability aspect of FIDO2 (for non-resident MFA) that is being overlooked - the paradigm was simple - a physical key you don't lose, and you can have multiple keys. The gotcha was no way to replicate backup keys, which becomes fairly difficult for users. But hey - passkeys launched with no export or migration process between closed device ecosystems! From my perspective though, I won't use passkeys until I get sufficient control over them to be allowed to decide if I want to make them "resident" or not. (I don't want resident keys!!) I want to use non-resident keys everywhere as a hardware-backed second factor that is phishing resistant, without capacity limitations (so zero cognitive burden on whether to use or not). It feels like a regression for passkeys to be forgetting about what (for me at least) was the core basic use-case of FIDO2 - as a highly secure second factor for someone who already can manage storage of secrets in software, and just wants high assurance phishing resistant MFA during their conventional login process.
    - formerly_proven 2y ago
      > Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution). You can, it’s part of CTAP2 and various apps like Yubico Authenticator are available to do it. It’s not user-friendly, but it is possible.
lapcat 2y ago
There's no browser extension available for Safari: https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_browser_integration https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_b...
- lxgr 2y ago
  For macOS/iOS, you could give Strongbox a try: https://strongboxsafe.com/ https://strongboxsafe.com/ I haven't really looked into it myself, but it seems to be using the same database format as KeePass, and it hooks into macOS's "FIDO provider" API, which makes it accessible to not only Safari but all browsers that use it (which includes Firefox and Chrome on macOS, and probably everything on iOS), without requiring any browser-side extension.

amlozano 2y ago

This is the exact reason I self host vault warden. I get all the convenience of syncing passkeys, but know that I am the only one with access to the back-end. I am also slightly paranoid as a security engineer, and admit that whole heartedly.

g_p 2y ago
I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move. I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA. Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...
- briHass 2y ago
  I'm also waiting for a password manager that tightly integrates with a hardware device to protect passwords individually and in-memory. I wrote a quick PoC using certificates to encrypt a password, with the cert private key 'stored' in the TPM, with a PIN. This is pretty easy on Windows, which exposes the TPM as a special crypto provider.
  - g_p 2y ago
    That's a pretty neat solution. I like that idea. If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used. If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs. That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.

deleted 2y ago

[deleted]

lxgr 2y ago

> The vendors claim that this is to make phishing impossible They do? I don't see how, since non-discoverable WebAuthN credentials make phishing just as impossible. The only thing discoverable credentials allow on top of non-discoverable ones is avoiding having the user type in their username or email address.

drhuseynov 2y ago
yes, that is for "usernameless" login, in addition to passwordless. Does not increase security, improves usability a bit

Elucalidavah 2y ago

Not to mention that a better security would involve a master key, and revocable subkeys signed with it, one for each device, instead of syncing. Not to mention n-of-m requirements. And sure, I understand that most people need the paternalistic form, whey they are not given any guns and are also unable to export their keys from some service. For example, with TOTP, the key is given to the user in the QR code, but common authenticator apps are unable to export the same data after it was imported. But not all; and the only bad thing about this is that the export restriction is a surprise to those who didn't expect it.

somat 2y ago

I was messing with implementing webauthn the other day, mainly because I like public key authentication. I was hoping for something sort of like ssh keys. and they were close, so close, to having something good that could replace password auth. and then they break it by requiring a hardware token, Yes, a hardware token is better, but I am not going to require users get a hardware token. there are working software token systems built into the browser but they are gated behind dev tools, again something I am not going to ask of users. and just to spit in whatever goodwill they have left, to make it really unusable, there is this weird mandated "no user interface" policy in the standard. making near impossible to manage keys. The keys are critical in a public key auth system. but "no, we are disallowed, by the standard, to give you an easy mechanism to back up and restore keys" If I were more conspiracy minded, I would suspect some sort of agent provocateur ruining our standards. However, I am unable to come up with a profit motive, so my only conclusion is incompetence.

formerly_proven 2y ago
You used to be able to generate X.509 client authentication certificates (well technically CSR) right in the browser with the since removed <keygen> tag. Ergonomics weren’t that bad, until a user forgot they had a certificate on their broken PC.
- lxgr 2y ago
  As somebody that used to use them for a while: The ergonomics of TLS client authentication in the browser were abysmal. And that's to say nothing about the privacy consequences.
  - formerly_proven 2y ago
    iirc managing them was buried super-deep in the browser settings (just like managing resident keys, browsers don’t even do that), but enrollment was fairly simple from a user PoV - submit a form and the server sent back the certificate, iirc you had to confirm a scarily worded dialog (or maybe import it manually? Not sure). Login was smooth if I remember it - just a pop-up if you want to use the installed certificate. Privacy should be fine with TLS 1.3 but would’ve been nonexistent with the contemporary SSL/TLS versions of course.

no_wizard 2y ago

At some point, you have to trust something. Thats how I feel about WebAuthN and syncing services. Ideally, some of this could actually be solved by having a government organization that provides this and is regularly updated / audited etc. but in the US at least, we are not in any place for that to happen, so you need to pick a provider. Apple is reasonably good at this, if you're in their ecosystem. Can't speak for Google. 1Password has been very good to me as well, and there are Yubikeys too. Nothing is perfect, but this is a far, far far better state than were it was heading before WebAuthN

lapcat 2y ago
> At some point, you have to trust something. If by "something" you mean an internet syncing service, then no, I don't. I do trust my own backup methodology.
- no_wizard 2y ago
  Some service. I’m not saying you have to trust what I trust. Personally I’m a big 1Password fan and have been in the Apple ecosystem for a very long time as well. Most security folks I trust also vouch for them, as far as practices and effectiveness goes of their software. But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases. The one thing I really like about Yubikey is it doesn’t require a network connection at all to work, but it never caught on generally for that model to be widespread supported so I have found while I do use my Yubikey a fair amount there are still things that don’t accept it that I wish did
  - lapcat 2y ago
    > But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases. Again, no, I don't, and you still haven't explained why. Unless you mean that the big tech companies will force me to use a sync service whether I want it or not. Moreover, you've ignored my point about paid subscriptions.