Re: [webauthn] Sign counter alg 507

I would rather fix the value of the counter at zero for devices that have
hardware protected keys.  I think randomizing it adds more confusion.

The validator is sending a challenge that is signed so a Authenticator
nonce is not adding much if anything other than additional replay
protection.   I suspect that validators using both challange and nonce
replay protection without a clock to bound the cache is not going to help
people.

As I recall the idea for the counter was to detect leaked credentials for
soft authenticators.    If the key leaks then one of the authenticators
(probably the real one) would have a counter that is lower than the one
last seen and the keyhandle could be invalidated.

As a bad guy I would be able to get in at least once by stepping forward
the counter by 10 or something to be sure I am greater than the legitimate
one.

With a global counter used at multiple sites the original one may still
work for some time depending on it's use at other sites.

I agree that the counter is a weak protection that may not be implemented
well on the server side.   Also that a global counter is a privacy problem.


Soft tokens generally are not state constrained.  There might be a value in
those using per credential counters.

I don't think per credential counters are a privacy issue, but I do agree
that proper server validation can be a challenge in the case that the
counter has not incrimented due to a failed write.

John B.

On Aug 30, 2017 11:08, "Adam Langley via GitHub" <sysbot+gh@w3.org> wrote:

> If we are concerned about an authenticator nonce, we could simply add it -
>> independent from the the signature counter.
>>
>
> I don't, personally, know the tradeoffs for an authenticator nonce but the
> last time I had an interaction with a representative from NXP they were
> very clear that such a thing was useful.
>
> But existing FIDO devices don't have such a field and I want to eliminate
> the signature counter. I don't believe that the signature counter achieves
> anything and it allows cross-site tracking of tokens.
>
> I understand that the theory of signature counters is that an attacker who
> obtained a private key would be forced to break the legitimate key by
> advancing the counter. Thus the user would be "informed" of the attack
> because their key would stop working.
>
> But, in practice, that'll be surfaced as an opaque, unactionable error to
> the user, who will probably just be annoyed that the security key stopped
> working and re-enroll it. (Presumably with a different key. Maybe they'll
> figure out they can delete the old token?). If it keeps happening, they'll
> discard the token and just get another.
>
> From the server's point of view this attack signal is very likely to be
>> drowned out in the noise of tokens failing to do a flash write, corrupting
>> their flash etc, and thus be useless there too.
>>
>
> On the other hand, tokens are very likely to use a single counter for all
> sites because per-site counters require per-site storage in the token.
> Indeed, the token that I'm using at the moment has a single counter which
> is currently 1,838. The progression of that value is likely strongly
> identifying.
>
> --
> GitHub Notification of comment by agl
> Please view or discuss this issue at https://github.com/w3c/webauth
> n/pull/539#issuecomment-326072876 using your GitHub account
>
>