[palata]

Say the user has two devices and hence two copies of the same passkey, let's call them A and B. They have a shared signCount.

Say an attacker manages to make a copy C of A. They have the signCount as part of it, right? So they can immediately connect to the server. The server will increment signCount and sync it with A and B, but C is already in and C knows that the signCount is probably lastSignCount+1.

The only way I could imagine signCount to be useful is if somehow the server synchronises it between A and B in a way that C - who got access for a while - cannot access. It would mean that C has access until A or B connects, and after that the next time C connects, it will be out of sync. This does not sound super useful, and it assumes that C cannot access the sync process even though it has unlimited access to the passkey (until A or B is used).

What am I missing? To me signCount doesn't bring anything here...

[uzyn]

If C uses it without the knowledge of the original owner (A or B). With proper signCount check, C would have to increment it at its end; A or B would not have known.

When A logs in with an unincremented signCount. A and the relying party are now aware of a potential cloned authenticator and disable the compromised passkey.

[palata]

I'm sorry but it seems far-fetched to me. For signCount to be useful with shared passkeys, the attacker who managed to copy the passkey and get full access until the true owner logs in again would have to not synchronise the signCount (which they can totally do because they have full access), and it would "only" let the true owner know that the passkey is compromised.

It seems strictly worse than just sending an email saying "your passkey was used from <IP-based geolocation>, wasn't it you?".