# Signature counters

DevFeed: [Signature counters](<https://devfeed.tech/articles/signature-counters-36610.md>)

Original publisher: [Read original article](<http://www.imperialviolet.org/2023/08/05/signature-counters.html>)

Author: Adam Langley

Published: 2023-08-05T00:00:00Z

Content type: article

Language: en

Sources: [ImperialViolet](<https://devfeed.tech/sources/imperialviolet.md>)

Topics: [WebAuthn](<https://devfeed.tech/topics/webauthn.md>), [Security](<https://devfeed.tech/topics/security.md>), [private key](<https://devfeed.tech/topics/private-key.md>)

Tags: [account](<https://devfeed.tech/tags/account.md>), [private-key](<https://devfeed.tech/tags/private-key.md>), [security](<https://devfeed.tech/tags/security.md>), [signal](<https://devfeed.tech/tags/signal.md>)

## AI overview

The article explains WebAuthn signature counters, including their optional nature, how non-zero counters should increase for future assertions from a credential, and how counter inconsistencies might indicate a cloned security key. It argues that sites using counters should lock the account, investigate, and replace the key rather than merely reject the assertion.

## Source excerpt

If you look at the structure of the signed messages in WebAuthn you'll notice that one of the fields is called the "signature counter". In the previous long post I said to ignore it, which is still correct, but here's why. Signature counters are optional for the authenticator to implement: it's valid for a security key not to have a signature counter, although the vast majority of them do. In that case, the counter value is always zero. But once a website has seen a non-zero value, then the security key has to ensure that the counter, for all future assertions from a given credential, is strictly increasing. The motivation of the signature counter is that it might allow websites to detect when a security key has been cloned. Cloning a security key is supposed to be very difficult. At the very least, you should need physical access to it, and hopefully you need to spend a substantial amount of time invasively interrogating it. But, if you assume all that happened, then one could clone a security key (probably destroying it in the process), get the private key of a credential out of it, and create a working replica which could be slipped back into the possession of the legitimate user, leaving them unaware that anything has happened. At this point, the attacker can create assertions at will because they know the credential's private key. If all that has happened, then the signature counter might uncover it. Unless the attacker can know exactly when the legitimate user has created an assertion, and thus incremented the counter, then eventually either they or the real user will create an assertion where the counter didn't increase. You might be able to tell, but I consider this a rather far-fetched scenario. Nevertheless, if a website wants to use the signature counters, then it must treat any non-incrementing counter as a signal to lock the account and trigger an investigation. At a minimum, the security key in question should be replaced. Simply rejecting the assertio