5 ms·
By design, ideally not. WebAuthn optionally includes (as a 'SHOULD') a signature counter concept that allows relying parties to be confident that the attestatio
by NovemberWhiskey 5y ago
By design, ideally not. WebAuthn optionally includes (as a 'SHOULD') a signature counter concept that allows relying parties to be confident that the attestation isn't coming from a previously-cloned version of the authenticator.
- zozbot234 5y agoThe specification states that cloning should merely be included in the service's underlying threat model. E.g. you might well be able to log in from an authenticator that fails the "signature counting" step if it's expected that the authenticator would allow for backing up and restoring its stored credentials.
- NovemberWhiskey 5y agoI think the point is it's up to the relying party to make the decision; so an uneven user experience is possible.
- zozbot234 5y agoIf an "insecure" authenticator reveals itself at enrollment, the only "unevenness" is that attempts to enroll it might fail, perhaps with a request to use a securely attested authenticator instead - you would never be locked out from any service after the fact. This is better than "cloning" a supposedly secure device and then failing a count check while trying to authenticate.
- NovemberWhiskey 5y agoYeah; being told "you can't use that here" for some sites is a pretty uneven user experience, wouldn't you say? Not sure why the scare quotes are necessary here.