Hacker News Reader

Comment by woodruffw | Hacker News Reader

> 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.

View on HN

The counter can always be 0, which is what cloud synced passkeys are doing IIRC.

Huh yeah, I hadn't considered how they got around that. I suppose in that case this key could do something similar?

The 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.

I 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?

Yes, 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.

User 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

Isn't a 'passkey' with no discoverable credentials and no user verification just a regular U2F token?

Well, it could still provide credBlob (up to 32 bytes of data stored in the non-discoverable credential and handed back after verification). But mostly yes, it's losing the advantages of FIDO2.

Modulo supporting more algorithms -- yes

Reply on news.ycombinator.com