Does the counter check is critical

[Moumouls]

I see in the code.

  if ((counter > 0 || authenticator.counter > 0) && counter <= authenticator.counter) {
    // Error out when the counter in the DB is greater than or equal to the counter in the
    // dataStruct. It's related to how the authenticator maintains the number of times its been
    // used for this client. If this happens, then someone's somehow increased the counter
    // on the device without going through this site
    throw new Error(
      `Response counter value ${counter} was lower than expected ${authenticator.counter}`,
    );

What is the security purpose of this check ?
What are the risks if the counter is kept at 0 on the database side and is not updated after each assertion?

[aseigler]

See https://www.w3.org/TR/webauthn/#sign-counter. Counter is there to check for cloned or otherwise malfunctioning authenticators.

[Moumouls]

Okay thanks @aseigler for the link so the best practice is to update the db counter on each successful assertion to avoid clone !
Also my bad since there is a suggestion into the docs: https://simplewebauthn.dev/docs/packages/server#2-verify-attestation-response

May be it could be interesting to add a note on the docs to explain why it's important to save the counter after each operation to avoid cloned authenticators 👍

[roboncode]

I second adding to docs. I went to the discussions in hopes to find an answer to help me better understand what purpose the counter served.

[MasterKale]

I'm preparing to add the following to the docs:

Regarding counter

Tracking the "signature counter" allows Relying Parties to potentially identify misbehaving authenticators, or cloned authenticators. The counter on subsequent authentications should only ever increment; if your stored counter is greater than zero, and a subsequent authentication response's counter is the same or lower, then perhaps the authenticator just used to authenticate is in a compromised state.

Unfortunately it's not uncommon for an authenticator to always return a constant 0 (zero) value for the signature counter. In this case there is nothing an RP can really do to detect a cloned authenticator, especially in the context of multi-device credentials.

@simplewebauthn/server already knows how to properly check the signature counter on subsequent authentications. RP's should only need to remember to store the value after registration, and then eventually feed it back into startAuthentication() when the user attempts to log in.

And I'm currently intending to put this as a new Step 3 under "2. Verify registration response" here: https://simplewebauthn.dev/docs/packages/server#2-verify-registration-response

How does this sound?

[MasterKale]

Yeah, Chrome on Mac returning zero for Touch ID all the time is pretty common now. Chrome used to return an atomic timestamp so you'd get massive counters like 1653347858727143000, but at some point that switched over.

[MasterKale]

Actually I guess I should say it's common for Apple authenticators to return zero now; the browser has nothing to do with how the signature counter is generated.

[roboncode]

This is also good information, that I would want to have in the documentation in some form (regarding common expected behaviors - Mac Touch ID). Even though the SimpleWebAuthn "simplifies" many of the lower level complexities, I would think that developers implementing this will want to have a deeper understanding on what they may come to expect in order to avoid confusion and unnecessary bug reports.

[MasterKale]

Alright, I've just deployed a couple of new sections to the server docs, "post-registration/post-authentication responsibilities". The former has a tall blue info box with what I hope is a sufficiently succinct description of the utility of counter and how to handle it:

https://simplewebauthn.dev/docs/packages/server#3-post-registration-responsibilities

Let me know what you all think.

[roboncode]

Good addition. I think it will help others.