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.
