3 ms·
> similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not It's been a while since I've looked d
by woodruffw 2y ago
> similar while FIDO protocols and passkeys could have been designed in a way which can work fully stateless they are not
It's been a while since I've looked deeply at FIDO, but I think they would have had to make a handful of nontrivial security concessions to make WebAuthn stateless. One pretty important one that comes to mind is the token counter, which in principal enables RPs to detect a cloned credential.
- Rafert 2y agoThe counter can always be 0, which is what cloud synced passkeys are doing IIRC.
- woodruffw 2y agoHuh yeah, I hadn't considered how they got around that. I suppose in that case this key could do something similar?
- dathinab 2y agoThe problem starts earlier with the secret key which you can't place "into" a TKey. You can deterministically derive one between the TKey and a server using some thing like a (semi) static DH but that isn't how it is implemented in general.
- cuu508 2y agoI understand that the ability to place stuff "into" a TKey would be needed to support discoverable WebAuthn credentials ("passkeys"). But would it also be needed for non-discoverable credentials?
- Borealid 2y agoYes, to set a PIN protecting the non-discoverable credentials. The FIDO PIN can be changed while you have access to the authenticator and not to the credentials it previously created.
- arianvanp 2y agoUser verification is optional. If you only do user presence and non-discoverable, then WebAuthn is completely stateless and deterministic for a given (challenge,rpId,origin) triplet
- michaelt 2y agoIsn't a 'passkey' with no discoverable credentials and no user verification just a regular U2F token?