6 ms·

I am an engineer and have some insights on the discussions and developments around it. ITS NOT SIMPLE AT ALL 1. The idea was to provide a phishing resistant a

I am an engineer and have some insights on the discussions and developments around it. ITS NOT SIMPLE AT ALL 1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing). 2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential. 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in. 5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices. 6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well Personally its a mess, the phishing resistant aspect has its own benefits though. If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.

pishpash 3mo ago
It should have never been a cloud password manager play. It should be hardware device only, and tied to the device. One passkey on each hardware device.
- jallmann 3mo ago
  That leads to the cross-device usability issues from the original post. Even for an experienced engineer, it's a headache to manage multiple devices across multiple sites. With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.
- Someone1234 3mo ago
  Then most of us would never use it. That means either: - Only one specific device can ever login (bad). - It doesn't limit login to one specific device, therefore it does nothing. Linking Passkeys to a physical device was always DoA. At least not without a way to enroll every device you own, and strong recovery strategies. But considering how inconsistent every company's Passkey implementation is (inc. many that only allow ONE TOTAL!), it is DoA.
  - thewebguyd 3mo ago
    > Only one specific device can ever login That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" > It doesn't limit login to one specific device, therefore it does nothing. It's not nothing. It provides an attestation that you the user are in physical possession of the device, and have passed the challenge to release the key form the TPM (biometrics, pin, something like a yubikey). Giving your private key to a cloud password vault makes it phishable again (via an attacker getting acsess to your vault, just like with passwords). The private keys are supposed to be non-exportable, and the cloud password managers defeat that as well.
    - sib 3mo ago
      >> Only one specific device can ever login > That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" Unfortunately, given the laziness, incompetence, and cost-consciousness of organizations like traditional financial institutions, telcos, governments, etc., many of them have & will end up with that implementation.
    - tialaramex 3mo ago
      > That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers... 1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit. 2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.
- Zak 3mo ago
  Then I wouldn't use it, and I would probably stop using services that tried to push me in to it. I use multiple devices and I want to log in to things using only my master password. I also want to be able to back up my credentials to local encrypted storage so I can restore them if my password manager service provider stops operating or becomes untenable.
smelendez 3mo ago
Yes, this is exactly the problem. Multiple pieces of software vying to be your passkey provider, often using dark patterns so you don’t realize you’re making a choice, and not using the term “passkey” so people are using the technology without knowing what it is or how to research it. Kind of reflects the state of the web today, where every company wants to be your intermediary in every interaction, from making a purchase to transcribing a meeting.
- thewebguyd 3mo ago
  > Multiple pieces of software vying to be your passkey provider, Which entirely defeats the point of using passkeys. There shouldn't be a passkey provider the "provider" is your device's TPM/secure enclave + your biometric challenge. They are supposed to be mathematically non-exportable, device-bound.
  - sib 3mo ago
    Yeah - and as a user, I don't want my device manufacturer to have that level of influence or control over the authentication that I use for unrelated services.
  - JohnFen 3mo ago
    > They are supposed to be mathematically non-exportable, device-bound. Which would make the whole scheme unworkable (at least for me).
    - l11r 3mo ago
      I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.
      - crote 3mo ago
        Except enrollability. Got a new account? You need physical access to both tokens to enroll it. Got a new token? You'll have to individually enroll every website - provided they even support multiple tokens at all... Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.
otabdeveloper4 3mo ago
WebAuthn is the standard for token authentication. (I.e., Yubikeys and other USB sticks.) It works fine and it a no-brainer to use. The problems start when vendors start trying to shoehorn their shitty cloud auth services into WebAuthn.
- NetMageSCW 3mo ago
  How well does that Yubikey work with an iPhone?
  - sandeepkd 3mo ago
    Works just fine, you have to get the one with NFC
    - bugcheck7b 3mo ago
      You can also plug them in to the USB-C port, works just fine.
      - akdev1l 3mo ago
        Some functionality is not supported via USB-C. Namely HMAC Challenge does not work via usb-c but will work via lighting port.
  - thyristan 3mo ago
    iPhones are a lost cause.
    - bdamm 3mo ago
      Passkeys on my iPhone works awesome. Too bad for Yubikey. I don't need them any more.
  - iamnothere 3mo ago
    Works great, they even have ones with USB on one side and Lightning on the other for older iPhones.
