3 ms·

It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server

It seems likely that you know passkeys better than I do (you wrote a blog about them after all), so I've got a question. My impression is that there's a server side component. It's not just a key in your device, it's a key in your device that's blessed by someone who maintains a server. My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other. They can say: > sorry passkeys.jimbobsmomsbasement.com, you're not on the list of servers that I trust, so I'm not going to accept this key Quoting GP here: > Right now all my data is held by corporate types who don’t give a shit. Is it true that passkey providers will be able to use this feature band together and prevent passkey providers that they don't like from being useful? It was something about attestations--I didn't fully get it the first time it was explained to me. If so, doesn't that make the "corporate types who don't give a shit" problem worse? At least with a password the corporate types couldn't deny you the right to authenticate because in their estimation your password provider isn't corporate enough.

hirsin 3y ago
It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employees Yubikey 3s", they can instruct their idp to only accept passkeys for Yubikey 3s. This is a tradeoff - their employees can't register legitimate, useful personal passkeys like their phone, but an arbitrary (not dedicated nationstate) attacker is a bit less likely to somehow takeover the account and add a Feitian key. That mismatch is a nice signal to block the user. But in general, outside of corporate identities, no one has any interest in caring what kind of passkey you use. GitHub doesn't, certainly, outside of resident key requirements, a different bundle of fish. (and yes, Dan is definitely great at this stuff, read his blog on this stuff).
- __MatrixMan__ 3y ago
  I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure. The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only collects a retinal scan, not also DNA, or somesuch, and now we're in a race to the bottom re: just how authenticated one can be.
  - juped 3y ago
    It's hardly tinfoil hattery. If it isn't that (and I'm still not convinced by all the above that it isn't) then it needs to explain exactly how it isn't loudly, repeatedly, clearly, and very prominently.
    - __MatrixMan__ 3y ago
      The messaging around it sure has been heavy on the "you should do this it's better" and light on the "and here are the implications".
mooreds 3y ago
There's a server side component--a public key tied to the private key on a device you control. That public key is also tied to the website that you register the passkey too. > My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other. I haven't seen that in the specification. Every host is assigned one or more public keys (again, corresponding to private keys kept in the device), and I don't think there is a common identifier that could be shared between different hosts. Attestation is not required and seems atypical outside of enterprise use cases. I haven't seen it used at all for consumer use cases.
- __MatrixMan__ 3y ago
  So I did some hunting in the spec (which I should've done when I first heard this concern), so that I can be specific. I turned up this from https://w3c.github.io/webauthn/#attestation-object https://w3c.github.io/webauthn/#attestation-object > An important component of the attestation object is the attestation statement. This is a specific type of signed data object, containing statements about a public key credential itself and the authenticator that created it. It contains an attestation signature created using the key of the attesting authority (except for the case of self attestation, when it is created using the credential private key). The concern was about how creatively parties with a market interest in providing authentication services (1Password, Okta, Apple, Google) can use this field in service of goals that the user doesn't share, such as preventing competition. It's already the case that if you don't have a phone number you're in some ways a non-person because you can't 2fa with many services that require it. The same dynamic could be used to guarantee that everybody have a relationship with one of a small handful of providers such that they don't have to care about whether we consent to whatever new requirements they dream up. Maybe. I'll have to think about it a bit more. For instance, could this object one day contain an attestation that the user has a credit score above a certain threshold? That's the sort of thing that's new compared to passwords.

hirsin 3y ago

It's not a server-side component but something integral to the passkey itself. Everything is on the key and there's no third party - just the key, and the site you're authing to. So when you auth with a passkey, it includes some details around "this came from a Feitian model x or yubico model y or bitwarden or...". That's blank, IIRC, if it's Apple. And then if a corporate type has said "well we only gave our employees Yubikey 3s", they can instruct their idp to only accept passkeys for Yubikey 3s. This is a tradeoff - their employees can't register legitimate, useful personal passkeys like their phone, but an arbitrary (not dedicated nationstate) attacker is a bit less likely to somehow takeover the account and add a Feitian key. That mismatch is a nice signal to block the user. But in general, outside of corporate identities, no one has any interest in caring what kind of passkey you use. GitHub doesn't, certainly, outside of resident key requirements, a different bundle of fish. (and yes, Dan is definitely great at this stuff, read his blog on this stuff).

__MatrixMan__ 3y ago
I see, thank you. I suppose it also lets you reject keys from hardware platforms that are later determined to be insecure. The tinfoilhattery which I heard (and regret tangentially supporting on occasion) was that it was a slippery slope towards something like SSO, where some company (1Password, say) is your identity provider. And then other companies might reject your identity because hypothetically 1Password only collects a retinal scan, not also DNA, or somesuch, and now we're in a race to the bottom re: just how authenticated one can be.
- juped 3y ago
  It's hardly tinfoil hattery. If it isn't that (and I'm still not convinced by all the above that it isn't) then it needs to explain exactly how it isn't loudly, repeatedly, clearly, and very prominently.
  - __MatrixMan__ 3y ago
    The messaging around it sure has been heavy on the "you should do this it's better" and light on the "and here are the implications".

mooreds 3y ago

There's a server side component--a public key tied to the private key on a device you control. That public key is also tied to the website that you register the passkey too. > My further impression is that the people who manage the servers (either the authenticating-you server or the supporting-auth-for-you server) will be able to configure allow/deny lists for each other. I haven't seen that in the specification. Every host is assigned one or more public keys (again, corresponding to private keys kept in the device), and I don't think there is a common identifier that could be shared between different hosts. Attestation is not required and seems atypical outside of enterprise use cases. I haven't seen it used at all for consumer use cases.

__MatrixMan__ 3y ago
So I did some hunting in the spec (which I should've done when I first heard this concern), so that I can be specific. I turned up this from https://w3c.github.io/webauthn/#attestation-object https://w3c.github.io/webauthn/#attestation-object > An important component of the attestation object is the attestation statement. This is a specific type of signed data object, containing statements about a public key credential itself and the authenticator that created it. It contains an attestation signature created using the key of the attesting authority (except for the case of self attestation, when it is created using the credential private key). The concern was about how creatively parties with a market interest in providing authentication services (1Password, Okta, Apple, Google) can use this field in service of goals that the user doesn't share, such as preventing competition. It's already the case that if you don't have a phone number you're in some ways a non-person because you can't 2fa with many services that require it. The same dynamic could be used to guarantee that everybody have a relationship with one of a small handful of providers such that they don't have to care about whether we consent to whatever new requirements they dream up. Maybe. I'll have to think about it a bit more. For instance, could this object one day contain an attestation that the user has a credit score above a certain threshold? That's the sort of thing that's new compared to passwords.