6 ms·

A potentially good idea got corrupted by vendors, password managers, browsers, etc trying to assert control. I'm also an engineer and I find the UI around passk

A potentially good idea got corrupted by vendors, password managers, browsers, etc trying to assert control. I'm also an engineer and I find the UI around passkeys entirely unclear, but it doesn't have to be that way. It seems like everyone wants to be _the_ password manager for all your passkeys. They don't want to make it easy to understand that is what they are doing though, they just happily offer to "handle it for you". My non-technical friends are extremely confused by passkeys and if they should use them and how to use them and I honestly don't have very good answers. It is a mess. I don't believe an inherit mess, but one created by the companies and projects trying to take advantage of the new system.

thewebguyd 2mo ago
> It seems like everyone wants to be _the_ password manager for all your passkeys. Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised. Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).
- Someone1234 2mo ago
  Right; but THAT idea is consumer hostile by design. So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.
  - thewebguyd 2mo ago
    > Right; but THAT idea is consumer hostile by design. No argument from me there, just stating what the design actually calls for. It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning. But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.
    - unscaled 2mo ago
      The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are: 1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO. 2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F. I might be wrong but at least these are the two parts I know. And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard. It doesn't mean they are not confusing, but they are clearly designed with end users in mind.
    - marysol5 2mo ago
      Eh, PassKeys are consumer friendly by virtue of allowing the keys to be synced across multiple devices. That actually breaks some of the security of it for the benefit of the end user. No end user wants to export and store a keychain. So they hand that off to somewhere else.
- TitaRusell 2mo ago
  This is exactly all the stuff normal people don't care about. If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.
  - thewebguyd 2mo ago
    I mean, no one ever said it was a good design. But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use. It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.
    - inquirerGeneral 2mo ago
      [dead]
  - sib 2mo ago
    Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.
- jesseendahl 2mo ago
  > Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case. What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple. The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
  - phs318u 2mo ago
    > the only possible way to compete with that UX is to sync the private key across the user’s devices This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys). Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.
    - Ajedi32 2mo ago
      "A better version of password syncing" is exactly what Passkeys are and ought to be. Just like passwords, but unphishable, unguessable, not reusable across sites, not vulnerable to data breaches, and with better UX. Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.
      - inigyou 2mo ago
        So just a password manager?
- dotancohen 2mo ago
  > Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey). I have just shy of 2000 site credentials in Keepass. Let's assume that they were all Passkeys. 1) When I buy a new device, how do I create 2000 new Passkeys for that device? 2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost. 3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?
  - ilchalpenl 2mo ago
    Apple's keychain or google password manager - can hold 2000 passkeys easily.
    - Petersipoi 2mo ago
      Did you not read the comment thread you're responding to?
    - blochist 2mo ago
      Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?
      - nightski 2mo ago
        No you don't. I use the same passkeys for all my devices sync'd with bitwarden.
        crote 2mo ago
        Exactly. Bitwarden, not the Apple/Google/Microsoft keychain. That's the problem.
      - ilchalpenl 2mo ago
        Not at the moment. But if you sign into google account in iPhone then you can use Google's passkeys in iPhone. At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No. A majority will benefit. End of matter. A majority don't change platforms (I have not seen them do it). And lets be honest - even if they were portable are you privacy person that is going to do it? No.
- packetlost 2mo ago
  > Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey). This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't. Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate. The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.
  - unscaled 2mo ago
    Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA. Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now. What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.
    - ivlad 2mo ago
      I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.
    - marysol5 2mo ago
      Lest we forget that enterprises have had passwordless auth long before any of this
  - michaelt 2mo ago
    > Passkeys are primarily meant to replace passwords Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors. Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.
