rfc2617-htt11.txt

串口配置工具 ·作车牌识别的人一定要看

4.3 Limited Use Nonce Values

   The Digest scheme uses a server-specified nonce to seed the
   generation of the request-digest value (as specified in section
   3.2.2.1 above).  As shown in the example nonce in section 3.2.1, the
   server is free to construct the nonce such that it may only be used
   from a particular client, for a particular resource, for a limited
   period of time or number of uses, or any other restrictions.  Doing
   so strengthens the protection provided against, for example, replay
   attacks (see 4.5).  However, it should be noted that the method
   chosen for generating and checking the nonce also has performance and
   resource implications.  For example, a server may choose to allow
   each nonce value to be used only once by maintaining a record of
   whether or not each recently issued nonce has been returned and
   sending a next-nonce directive in the Authentication-Info header
   field of every response. This protects against even an immediate
   replay attack, but has a high cost checking nonce values, and perhaps
   more important will cause authentication failures for any pipelined
   requests (presumably returning a stale nonce indication).  Similarly,
   incorporating a request-specific element such as the Etag value for a
   resource limits the use of the nonce to that version of the resource
   and also defeats pipelining. Thus it may be useful to do so for
   methods with side effects but have unacceptable performance for those
   that do not.



Franks, et al.              Standards Track                    [Page 21]

RFC 2617                  HTTP Authentication                  June 1999


4.4 Comparison of Digest 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
   may be limited by the server's choice of nonce.

4.5 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 request 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.

   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, the resource
   ETag, 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.

   For applications where no possibility of replay attack can be
   tolerated the server can use one-time nonce values which will not be
   honored for a second use. This requires the overhead of the server



Franks, et al.              Standards Track                    [Page 22]

RFC 2617                  HTTP Authentication                  June 1999


   remembering which nonce values have been used until the nonce time-
   stamp (and hence the digest built with it) has expired, but it
   effectively protects against replay attacks.

   An implementation must give special attention to the possibility of
   replay attacks with POST and PUT requests. Unless the server employs
   one-time or otherwise limited-use nonces and/or insists on the use of
   the integrity protection of qop=auth-int, an attacker could replay
   valid credentials from a successful request with counterfeit form
   data or other message body. Even with the use of integrity protection
   most metadata in header fields is not protected. Proper nonce
   generation and checking provides some protection against replay of
   previously used valid credentials, but see 4.8.

4.6 Weakness Created by Multiple Authentication Schemes

   An HTTP/1.1 server may return multiple challenges with a 401
   (Authenticate) response, and each challenge may use a different
   auth-scheme. A user agent MUST choose to use the strongest auth-
   scheme it understands and request credentials from the user based
   upon that challenge.

      Note that many browsers will only recognize Basic and will require
      that it be the first auth-scheme presented. Servers should only
      include Basic if it is minimally acceptable.

   When the server offers choices of authentication schemes using the
   WWW-Authenticate header, the strength of the resulting authentication
   is only as good as that of the of the weakest of the authentication
   schemes. See section 4.8 below for discussion of particular attack
   scenarios that exploit multiple authentication schemes.

4.7 Online dictionary attacks

   If the attacker can eavesdrop, then it can test any overheard
   nonce/response pairs against a list of common words. Such a list is
   usually much smaller than the total number of possible passwords. The
   cost of computing the response for each password on the list is paid
   once for each challenge.

   The server can mitigate this attack by not allowing users to select
   passwords that are in a dictionary.









Franks, et al.              Standards Track                    [Page 23]

RFC 2617                  HTTP Authentication                  June 1999


4.8 Man in the Middle

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

   A possible man-in-the-middle attack would be to add a weak
   authentication scheme to the set of choices, hoping that the client
   will use one that exposes the user's credentials (e.g. password). For
   this reason, the client should always use the strongest scheme that
   it understands from the choices offered.

   An even better MITM attack would be to remove all offered choices,
   replacing them with a challenge that requests only Basic
   authentication, then uses the cleartext credentials from the Basic
   authentication to authenticate to the origin server using the
   stronger scheme it requested. A particularly insidious way to mount
   such a MITM attack would be to offer a "free" proxy caching service
   to gullible users.

   User agents should consider measures such as presenting a visual
   indication at the time of the credentials request of what
   authentication scheme is to be used, or remembering the strongest
   authentication scheme ever requested by a server and produce a
   warning message before using a weaker one. It might also be a good
   idea for the user agent 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.

4.9 Chosen plaintext attacks

   With Digest authentication, a MITM or a malicious server can
   arbitrarily choose the nonce that the client will use to compute the
   response. This is called a "chosen plaintext" attack. The ability to
   choose the nonce is known to make cryptanalysis much easier [8].

   However, no way to analyze the MD5 one-way function used by Digest
   using chosen plaintext is currently known.

   The countermeasure against this attack is for clients to be
   configured to require the use of the optional "cnonce" directive;
   this allows the client to vary the input to the hash in a way not
   chosen by the attacker.



Franks, et al.              Standards Track                    [Page 24]

RFC 2617                  HTTP Authentication                  June 1999


4.10 Precomputed dictionary attacks

   With Digest authentication, if the attacker can execute a chosen
   plaintext attack, the attacker can precompute the response for many
   common words to a nonce of its choice, and store a dictionary of
   (response, password) pairs. Such precomputation can often be done in
   parallel on many machines. It can then use the chosen plaintext
   attack to acquire a response corresponding to that challenge, and
   just look up the password in the dictionary. Even if most passwords
   are not in the dictionary, some might be. Since the attacker gets to
   pick the challenge, the cost of computing the response for each
   password on the list can be amortized over finding many passwords. A
   dictionary with 100 million password/response pairs would take about
   3.2 gigabytes of disk storage.

   The countermeasure against this attack is to for clients to be
   configured to require the use of the optional "cnonce" directive.

4.11 Batch brute force attacks

   With Digest authentication, a MITM can execute a chosen plaintext
   attack, and can gather responses from many users to the same nonce.
   It can then find all the passwords within any subset of password
   space that would generate one of the nonce/response pairs in a single
   pass over that space. It also reduces the time to find the first
   password by a factor equal to the number of nonce/response pairs
   gathered. This search of the password space can often be done in
   parallel on many machines, and even a single machine can search large
   subsets of the password space very quickly -- reports exist of
   searching all passwords with six or fewer letters in a few hours.

   The countermeasure against this attack is to for clients to be
   configured to require the use of the optional "cnonce" directive.

4.12 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.  Again, the
   user can be helped in detecting this attack by a visual indication of
   the authentication mechanism in use with appropriate guidance in
   interpreting the implications of each scheme.



Franks, et al.              Standards Track                    [Page 25]

RFC 2617                  HTTP Authentication                  June 1999


4.13 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.

   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 o