iamnothere 3mo ago
I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor, to protect against the theft or compromise of your primary device. I’m a little afraid that hardware tokens are getting lost in all the passkey marketing BS. At least they continue to work for now.
- jesseendahl 3mo ago
  > I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor. >to protect against the theft or compromise of your primary device. I love Yubikeys, but the only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session. And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/ https://w3c.github.io/webappsec-dbsc/ I have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.
  - deleted 3mo ago
    [deleted]
jesseendahl 3mo ago
There are some parts of this that are correct and other parts that are incorrect: >1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing). This is incorrect. The idea was to provide a phishing resistant primary factor that could compete with the usability of passwords to the point that consumers would actually want to adopt it. >2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers This is correct/accurate. > 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential. IIRC at least Chrome's default on Apple platforms is to save to the Passwords app by default. There are then multiple fallback options in the case that the user isn't using the default credential provider -- ultimately falling back all the way to cross-device passkey sign-in (the QR-code initiated sign in) or Security Key. The security engineering behind the QR-code cross-device sign-in stuff is interesting: https://www.corbado.com/blog/webauthn-passkey-qr-code#4-passkeys-qr-code https://www.corbado.com/blog/webauthn-passkey-qr-code#4-pass... That said, I strongly agree that fragmentation of where passkeys get saved is super confusing and I wish there: (a) was stronger guidance from the FIDO alliance on both educating users that it's totally fine to have multiple passkeys across different ecosystems (e.g. one in Apple, one in Google), and; (b) that all the credential managers could figure out a better way to place nice together and make it super clear to the end-user where a passkey is getting stored, what context it's for (e.g. personal vs. work), and actively help them store it in the right place (which might be different credential manager app for personal vs. work!). > 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in. This is incorrect -- passkeys are not just another name for WebAuthn. If you go back and look at the original definition Apple gave for the word passkey, you'll find that it was meant to be a discoverable WebAuthn credential that syncs across a user's devices with end-to-end encryption. There was a bunch of industry thrash around the definition, but it seems like the original Apple definition has largely stuck/settled now, and when passkeys don't sync they're typically called "device-bound passkeys" rather than just "passkeys". >5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices. If you go back and watch the original passkeys announcement from Apple, their stated goal was to create something that is both a better user experience and more secure than passwords. By "better user experience", they meant the act of creating credentials and then repeatedly using those credentials (logging in). Part of actually achieving that goal means there needs to be something that "just works automatically out of the box" which means there needs to be a built-in credential manager. That said, Apple credential manager had already existed for many many years by the time passkeys came around. The only thing that changed was instead of being solely accessible from inside System Settings (which was hard for the average user to find), the functionality moved into a standalone Passwords app. >6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well I think it's a huge positive that all the password managers jumped on board, and that they could jump on board (since WebAuthn is an open standard). I think this is a good thing for consumer choice and for overall adoption and perception of passkeys. A lot of folks (including on this thread) have big tech lock-in conspiracy theories about passkeys, and the conspiracy theories would be even more prevalent without a wide spectrum of consumer choice for credential managers. >If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective. Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation. The only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session. And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/ https://w3c.github.io/webappsec-dbsc/
xg15 3mo ago
> The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing). Honest question: If the main issue is phishing, why wasn't something like Yubikey adopted more widely - or dongles, or the venerable chip cards we have since the 80s? Everyone knows what a key is - I mean the thing you open doors with. Most people know the basic security implications as well as what to do if you lose one. The simplest way to translate that to "electronic keys" would be a dongle or chip card - that lets a device use its identity as long as its plugged in, but is not physically locked to that device. A user can unplug it, take it home with them or plug it into a different device. What a user can't do is copy them, so the same phishing protections as with passkeys are provided. But for some reason, this never caught on except for niche solutions. Instead, the industry is increasingly moving to systems where the keys are fused with the devices themselves, using TPMs or similar technologies that can't be removed from the device. Which gives you all the well-kniwn hassles if keys have to be moved or devices get lost or stolen. But I don't understand why this is done.

pishpash 3mo ago

It should have never been a cloud password manager play. It should be hardware device only, and tied to the device. One passkey on each hardware device.