- richstokes 2mo ago
  Device-bound would be a nightmare. I don’t want to have to think about different credential for phone vs. laptop, etc.
  - crote 2mo ago
    Easy: it's the token on your physical keyring, right next to your house key and car key.
    - Telaneo 2mo ago
      I have 7 house keys and 2 car keys. Getting a new house key is a breeze and cheap, and even if I lose them all, a lock smith can make me whole again. Getting a new car key is a bit more expensive, but also largely not a hassle. Having spare Yubikeys is more of a hassle than both of those (and more expensive!), and the worst case scenario of losing them all is much more catastrophic. If I have no house key, I still get into my house. If I have no car key, I still get into my car (after a fair bit of hassle). If I have no Yubikey, I have permanently lost access to the accounts it was tied to. If physical hardware tokens were as cheap as house keys and not much more difficult to set up and copy, then it would be kind of reasonable. As it is, it's unworkable. Even password managers manage to make this work. You can throw your database on every storage device you have and write the master password down on paper, and the chances of you not being able to have access to it are pretty darn close to zero.
      - coffe2mug 2mo ago
        No one is forcing you. You can continue to use passwordmanager. We are talking about the rest the people that want convenience. In a way that is the reason passkeys synced with Google or Apple just work. No need of hardware keys.
  - anticensor 2mo ago
    It's not a nightmare, in fact different sessions of the same user could be used to grant different capability levels across sessions depending on the trust level.
- jimbokun 2mo ago
  Seems like the flow should be: 1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device. It’s presented to the user as a convenience clearly tied to this device. …but you still have your text password stored in the password manager’s servers…
  - akdev1l 2mo ago
    By still having the password the user can still be attacked via phishing
    - thewebguyd 2mo ago
      The user can always be attacked via phishing so long as account recovery methods exist (and they need to exist for obvious reasons). Use passkeys, but so long as you can also log in via password, or SMS code, etc., it's phishable, you can get sim swapped. Your master password to your cloud PW manager's vault is also phishable (hence why passkeys were ideally device specific, non-exportable). Its phishing resistant not phishing proof
      - akdev1l 2mo ago
        > hence why passkeys were ideally device specific, non-exportable Not true. The original concept was always for them to be cloud synced. This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not. You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”. > Your master password to your cloud PW manager's vault is also phishable No, it’s not. You would need to steal my yubikey to get access.
- jknoepfler 2mo ago
  I do not want my identity to be device-bound. I want it to be me-bound.
  - thewebguyd 2mo ago
    That's self sovereign identity. But you still need someones that can issue those verifiable credentials, and we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth? Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information). Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.
    - jknoepfler 2mo ago
      Put yourself in the role of a consumer for a second. As a consumer, I don't give a shit. I use my driver's license to apply to jobs, my passport to fly, and a password (with 2FA depending on how much I / my employer cares) for everything else. I prefer whatever I use for 2FA to not be device-bound, because that's obnoxious, error-prone and constraining. As a consumer, I don't see any reason for my auth to be more complicated than that.
    - TeMPOraL 2mo ago
      > we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth? Yes? I mean, that's what literally is there by default in every country. They're not either/or either, they're part of a chain. Most importantly, none of that is device-bound. Or even person-bound. Which allows for delegation, which is a feature that cybersecurity people keep insisting is not real.
  - crote 2mo ago
    How do we verify that you are you? It can't be linked to fingerprints, iris scans, or DNA, as those are trivially leaked, impossible to change, and a privacy nightmare. Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.
- j0057 2mo ago
  In the Apple ecosystem, passkeys are stored in your iCloud, and access to the passkeys is device bound. So if I generate a passkey on a MacBook, I can then use it from my iPhone as well, because it's encrypted to all my hardware devices.
  - phs318u 2mo ago
    Replace the word passkey with password in your comment. What’s the benefit of passkeys again? If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud? The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.
    - krferriter 2mo ago
      A random website breach can't disclose your password either, assuming you use random high-entropy passwords and the website only stores a hash of it. I haven't really seen the benefit to passkeys over passwords. Pretty much everyone is using a password management service that securely syncs both passwords and passkeys across devices. In that context I don't see the difference.
      - thewebguyd 2mo ago
        > Pretty much everyone is using a password management service In the US, only about 34 to 36% of adults use a password manager. Of the ~64% that don't, an alarming 20% reuse the same password across almost every service, and a ton just rely on browser autofill. If you use a password manager, you are in the minority. Hell, even if you don't use a PW manager and you at least use a different password for different services, you are ahead of most people. The general population is largely computer illiterate, and have a staggering lack of basic security hygiene.
        inigyou 2mo ago
        FWIW, browser autofill is a basic password manager.
- merb 2mo ago
  Wouldn’t it be better to use envelope encryption and sync the passkeys? I mean with envelope encryption somebody would probably be able to create a rfc that would support cross browser/password manager sync a passkey by using a encrypted envelope that would be able to be deceptively wither via tpm or by using credentials so when syncing it would ask for upn/password of the original device or something so it can even be e2e encrypted, so some kind of federation protocol for password managers that you own
