rfc2069.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

3.1 Comparison with Basic Authentication

   Both Digest and Basic Authentication are very much on the weak end of
   the security strength spectrum. But a comparison between the two
   points out the utility, even necessity, of replacing Basic by Digest.

   The greatest threat to the type of transactions for which these
   protocols are used is network snooping.  This kind of transaction
   might involve, for example, online access to a database whose use is
   restricted to paying subscribers.  With Basic authentication an
   eavesdropper can obtain the password of the user.  This not only
   permits him to access anything in the database, but, often worse,
   will permit access to anything else the user protects with the same
   password.

   By contrast, with Digest Authentication the eavesdropper only gets
   access to the transaction in question and not to the user's password.
   The information gained by the eavesdropper would permit a replay
   attack, but only with a request for the same document, and even that
   might be difficult.

3.2 Replay Attacks

   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.





Franks, et. al.             Standards Track                    [Page 13]

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 <digest> 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



Franks, et. al.             Standards Track                    [Page 14]

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.

3.4 Spoofing by Counterfeit Servers

   Basic Authentication is vulnerable to spoofing by counterfeit
   servers. If a user can be led to believe that she is connecting to a
   host containing information protected by a password she knows, when
   in fact she is connecting to a hostile server, then the hostile
   server can request a password, store it away for later use, and feign
   an error.  This type of attack is more difficult with Digest
   Authentication -- but the client must know to demand that Digest
   authentication be used, perhaps using some of the techniques
   described above to counter "man-in-the-middle" attacks.

3.5 Storing passwords

   Digest authentication requires that the authenticating agent (usually
   the server) store some data derived from the user's name and password
   in a "password file" associated with a given realm.  Normally this
   might contain pairs consisting of username and H(A1), where H(A1) is
   the digested value of the username, realm, and password as described
   above.

   The security implications of this are that if this password file is
   compromised, then an attacker gains immediate access to documents on
   the server using this realm.  Unlike, say a standard UNIX password
   file, this information need not be decrypted in order to access
   documents in the server realm associated with this file.  On the
   other hand, decryption, or more likely a brute force attack, would be
   necessary to obtain the user's password.  This is the reason that the
   realm is part of the digested data stored in the password file.  It
   means that if one digest authentication password file is compromised,
   it does not automatically compromise others with the same username
   and password (though it does expose them to brute force attack).

   There are two important security consequences of this.  First the
   password file must be protected as if it contained unencrypted
   passwords, because for the purpose of accessing documents in its
   realm, it effectively does.



Franks, et. al.             Standards Track                    [Page 15]

RFC 2069              Digest Access Authentication          January 1997


   A second consequence of this is that the realm string should be
   unique among all realms which any single user is likely to use.  In
   particular a realm string should include the name of the host doing
   the authentication.  The inability of the client to authenticate the
   server is a weakness of Digest Authentication.

3.6 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 many, 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 while others may satisfied with a nonce like
   the one recommended above restricted to a single IP address and 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.

4.  Acknowledgments

   In addition to the authors, valuable discussion instrumental in
   creating this document has come from Peter J. Churchyard, Ned Freed,
   and David M. Kristol.

5. References

   [1]  Berners-Lee, T.,  Fielding, R., and H. Frystyk,
        "Hypertext Transfer Protocol -- HTTP/1.0",
        RFC 1945, May 1996.

   [2]  Berners-Lee, T., Fielding, R., and H. Frystyk,
        "Hypertext Transfer Protocol -- HTTP/1.1"
        RFC 2068, January 1997.

   [3]  Rivest, R., "The MD5 Message-Digest Algorithm",
        RFC 1321, April 1992.








Franks, et. al.             Standards Track                    [Page 16]

RFC 2069              Digest Access Authentication          January 1997


6. Authors' Addresses

   John Franks
   Professor of Mathematics
   Department of Mathematics
   Northwestern University
   Evanston, IL 60208-2730, USA

   EMail: [e-mail]


   Phillip M. Hallam-Baker
   European Union Fellow
   CERN
   Geneva
   Switzerland

   EMail: [e-mail]


   Jeffery L. Hostetler
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   EMail: [e-mail]


   Paul J. Leach
   Microsoft Corporation
   1 Microsoft Way
   Redmond, WA 98052, USA

   EMail: [e-mail]


   Ari Luotonen
   Member of Technical Staff
   Netscape Communications Corporation
   501 East Middlefield Road
   Mountain View, CA 94043, USA

   EMail: [e-mail]







Franks, et. al.             Standards Track                    [Page 17]

RFC 2069              Digest Access Authentication          January 1997


   Eric W. Sink
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   EMail: [e-mail]


   Lawrence C. Stewart
   Open Market, Inc.
   215 First Street
   Cambridge, MA  02142, USA

   EMail: [e-mail]




































Franks, et. al.             Standards Track                    [Page 18]