jallmann 3mo ago
That leads to the cross-device usability issues from the original post. Even for an experienced engineer, it's a headache to manage multiple devices across multiple sites. With the "cloud password manager" angle there is some hope of being user friendly, although we're certainly not there yet for most folks.
Someone1234 3mo ago
Then most of us would never use it. That means either: - Only one specific device can ever login (bad). - It doesn't limit login to one specific device, therefore it does nothing. Linking Passkeys to a physical device was always DoA. At least not without a way to enroll every device you own, and strong recovery strategies. But considering how inconsistent every company's Passkey implementation is (inc. many that only allow ONE TOTAL!), it is DoA.
- thewebguyd 3mo ago
  > Only one specific device can ever login That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" > It doesn't limit login to one specific device, therefore it does nothing. It's not nothing. It provides an attestation that you the user are in physical possession of the device, and have passed the challenge to release the key form the TPM (biometrics, pin, something like a yubikey). Giving your private key to a cloud password vault makes it phishable again (via an attacker getting acsess to your vault, just like with passwords). The private keys are supposed to be non-exportable, and the cloud password managers defeat that as well.
  - sib 3mo ago
    >> Only one specific device can ever login > That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" Unfortunately, given the laziness, incompetence, and cost-consciousness of organizations like traditional financial institutions, telcos, governments, etc., many of them have & will end up with that implementation.
  - tialaramex 3mo ago
    > That's entirely service dependent, and the standard doesn't mandate "Service must not allow multiple passkeys" In fact WebAuthn is explicit that you should allow multiple tokens. But every time I see an HN thread it has people who insist this doesn't work or at least isn't common. When asked for examples, if they give any answers... 1. Most often these are sites where you can't use this technology at all. They'll have TOTP or something and apparently "I don't know anything about this" == "I know everything there is to know about this topic" in the increasingly LLM-crazy world we inhabit. 2. Usually otherwise it's AWS. Which is pretty annoying, but it's one site. I have like a couple of dozen places where I use WebAuthn and in all of those two (or three, or in a few cases four) tokens are enrolled. I don't have an AWS account, my employer is a Microsoft-only shop in this respect.
Zak 3mo ago
Then I wouldn't use it, and I would probably stop using services that tried to push me in to it. I use multiple devices and I want to log in to things using only my master password. I also want to be able to back up my credentials to local encrypted storage so I can restore them if my password manager service provider stops operating or becomes untenable.

smelendez 3mo ago

Yes, this is exactly the problem. Multiple pieces of software vying to be your passkey provider, often using dark patterns so you don’t realize you’re making a choice, and not using the term “passkey” so people are using the technology without knowing what it is or how to research it. Kind of reflects the state of the web today, where every company wants to be your intermediary in every interaction, from making a purchase to transcribing a meeting.

thewebguyd 3mo ago
> Multiple pieces of software vying to be your passkey provider, Which entirely defeats the point of using passkeys. There shouldn't be a passkey provider the "provider" is your device's TPM/secure enclave + your biometric challenge. They are supposed to be mathematically non-exportable, device-bound.
- sib 3mo ago
  Yeah - and as a user, I don't want my device manufacturer to have that level of influence or control over the authentication that I use for unrelated services.
- JohnFen 3mo ago
  > They are supposed to be mathematically non-exportable, device-bound. Which would make the whole scheme unworkable (at least for me).
  - l11r 3mo ago
    I pair of hardware keys (Token2, Yubico, etc) has the benefits from both worlds.
    - crote 3mo ago
      Except enrollability. Got a new account? You need physical access to both tokens to enroll it. Got a new token? You'll have to individually enroll every website - provided they even support multiple tokens at all... Yubikey tried to solve this, for obvious reasons. Their proposal was DOA.

otabdeveloper4 3mo ago

WebAuthn is the standard for token authentication. (I.e., Yubikeys and other USB sticks.) It works fine and it a no-brainer to use. The problems start when vendors start trying to shoehorn their shitty cloud auth services into WebAuthn.

NetMageSCW 3mo ago
How well does that Yubikey work with an iPhone?
- sandeepkd 3mo ago
  Works just fine, you have to get the one with NFC
  - bugcheck7b 3mo ago
    You can also plug them in to the USB-C port, works just fine.
    - akdev1l 3mo ago
      Some functionality is not supported via USB-C. Namely HMAC Challenge does not work via usb-c but will work via lighting port.
- thyristan 3mo ago
  iPhones are a lost cause.
  - bdamm 3mo ago
    Passkeys on my iPhone works awesome. Too bad for Yubikey. I don't need them any more.
- iamnothere 3mo ago
  Works great, they even have ones with USB on one side and Lightning on the other for older iPhones.

iamnothere 3mo ago

I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor, to protect against the theft or compromise of your primary device. I’m a little afraid that hardware tokens are getting lost in all the passkey marketing BS. At least they continue to work for now.