- Lammy 2mo ago
  I don't want my computer to be able to decide I'm not allowed to access something. I'll never use these.
- account42 2mo ago
  Good. Device bound keys are a mistake.
- jjav 2mo ago
  > supposed to be device-bound Device bound is horribly broken idea. Credentials must be me-bound, so I and only me fully own and control the credential. I want to access the site from wherever I want to access it.
  - inquirerGeneral 2mo ago
    [dead]
- BetterThanSober 2mo ago
  Device bound is a bad idea especially if in the future sites is designed to be fail secure, you might be able to recover your account but not your data. The provider will then have to take a negative PR risk for something they cannot do People lose their device all the time, there's tons of horror story where people got locked out because they lost their sole method of 2FA and if there is a method to bypass that then it is inherently insecure For the layman yeah it is probably enough
- zombot 2mo ago
  > they are supposed to be device-bound Which in and of itself should already be a super obvious total no-go. Every device will eventually go out of service or will be decommissioned, for a multitude of reasons. Then what, I lose all access, because I went from an iPhone to Android? WTF?
- lazide 2mo ago
  Except I literally never want to have auth tied to a device. That’s ridiculous.
inigyou 2mo ago
If a good idea falls apart when confronted with reality, it's a bad idea.
m-p-3 2mo ago
What I find particularly annoying on Windows is that it tries to take over the Passkey workflow with Windows Hello. I wish I could just tell it to not handle Passkeys at all, and let me deal with it through my Password Manager (KeePassXC) and my hardware tokens (2 YubiKeys).
YetAnotherNick 2mo ago
How is it corrupted by vendors and password manager? Why is password manager being passkey so bad or do you believe password manager should have no role there? How would it look if it wasn't corrupted?

thewebguyd 2mo ago

> It seems like everyone wants to be _the_ password manager for all your passkeys. Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound, the private key held in the TPM or secure enclave or whatever other security chip, mathematically non-exportable. Storing all your private keys in a cloud vault still leaves you exposed to potential credential theft if your vault gets compromised. Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

Someone1234 2mo ago
Right; but THAT idea is consumer hostile by design. So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.
- thewebguyd 2mo ago
  > Right; but THAT idea is consumer hostile by design. No argument from me there, just stating what the design actually calls for. It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning. But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.
  - unscaled 2mo ago
    The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are: 1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO. 2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F. I might be wrong but at least these are the two parts I know. And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard. It doesn't mean they are not confusing, but they are clearly designed with end users in mind.
  - marysol5 2mo ago
    Eh, PassKeys are consumer friendly by virtue of allowing the keys to be synced across multiple devices. That actually breaks some of the security of it for the benefit of the end user. No end user wants to export and store a keychain. So they hand that off to somewhere else.
TitaRusell 2mo ago
This is exactly all the stuff normal people don't care about. If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.
- thewebguyd 2mo ago
  I mean, no one ever said it was a good design. But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use. It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.
  - inquirerGeneral 2mo ago
    [dead]
- sib 2mo ago
  Stronger than "don't care about" (at least if I and some friends I've discussed this with count as normal people): this is actively what I don't want! I want control over my authentication and I don't want it bound to device, browser, OS, etc.
jesseendahl 2mo ago
> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case. What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple. The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
- phs318u 2mo ago
  > the only possible way to compete with that UX is to sync the private key across the user’s devices This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys). Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.
  - Ajedi32 2mo ago
    "A better version of password syncing" is exactly what Passkeys are and ought to be. Just like passwords, but unphishable, unguessable, not reusable across sites, not vulnerable to data breaches, and with better UX. Stranding private keys in clone resistant secure enclaves has unacceptably bad UX for the average user, which is why very few implementations try to do that.
    - inigyou 2mo ago
      So just a password manager?
