4. Security Considerations
4.1 Authentication of Clients using Basic Authentication
The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in cleartext across the physical network. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication.
The most serious flaw of Basic authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
Because Basic authentication involves the cleartext transmission of passwords, it SHOULD NOT be used (without enhancements) to protect sensitive or valuable information.
A common use of Basic authentication is for identification purposes -- requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and, in particular, does not allow the user to choose his or her own password. The danger is that naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.
If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the server but also unauthorized access to any other resources on other systems that the user protects with the same password. Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all those other sites if this information is not maintained in a secure fashion.
Basic authentication is also 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 Basic authentication when, in fact, she is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest authentication. Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular, the behavior of a server that accepts a connection should be under the complete control of the server, and not a gateway or CGI script. This gateway could then use the persistent connection mechanism to perform multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.
4.2 Authentication of Clients using Digest Authentication
Digest authentication does not provide a strong authentication mechanism, when compared to public key based mechanisms.
However, it is significantly stronger than (e.g.) CRAM-MD5, which has been proposed for use with LDAP [10], POP and IMAP (see RFC 2195 [9]). It is intended to replace the much weaker and even more dangerous Basic mechanism.
Digest Authentication offers no confidentiality protection beyond protecting the actual password. All of the rest of the request and response are available to an eavesdropper.
Digest Authentication offers only limited integrity protection for the message in either direction. If the qop=auth-int mechanism is used, then the message parts that are used to compute the WWW-Authenticate and Authorization header field response directive values (see section 3.2 above) are protected. Most header fields and their values can be modified as part of a man-in-the-middle attack.
Digest authentication cannot meet the needs of many secure HTTP transactions. For those needs, TLS or SHTTP are more appropriate protocols. In particular, Digest authentication cannot be used for any transaction for which confidentiality protection is needed. Nevertheless, Digest authentication is both useful and appropriate for many functions. Any service that is currently using Basic authentication should switch to Digest authentication as soon as practical.
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 instance, 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 an even higher cost in the failure of any pipelined requests to be authenticated (presumably resulting in 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 particular 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 impacts on those that do not.
4.4 Comparison of Digest with Basic Authentication
Both Digest and Basic authentication are weak in the sense that they may not prevent unauthorized access by a determined adversary. However, the comparison between the two points out the utility, and perhaps even the necessity, of replacing Basic with Digest.
For the type of transactions this protocol is likely to be used for, the greatest threat is network eavesdropping. This type of transaction might involve, for instance, online access to a database whose use is restricted to paying subscribers. With Basic authentication, an eavesdropper can obtain the user's password. This not only permits him access to anything in the database, but, what is often worse, will permit access to anything else the user protects with the same password.
By contrast, with Digest authentication, the eavesdropper gains access to only the transaction in question, and not the user's password. The information gained by the eavesdropper would permit a replay attack, but only with the same document request, and even that may be limited by the server's choice of nonce.
4.5 Replay Attacks
Replay attacks with Digest authentication are typically meaningless for simple GET requests, since the eavesdropper has already seen the only document he could obtain by replaying. This is because the URI of the document requested 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.
Therefore, for some purposes, it is necessary to protect against replay attacks. Good digest implementations can do so 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 originated from a bogus IP address and must cause the server to deliver the document to an IP address different from the one it thinks it is sending the document to. The attack can only succeed in the period of time before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation that does not maintain state between transactions.
For applications that cannot tolerate even the possibility of replay attacks, the server can use one-time nonce values which are not accepted a second time. This requires the overhead of the server remembering which nonce values have been used until the nonce time-stamp expires.
4.6 Weakness Created by Multiple Authentication Schemes
When a server offers multiple authentication schemes in the WWW-Authenticate header, the client should select the strongest scheme it supports. However, if an attacker can modify the response to remove the stronger scheme, the client may be forced to use a weaker scheme.
4.7 Online dictionary attacks
If the server does not limit the rate of authentication attempts, an attacker can attempt a large number of passwords to guess the correct one. Servers SHOULD limit the rate of failed authentication attempts from a single IP address.
4.8 Man in the Middle
Digest authentication is vulnerable to man-in-the-middle attacks. An attacker can intercept communications between the client and server and modify or replace messages. Using TLS or other transport layer security mechanisms can prevent such attacks.
4.9 Chosen plaintext attacks
Digest authentication is vulnerable to chosen plaintext attacks. An attacker can choose specific URIs and observe the resulting digests, potentially gaining information about the password.
4.10 Precomputed dictionary attacks
If an attacker can access the server's password file, he can precompute digests of common passwords and then compare these digests against those in the file. Using salt values can make this attack more difficult.
4.11 Batch brute force attacks
If an attacker can capture multiple authentication exchanges, he can attempt to brute force the password offline. Using strong passwords and limiting the validity period of nonces can mitigate this risk.
4.12 Spoofing by Counterfeit Servers
Clients SHOULD verify the server's identity to prevent connecting to counterfeit servers. Using TLS with server certificate validation can prevent such attacks.
4.13 Storing passwords
Servers SHOULD NOT store passwords in cleartext. Instead, the hash of the password should be stored. For Digest authentication, the server can store H(username:realm:password), which allows verification of the client without storing cleartext passwords.
4.14 Summary
Digest authentication provides better security than Basic authentication, but it is not a complete security solution. For applications requiring strong security, TLS or other stronger security mechanisms should be used. Nevertheless, Digest authentication is a practical and useful improvement for many applications.