Re: [webauthn] Sign counter alg 507

> Perhaps so, for RPs who attempt to employ this signal in a simplistic fashion. RPs employing risk analysis will be able to factor in further information, such as, e.g., an allegedly-cloned user private key continuing to be used from the same user device in the same location

The signal, in this case, doesn't indicate a risk about the current login, so much as it indicates that a previous login (perhaps many weeks ago) might now be suspect in hindsight. I think the best response to this would be for a service to highlight, to the user, the set of current login sessions and suggest that they change their password and revoke all other sessions.

That might be valuable, but the value of this specific signal is the additional benefit of this signal over the other signals that also trigger this behaviour. In light of that, consider both the sources of noise (i.e. Flash write failures) and that this signal has a good chance of getting lost completely:

A token having a single counter for all sites is both the obvious design (to avoid unbounded storage requirements) and what I've observed in practice. But such a token will increment the counter in response to logins to unrelated sites. So if an attacker clones a token and uses counter value n+1 to login to a site, the original token might advance to n+20 before ever logging into that site again, and the signal is lost. If the attacker can observe the counter (say, by having the victim use a service controlled by them) then that'll probably work forever. If not, re-login intervals on sites are long these days anyway.

So I consider this signal to be unreliable, noisy and probably fairly redundant in a complex risk-analysis system. On the other side of the balance: given a record of time-stamped counter values from two services, users can probably be strongly correlated by their progression. Overall, I think the costs dominate the benefits and that counters should be eliminated.

At least tokens can opt-out by always using the zero value. However, I suspect that token vendors will dramatically overestimate the value of signature counters unless the spec removes them, and thus they'll keep being implemented.

-- 
GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/539#issuecomment-326831893 using your GitHub account

Received on Sunday, 3 September 2017 21:18:18 UTC