dotancohen 2mo ago
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey). I have just shy of 2000 site credentials in Keepass. Let's assume that they were all Passkeys. 1) When I buy a new device, how do I create 2000 new Passkeys for that device? 2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost. 3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?
- ilchalpenl 2mo ago
  Apple's keychain or google password manager - can hold 2000 passkeys easily.
  - Petersipoi 2mo ago
    Did you not read the comment thread you're responding to?
  - blochist 2mo ago
    Nothing in the post you're replying to is about "is 2000 passkeys storable", it's about "if I have 2000 passkeys and I need to move between an Apple device and an Android device, do I need to establish a second set of 2000 passkeys"?
    - nightski 2mo ago
      No you don't. I use the same passkeys for all my devices sync'd with bitwarden.
      - crote 2mo ago
        Exactly. Bitwarden, not the Apple/Google/Microsoft keychain. That's the problem.
    - ilchalpenl 2mo ago
      Not at the moment. But if you sign into google account in iPhone then you can use Google's passkeys in iPhone. At the end, passkeys are built not for the tin-foil, (I hate Google Apple fellows), I want to keep every single locally, RMS fans. No. A majority will benefit. End of matter. A majority don't change platforms (I have not seen them do it). And lets be honest - even if they were portable are you privacy person that is going to do it? No.
packetlost 2mo ago
> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey). This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't. Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate. The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.
- unscaled 2mo ago
  Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA. Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now. What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.
  - ivlad 2mo ago
    I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.
  - marysol5 2mo ago
    Lest we forget that enterprises have had passwordless auth long before any of this
- michaelt 2mo ago
  > Passkeys are primarily meant to replace passwords Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors. Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.
richstokes 2mo ago
Device-bound would be a nightmare. I don’t want to have to think about different credential for phone vs. laptop, etc.
- crote 2mo ago
  Easy: it's the token on your physical keyring, right next to your house key and car key.
  - Telaneo 2mo ago
    I have 7 house keys and 2 car keys. Getting a new house key is a breeze and cheap, and even if I lose them all, a lock smith can make me whole again. Getting a new car key is a bit more expensive, but also largely not a hassle. Having spare Yubikeys is more of a hassle than both of those (and more expensive!), and the worst case scenario of losing them all is much more catastrophic. If I have no house key, I still get into my house. If I have no car key, I still get into my car (after a fair bit of hassle). If I have no Yubikey, I have permanently lost access to the accounts it was tied to. If physical hardware tokens were as cheap as house keys and not much more difficult to set up and copy, then it would be kind of reasonable. As it is, it's unworkable. Even password managers manage to make this work. You can throw your database on every storage device you have and write the master password down on paper, and the chances of you not being able to have access to it are pretty darn close to zero.
    - coffe2mug 2mo ago
      No one is forcing you. You can continue to use passwordmanager. We are talking about the rest the people that want convenience. In a way that is the reason passkeys synced with Google or Apple just work. No need of hardware keys.
- anticensor 2mo ago
  It's not a nightmare, in fact different sessions of the same user could be used to grant different capability levels across sessions depending on the trust level.
jimbokun 2mo ago
Seems like the flow should be: 1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device. It’s presented to the user as a convenience clearly tied to this device. …but you still have your text password stored in the password manager’s servers…
- akdev1l 2mo ago
  By still having the password the user can still be attacked via phishing
  - thewebguyd 2mo ago
    The user can always be attacked via phishing so long as account recovery methods exist (and they need to exist for obvious reasons). Use passkeys, but so long as you can also log in via password, or SMS code, etc., it's phishable, you can get sim swapped. Your master password to your cloud PW manager's vault is also phishable (hence why passkeys were ideally device specific, non-exportable). Its phishing resistant not phishing proof
    - akdev1l 2mo ago
      > hence why passkeys were ideally device specific, non-exportable Not true. The original concept was always for them to be cloud synced. This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not. You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”. > Your master password to your cloud PW manager's vault is also phishable No, it’s not. You would need to steal my yubikey to get access.
jknoepfler 2mo ago
I do not want my identity to be device-bound. I want it to be me-bound.
- thewebguyd 2mo ago
  That's self sovereign identity. But you still need someones that can issue those verifiable credentials, and we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth? Arguably, that's the only way forward. SSI is also nice because you get to fully control what you share and don't share (e.g., age verification, you get to only share "I am over 21" and no other information). Passkeys were (are?) supposed to be just a password replacement though. That services are using them to replace a username AND a password AND 2FA is a problem that's turning the device into your identity, instead of keeping the identity as three parts (What you know, what you have, who you are (biometrics)). Now we've just turned the "something you have" into the entire identity stack.
  - jknoepfler 2mo ago
    Put yourself in the role of a consumer for a second. As a consumer, I don't give a shit. I use my driver's license to apply to jobs, my passport to fly, and a password (with 2FA depending on how much I / my employer cares) for everything else. I prefer whatever I use for 2FA to not be device-bound, because that's obnoxious, error-prone and constraining. As a consumer, I don't see any reason for my auth to be more complicated than that.
  - TeMPOraL 2mo ago
    > we (as a global society) can't decide who that should be in the web of trust? Our banks? Governments? Schools? Doctors at time of birth? Yes? I mean, that's what literally is there by default in every country. They're not either/or either, they're part of a chain. Most importantly, none of that is device-bound. Or even person-bound. Which allows for delegation, which is a feature that cybersecurity people keep insisting is not real.
