3 ms·

The whole messaging on passkeys are extraordinarily confusing. When I start reading, it sounds like a great thing: instead of passwords, I authorize devices to

The whole messaging on passkeys are extraordinarily confusing. When I start reading, it sounds like a great thing: instead of passwords, I authorize devices to my account by associating a public key with the account. But it's unclear if supporting passkeys actually requires services to support more than one public key associated with an account. The fact that you can sync passkeys to the cloud (rather than just using a key stored in a TPM) suggests that it's not actually a requirement, and it isn't even the default behavior. It seems like passkeys are intended as a fancier version of "log in with" rather than an actual private key/hardware-based replacement for passwords. A properly secure system would have a mode that made sync impossible, you would have to generate a unique and hardware-secure passkey for each device. It sounds like maybe I can achieve that, but not with any of the standard implementations.

WorldMaker 3y ago
Passkeys are a brand name for an "all of the above" buffet of menu options and sorting out specific "branding efforts" versus the practical, achievable, standardized options is going to be a real ongoing challenge. On the one hand, because it allows for and often uses so many different practical options that should mean that no one path is better tested than any other. On the other hand, yeah it adds for a lot of complications when trying to figure out what people (will) mean by "passkeys" support. > But it's unclear if supporting passkeys actually requires services to support more than one public key associated with an account. Present best practice for WebAuthn is to always support an arbitrary number of public keys associated with an account. That shouldn't change with Passkeys and some present passkeys implementations are allowed to present an arbitrary number of public keys at enrollment time. > A properly secure system would have a mode that made sync impossible, you would have to generate a unique and hardware-secure passkey for each device. You should be able to do that in theory. It's obviously going to be harder to operate and maintain than a system involving synced keys and yes it may be too soon to have a good idea of what sort of practical obstacles might exist.

WorldMaker 3y ago

Passkeys are a brand name for an "all of the above" buffet of menu options and sorting out specific "branding efforts" versus the practical, achievable, standardized options is going to be a real ongoing challenge. On the one hand, because it allows for and often uses so many different practical options that should mean that no one path is better tested than any other. On the other hand, yeah it adds for a lot of complications when trying to figure out what people (will) mean by "passkeys" support. > But it's unclear if supporting passkeys actually requires services to support more than one public key associated with an account. Present best practice for WebAuthn is to always support an arbitrary number of public keys associated with an account. That shouldn't change with Passkeys and some present passkeys implementations are allowed to present an arbitrary number of public keys at enrollment time. > A properly secure system would have a mode that made sync impossible, you would have to generate a unique and hardware-secure passkey for each device. You should be able to do that in theory. It's obviously going to be harder to operate and maintain than a system involving synced keys and yes it may be too soon to have a good idea of what sort of practical obstacles might exist.