Lighttpd

The relevant RFCs recommend that the nonce is constructed as a cryptographic hash of a secret and a timestamp. Then a received nonce can be validated by recomputing the hash and comparing it to the received hash. Alternatively, it recommends keeping a database of issued nonces and rejecting any that were not issued. The latter is often infeasible due to the associated performance cost.

Reference, please?

https://www.rfc-editor.org/rfc/rfc7616.txt discusses various approaches and tradeoffs, including security level, mitigations for replay attacks, CPU overhead, database/storage, added latency (round-trips) for user requests, and more. In multiple places, RFC7616 suggests that servers should strongly prefer providing HTTP Digest Authentication via a secure channel, e.g. over TLS.

lighttpd provides a compliant implementation of RFC7616, though improvements can of course be made. lighttpd's current implementation does not require persistent data (e.g. across server restarts) and does not require any shared state or shared secrets between multiple lighttpd worker processes or between multiple servers in a server farm.

https://www.rfc-editor.org/rfc/rfc7616.txt

5.12.  Parameter Randomness

   The security of this protocol is critically dependent on the
   randomness of the randomly chosen parameters, such as client and
   server nonces.  These should be generated by a strong random or
   properly seeded pseudorandom source (see [RFC4086]).

lighttpd uses a pseudorandom source to generate nonces and limits the lifetime. The changing nonces make things more difficult for an attacker sniffing traffic to obtain the password from the hashed data, which is the raison d'être of Digest Authentication.

It is true that the current lighttpd implementation does not validate nonces and so an attacker could provide both nonce, cnonce, and nc. However, I did not find any reference in RFC7616 where validating digest auth nonces is required. Please provide a link. Until then, I consider this a feature request for enhancements, and not a bug.

I will consider adding some configuration options (feature enhancements) to allow for some additional hardening techniques to be applied, but some of these hardening techniques might not work well with some setups (e.g. server farms which load balance without request stickiness, or even multiple lighttpd worker processes), so they must be optional.

Please note: the strength of the nonce is an entirely separate challenge from protection against replay attacks. Please share in more detail why you feel that validating the nonce significantly hardens the implementation and why time should be spent here before implementing additional options to mitigate replay attacks.

To wit, a man-in-the-middle will intercept client traffic, can downgrade client to use MD5, and use pre-generated rainbow tables to determine password, absent any interaction with the server. For a brute-force password attack against a server, an attacker can request a nonce from the server and reuse it, as lighttpd does not validate number of nonce uses. I could go on, but hope that this demonstrates that an attacker's ability to provide the nonce is not a terrible thing when there is an absense of attack monitoring (validating nonce reuse, nonce count (nc), ...)

All that said, it is important to remember the benefit of having any RFC7616-compliant implementation of Digest Authentication:

https://www.rfc-editor.org/rfc/rfc7616.txt

5.13.  Summary

   By modern cryptographic standards, Digest Authentication is weak.
   But, for a large range of purposes, it is valuable as a replacement
   for Basic Authentication.  It remedies some, but not all, weaknesses
   of Basic Authentication.  Its strength may vary depending on the
   implementation.  In particular, the structure of the nonce (which is
   dependent on the server implementation) may affect the ease of
   mounting a replay attack.  A range of server options is appropriate
   since, for example, some implementations may be willing to accept the
   server overhead of one-time nonces or digests to eliminate the
   possibility of replay.  Others may be satisfied with a nonce like the
   one recommended above, i.e., restricted to a single IP address and a
   single ETag or with a limited lifetime.

   The bottom line is that *any* compliant implementation will be
   relatively weak by cryptographic standards, but *any* compliant
   implementation will be far superior to Basic Authentication.

sketched a patch in my dev branch to validate nonce if "nonce_secret" is set to a secret string in the auth.require list

Applied in changeset e1188e770eb1939387cbbc214c9d16599cddc36b.