- crote 2mo ago
  How do we verify that you are you? It can't be linked to fingerprints, iris scans, or DNA, as those are trivially leaked, impossible to change, and a privacy nightmare. Until we find a way to securely implant a Yubikey in people's brains, it isn't going to happen.
j0057 2mo ago
In the Apple ecosystem, passkeys are stored in your iCloud, and access to the passkeys is device bound. So if I generate a passkey on a MacBook, I can then use it from my iPhone as well, because it's encrypted to all my hardware devices.
- phs318u 2mo ago
  Replace the word passkey with password in your comment. What’s the benefit of passkeys again? If you’re not storing the actual private key in the Secure Enclave but only the “access to it” what’s changed from how Apple’s keychain already manages password syncing to iCloud? The only benefit (and it’s still a decent one) is that some random website breach can’t disclose your private key.
  - krferriter 2mo ago
    A random website breach can't disclose your password either, assuming you use random high-entropy passwords and the website only stores a hash of it. I haven't really seen the benefit to passkeys over passwords. Pretty much everyone is using a password management service that securely syncs both passwords and passkeys across devices. In that context I don't see the difference.
    - thewebguyd 2mo ago
      > Pretty much everyone is using a password management service In the US, only about 34 to 36% of adults use a password manager. Of the ~64% that don't, an alarming 20% reuse the same password across almost every service, and a ton just rely on browser autofill. If you use a password manager, you are in the minority. Hell, even if you don't use a PW manager and you at least use a different password for different services, you are ahead of most people. The general population is largely computer illiterate, and have a staggering lack of basic security hygiene.
      - inigyou 2mo ago
        FWIW, browser autofill is a basic password manager.
merb 2mo ago
Wouldn’t it be better to use envelope encryption and sync the passkeys? I mean with envelope encryption somebody would probably be able to create a rfc that would support cross browser/password manager sync a passkey by using a encrypted envelope that would be able to be deceptively wither via tpm or by using credentials so when syncing it would ask for upn/password of the original device or something so it can even be e2e encrypted, so some kind of federation protocol for password managers that you own
Lammy 2mo ago
I don't want my computer to be able to decide I'm not allowed to access something. I'll never use these.
account42 2mo ago
Good. Device bound keys are a mistake.
jjav 2mo ago
> supposed to be device-bound Device bound is horribly broken idea. Credentials must be me-bound, so I and only me fully own and control the credential. I want to access the site from wherever I want to access it.
- inquirerGeneral 2mo ago
  [dead]
BetterThanSober 2mo ago
Device bound is a bad idea especially if in the future sites is designed to be fail secure, you might be able to recover your account but not your data. The provider will then have to take a negative PR risk for something they cannot do People lose their device all the time, there's tons of horror story where people got locked out because they lost their sole method of 2FA and if there is a method to bypass that then it is inherently insecure For the layman yeah it is probably enough
zombot 2mo ago
> they are supposed to be device-bound Which in and of itself should already be a super obvious total no-go. Every device will eventually go out of service or will be decommissioned, for a multitude of reasons. Then what, I lose all access, because I went from an iPhone to Android? WTF?
lazide 2mo ago
Except I literally never want to have auth tied to a device. That’s ridiculous.

inigyou 2mo ago

If a good idea falls apart when confronted with reality, it's a bad idea.

m-p-3 2mo ago

What I find particularly annoying on Windows is that it tries to take over the Passkey workflow with Windows Hello. I wish I could just tell it to not handle Passkeys at all, and let me deal with it through my Password Manager (KeePassXC) and my hardware tokens (2 YubiKeys).

YetAnotherNick 2mo ago

How is it corrupted by vendors and password manager? Why is password manager being passkey so bad or do you believe password manager should have no role there? How would it look if it wasn't corrupted?