A replay attack against digest authentication would usually be
   pointless for a simple GET request since an eavesdropper would
   already have seen the only document he could obtain with a replay.
   This is because the URI of the requested document is digested in the
   client response and the server will only deliver that document. By
   contrast under Basic Authentication once the eavesdropper has the
   user's password, any document protected by that password is open to
   him.  A GET request containing form data could only be "replayed"
   with the identical data.  However, this could be problematic if it
   caused a CGI script to take some action on the server.

   Thus, for some purposes, it is necessary to protect against replay
   attacks.  A good digest implementation can do this in various ways.
   The server created "nonce" value is implementation dependent, but if
   it contains a digest of the client IP, a time-stamp, and a private
   server key (as recommended above) then a replay attack is not simple.
   An attacker must convince the server that the request is coming from
   a false IP address and must cause the server to deliver the document
   to an IP address different from the address to which it believes it
   is sending the document.  An attack can only succeed in the period
   before the time-stamp expires.  Digesting the client IP and time-
   stamp in the nonce permits an implementation which does not maintain
   state between transactions.






 
RFC 2069              Digest Access Authentication          January 1997


   For applications where no possibility of replay attack can be
   tolerated the server can use one-time response digests which will not
   be honored for a second use.  This requires the overhead of the
   server remembering which digests have been used until the nonce
   time-stamp (and hence the digest built with it) has expired, but it
   effectively protects against replay attacks. Instead of maintaining a
   list of the values of used digests, a server would hash these values
   and require re-authentication whenever a hash collision occurs.

   An implementation must give special attention to the possibility of
   replay attacks with POST and PUT requests.  A successful replay
   attack could result in counterfeit form data or a counterfeit version
   of a PUT file.  The use of one-time digests or one-time nonces is
   recommended.  It is also recommended that the optional  be
   implemented for use with POST or PUT requests to assure the integrity
   of the posted data.  Alternatively, a server may choose to allow
   digest authentication only with GET requests. Responsible server
   implementors will document the risks described here as they pertain
   to a given implementation.

3.3 Man in the Middle

   Both Basic and Digest authentication are vulnerable to "man in the
   middle" attacks, for example, from a hostile or compromised proxy.
   Clearly, this would present all the problems of eavesdropping.  But
   it could also offer some additional threats.

   A simple but effective attack would be to replace the Digest
   challenge with a Basic challenge, to spoof the client into revealing
   their password. To protect against this attack, clients should
   remember if a site has used Digest authentication in the past, and
   warn the user if the site stops using it. It might also be a good
   idea for the browser to be configured to demand Digest authentication
   in general, or from specific sites.

   Or, a hostile proxy might spoof the client into making a request the
   attacker wanted rather than one the client wanted.  Of course, this
   is still much harder than a comparable attack against Basic
   Authentication.

   There are several attacks on the "digest" field in the
   Authentication-info header.  A simple but effective attack is just to
   remove the field, so that the client will not be able to use it to
   detect modifications to the response entity. Sensitive applications
   may wish to allow configuration to require that the digest field be
   present when appropriate. More subtly, the attacker can alter any of
   the entity-headers not incorporated in the computation of the digest,
   The attacker can alter most of the request headers in the client's




 
RFC 2069              Digest Access Authentication          January 1997


   request, and can alter any response header in the origin-server's
   reply, except those headers whose values are incorporated into the
   "digest" field.

   Alteration of Accept* or User-Agent request headers can only result
   in a denial of service attack that returns content in an unacceptable
   media type or language. Alteration of cache control headers also can
   only result in denial of service. Alteration of Host will be
   detected, if the full URL is in the response-digest. Alteration of
   Referer or From is not important, as these are only hints.