In HTTP Digest Authentication, what roles do the server nonce, the client-generated cnonce and the nc counter play in replay protection, and what does a 401 challenge carrying `stale=true` mean?

## What replay means here On a cleartext connection an attacker can copy an entire `Authorization: Digest` header. Since the digest is a fixed string, resending it would authenticate the attacker unless something makes each credential single-use. Three values do that work, and none is sufficient alone. ## Server nonce The nonce is opaque to the client but structured on the server. A common construction is `base64(timestamp : MAC(server-secret, timestamp [, client-ip]))`. That lets the server decide two things from the nonce alone: was it issued by me, and how old is it — with no shared session table, which matters behind a load balancer where the next request may hit a different node. Nonce lifetime is a direct tradeoff: short lifetimes shrink the replay window but force extra 401 round trips; long lifetimes push all the protection onto nc tracking. ## The nc counter `nc` (nonce count) is an 8-hex-digit counter starting at `00000001`, incremented by the client for every request that reuses the same nonce, and folded into the digest — so it cannot be edited without invalidating the hash. The server keeps, per nonce, the highest nc it has accepted, and rejects any request whose nc is less than or equal to it. **This is the only mechanism that actually detects a replay within a nonce's lifetime.** A server that ignores nc — and many do — leaves every captured credential replayable until the nonce expires. Tracking nc reintroduces exactly the per-nonce server state that a stateless nonce was meant to avoid, which is one reason implementations skip it. ## The cnonce The client nonce protects the *client*, not the server. Without it, the server controls every input to the hash (nonce, and it knows realm and URI), so a malicious or compromised server can issue a chosen nonce and use the reply to attack the password offline — including with precomputed tables. Mixing in fresh client-side randomness makes each digest unpredictable to the server and defeats precomputation. The `-sess` algorithm variants go further by folding nonce and cnonce into A1 itself, so the derived session key changes per authentication. ## stale=true When a request arrives with a well-formed digest that verifies against an *expired* nonce, the server should not report a credential failure. It returns `401` with `WWW-Authenticate: Digest ..., nonce="<new>", stale=true`. The semantics defined by RFC 7616 are: the credential was correct, only the nonce is out of date. A browser therefore recomputes with the new nonce and retries without showing the password prompt again; without `stale=true` it would treat the 401 as a rejected password and re-prompt, which is both bad UX and a nudge toward users retyping passwords into anything that asks. When `stale` is absent or false, the client must obtain a new username and password. ## Where the protection ends All of this defends the credential, not the exchange. The request body, the response and every other header travel in the clear. An active attacker who can modify traffic can still tamper with a request body under `qop=auth`, and can strip the Digest challenge and offer a Basic one instead — a downgrade the protocol has no defence against. Digest's replay machinery only ever raised the cost of *credential* theft; confidentiality and integrity require TLS.