jesseendahl 3mo ago
> I don’t see hardware tokens (like Yubikey) in the list. Those are the only ones that provide a true second factor passkeys are not meant to be a second factor; they are meant to replace the password as a primary factor. >to protect against the theft or compromise of your primary device. I love Yubikeys, but the only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session. And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/ https://w3c.github.io/webappsec-dbsc/ I have no idea if Yubico is involved with DBSC, but I would hope that they are, because it would help them make Yubikeys live up to the security guarantees that I personally feel are heavily implied by their marketing.
- deleted 3mo ago
  [deleted]

jesseendahl 3mo ago

There are some parts of this that are correct and other parts that are incorrect: >1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing). This is incorrect. The idea was to provide a phishing resistant primary factor that could compete with the usability of passwords to the point that consumers would actually want to adopt it. >2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers This is correct/accurate. > 3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential. IIRC at least Chrome's default on Apple platforms is to save to the Passwords app by default. There are then multiple fallback options in the case that the user isn't using the default credential provider -- ultimately falling back all the way to cross-device passkey sign-in (the QR-code initiated sign in) or Security Key. The security engineering behind the QR-code cross-device sign-in stuff is interesting: https://www.corbado.com/blog/webauthn-passkey-qr-code#4-passkeys-qr-code https://www.corbado.com/blog/webauthn-passkey-qr-code#4-pass... That said, I strongly agree that fragmentation of where passkeys get saved is super confusing and I wish there: (a) was stronger guidance from the FIDO alliance on both educating users that it's totally fine to have multiple passkeys across different ecosystems (e.g. one in Apple, one in Google), and; (b) that all the credential managers could figure out a better way to place nice together and make it super clear to the end-user where a passkey is getting stored, what context it's for (e.g. personal vs. work), and actively help them store it in the right place (which might be different credential manager app for personal vs. work!). > 4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in. This is incorrect -- passkeys are not just another name for WebAuthn. If you go back and look at the original definition Apple gave for the word passkey, you'll find that it was meant to be a discoverable WebAuthn credential that syncs across a user's devices with end-to-end encryption. There was a bunch of industry thrash around the definition, but it seems like the original Apple definition has largely stuck/settled now, and when passkeys don't sync they're typically called "device-bound passkeys" rather than just "passkeys". >5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices. If you go back and watch the original passkeys announcement from Apple, their stated goal was to create something that is both a better user experience and more secure than passwords. By "better user experience", they meant the act of creating credentials and then repeatedly using those credentials (logging in). Part of actually achieving that goal means there needs to be something that "just works automatically out of the box" which means there needs to be a built-in credential manager. That said, Apple credential manager had already existed for many many years by the time passkeys came around. The only thing that changed was instead of being solely accessible from inside System Settings (which was hard for the average user to find), the functionality moved into a standalone Passwords app. >6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well I think it's a huge positive that all the password managers jumped on board, and that they could jump on board (since WebAuthn is an open standard). I think this is a good thing for consumer choice and for overall adoption and perception of passkeys. A lot of folks (including on this thread) have big tech lock-in conspiracy theories about passkeys, and the conspiracy theories would be even more prevalent without a wide spectrum of consumer choice for credential managers. >If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective. Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation. The only additional protection you get by making the passkey hardware-bound is preventing an attacker who has already compromised your operating system from stealing the credential. But! Unless you are also doing hardware binding of the session (aka cookie) after sign-in, then doing hardware binding of your credential is mostly security theater, because the attacker can just wait for you to sign in and then steal your session. And there is standards work happening separately for hardening session security, such as DBSC: https://w3c.github.io/webappsec-dbsc/ https://w3c.github.io/webappsec-dbsc/

xg15 3mo ago

> The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing). Honest question: If the main issue is phishing, why wasn't something like Yubikey adopted more widely - or dongles, or the venerable chip cards we have since the 80s? Everyone knows what a key is - I mean the thing you open doors with. Most people know the basic security implications as well as what to do if you lose one. The simplest way to translate that to "electronic keys" would be a dongle or chip card - that lets a device use its identity as long as its plugged in, but is not physically locked to that device. A user can unplug it, take it home with them or plug it into a different device. What a user can't do is copy them, so the same phishing protections as with passkeys are provided. But for some reason, this never caught on except for niche solutions. Instead, the industry is increasingly moving to systems where the keys are fused with the devices themselves, using TPMs or similar technologies that can't be removed from the device. Which gives you all the well-kniwn hassles if keys have to be moved or devices get lost or stolen. But I don't understand why this is done.