4 ms·

Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your fav

Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your favorite smart phone to authenticate everywhere or even choose to rely on local TPM storage on your laptop or PC through MS Windows. This trades convenience with the risk of a vendor lock-in. But AFAIU the FIDO2 protocol you are free to use a dedicated USB key storage instead to store your private key (protected by a PIN or passphrase) on your own. This a bit less convenient but gives you peace of mind if you hate MS/ABC/Apple.

tux3 2y ago
>you are free to use a dedicated USB key storage instead to store your private key As long as the server supports the device/protocol/options you want, and doesn't enforce attestation against a small list of enterprise vendors. For instance Microsoft Azure AD's Entra ID authentication service, the one that keeps changing name, has a hardcoded list which you can consult here: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless#fido2-security-key-providers https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list. For the Apple/Google ecosystems specifically, it's also important to keep the compatibility matrix for each service in mind. For instance with Azure again: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-fido2-compatibility https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.

tux3 2y ago

>you are free to use a dedicated USB key storage instead to store your private key As long as the server supports the device/protocol/options you want, and doesn't enforce attestation against a small list of enterprise vendors. For instance Microsoft Azure AD's Entra ID authentication service, the one that keeps changing name, has a hardcoded list which you can consult here: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless#fido2-security-key-providers https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list. For the Apple/Google ecosystems specifically, it's also important to keep the compatibility matrix for each service in mind. For instance with Azure again: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-fido2-compatibility https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.