4 ms·

AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature

AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. And for things like Plaid, I think banks are moving towards OAuth-style permissions, where you login to your bank and authorize the connection. Under the hood, Plaid or other app can connect to the bank with limited permissions using API authorization keys. It's a different problem, I think.

tialaramex 3y ago
> AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.
- vladvasiliu 3y ago
  I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain. So now, if the service's domain were to change, it would presumably be aware of it and incorporate it in the new challenge, which the client would sign, since it's browsing the correct domain, with the same private key used before. Is this not how it works?
  - heavyset_go 3y ago
    FIDO2 allows for things like resident keys, which the Yubikey can only hold so many of. The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.
    - TheNewsIsHere 3y ago
      Most web based services don’t seem to be using the discoverable credentials either. So far only my Apple ID and Azure AD accounts are utilizing those.
      - deleted 3y ago
        [deleted]
  - tialaramex 3y ago
    Nope, but I can see why you'd expect that because the actual design is very clever and so it's not obvious how this could work. What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done: When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too. The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that. For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate. When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.
- deleted 3y ago
  [deleted]
detourdog 3y ago
It is essentially kerberos only Apple has managed to grow a coherent ticketing system for all hardware, services, and users. Each Developer essentially has their own ticket signing system. Apple can revoke any ticket at any time and a developer can revoke their own tickets.
microtonal 3y ago
AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. The credentials are scoped to a relying party, which must be equal to the domain or registrable domain suffix: https://www.w3.org/TR/webauthn-2/#scope https://www.w3.org/TR/webauthn-2/#scope If this wasn't the case and it was old-school public-key verification, it would still be vulnerable to phishing, since the phishing site could just forward the challenges.

tialaramex 3y ago

> AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. In principle the fancier systems with a user interface could add a feature where you can change the DNS names associated with a key it's storing. That sounds like a monumental pain in the backside, and of course the primary consequence would be it increases phishing because now your users can be tricked into allowing it - but sure, they could do that. For simpler devices like a Yubico Security Key, there is no such interface, they aren't storing any keys so there's no way to make such an association. The keys are bound to the DNS name and are actually stored (encrypted) by the sites you're actually authenticating to. So without a matching DNS name they're intentionally just useless nonsense.

vladvasiliu 3y ago
I may be wrong here, but since the yubikey and similar don't actually store anything site-specific, it means they just respond to a challenge, right? What they prove is that they own a specific private key. So if the website bundles its domain in the challenge, it can make sure that the client signed the challenge for itself, and the client can verify that it signs the challenge for the current domain. So now, if the service's domain were to change, it would presumably be aware of it and incorporate it in the new challenge, which the client would sign, since it's browsing the correct domain, with the same private key used before. Is this not how it works?
- heavyset_go 3y ago
  FIDO2 allows for things like resident keys, which the Yubikey can only hold so many of. The Yubikey can act in HMAC challenge mode, though, but that's not the mode used on the web.
  - TheNewsIsHere 3y ago
    Most web based services don’t seem to be using the discoverable credentials either. So far only my Apple ID and Azure AD accounts are utilizing those.
    - deleted 3y ago
      [deleted]
- tialaramex 3y ago
  Nope, but I can see why you'd expect that because the actual design is very clever and so it's not obvious how this could work. What's inside the cheapest authenticators isn't a private key, after all they present a unique random public key for every single enrolment, so that couldn't work if they held a single private key. Instead it's a symmetric key (e.g. AES-256). Lets see how that's done: When you enrol at a site, the authenticator mints a completely random new public/private key pair (with Elliptic curve crypto it's really easy to pick random key pairs because with a few bit ops any random bits become a random key) and after signing the enrolment step, the authenticator encrypts its new private key using that secret symmetric key and the DNS name in an authenticated encryption mode and provides that encrypted value too. The browser, with the authenticator's help, puts together the final enrolment document, with a signature and it includes that encrypted private key as a Unique Identifier. All the Unique Identifiers in the protocol are huge random looking numbers, so the encrypted key blends right in with that. For a web site, you need to store the public key (obviously) and this unique unique identifier value. You have to do that for everybody, anyway, it's mandatory. You can't decrypt the identifier even if you were sure it's encrypted, you don't know the key, so all you can do is play it back when you want a user to authenticate. When it's played back, the authenticator takes the web site's DNS name, plus its own secret key, and decrypts the identifier to get back its private key, which it can now use to sign authentication messages. Of course if the DNS name is wrong, the decryption fails, which is exactly the same thing as happens if you try to use the wrong authenticator, or you're being phished, or a dozen other things - the authentication can't succeed.
deleted 3y ago
[deleted]

detourdog 3y ago

It is essentially kerberos only Apple has managed to grow a coherent ticketing system for all hardware, services, and users. Each Developer essentially has their own ticket signing system. Apple can revoke any ticket at any time and a developer can revoke their own tickets.

microtonal 3y ago

AFAIK, passkeys aren't really linked to a domain. It's old-school public-key verification, the server stores your public key and uses it to verify the signature of a challenge they send to your device on login. As long as the different domains/apps can share the public key you should be able to login. The credentials are scoped to a relying party, which must be equal to the domain or registrable domain suffix: https://www.w3.org/TR/webauthn-2/#scope https://www.w3.org/TR/webauthn-2/#scope If this wasn't the case and it was old-school public-key verification, it would still be vulnerable to phishing, since the phishing site could just forward the challenges.