In digest authentication we use something that is called cnonce.
According to RFC7616:

This parameter MUST be used by all implementations. The cnonce value is an opaque quoted ASCII-only string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide mutual authentication, and to provide some message integrity protection. See the descriptions below of the calculation of the rspauth and response values.

What is the meaning of "opaque quoted ASCII-only string value"?
How does the server use this value?
What is it's purpose and how does it help avoiding chosen plaintext attacks?

  • 1
    What is the meaning of "opaque quoted ASCII-only string value"? - what part of this don't you understand? The meaning of "opaque" is defined in section 3.3 of the RFC you cite. "quoted ASCII-only string" should be obvious. Sep 1, 2022 at 14:06

1 Answer 1


The "cnonce" is the client nonce. It is an unpredictable value generated by the client rather than the server, and is unique (different for every authentication). You can think of it kind of like salting the password; it prevents generating a rainbow table (precomputed hash value lookup table) that would otherwise allow an attacker to break the hash of many passwords any time the attacker can manipulate the server-supplied values (nonce and realm) and can hold the URL (and request body, for some modes) fixed. Instead, since the server (or a man-in-the-middle attacker) can't control or predict the cnonce (because it's randomly chosen by the client), each digest auth hash has a bunch of extra entropy in it, making computing a rainbow table totally infeasible.

The server can also keep track of either specific cnonces it has seen before, or the other client-chosen value of "nonceCount" which is intended to strictly increment. In this way, the server can defeat replay attacks (where an attacker captures the victim's authorization header value but, not knowing the password, can't actually generate a new, valid value so they just send the captured one again to try and get the server to accept it again). Replay attacks can also be defeated by the server generating a new nonce in response to each request and not allowing old (server-chosen) nonces, but having the client generate a new one and the server track it (or just track the last seen nonceCount, which is much simpler) reduces round-trips needed for re-negotiating the nonces and thus improves user experience and server load.

Mind you, modern GPUs could still crack any remotely common password. A few (single-digit) iterations of MD5, or even SHA2-512, isn't going to impede any highly-parallel processor (such as a GPU) from trying hundreds of millions, or even billions, of candidate passwords per second. Furthermore, digest auth doesn't provide any means of protecting the confidentiality of the URL, request body, or other headers, nor any way to protect either the confidentiality nor the integrity of the response. Finally, a man-in-the-middle attacker can of course just turn off digest auth (e.g. request basic auth instead, which sends the credentials in de-facto plain text) or at least downgrade the digest auth (use the older version without cnonces and integrity for the request), unless the client is specifically expecting a specific mode (which browsers generally won't do).

TLS (Transport Layer Security, the successor to SSL or Secure Socket Layer) avoids all of these problems, and some others besides. Given the existence of TLS - which is how modern HTTPS is secured - there's just no reason for digest auth any more.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .