digest鉴权_什么叫鉴权

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials with a user’s web browser. It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext.

Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to discourage cryptanalysis. It uses the HTTPprotocol.

Overview

Digest access authentication was originally specified by RFC 2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1, HA2, A1, A2 are names of string variables):

RFC 2069 was later replaced by RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 introduced a number of optional security enhancements to digest authentication; “quality of protection” (qop), nonce counter incremented by client, and a client-generated random nonce. These enhancements are designed to protect against, for example,chosen-plaintext attack cryptanalysis.

If the qop directive’s value is “auth” or is unspecified, then HA2 is

If the qop directive’s value is “auth-int”, then HA2 is

If the qop directive’s value is “auth” or “auth-int”, then compute the response as follows:

If the qop directive is unspecified, then compute the response as follows:

The above shows that when qop is not specified, the simpler RFC 2069 standard is followed.

[edit]Impact of MD5 security on digest authentication

The MD5 calculations used in HTTP digest authentication is intended to be “one way”, meaning that it should be difficult to determine the original input when only the output is known. If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) – perhaps aided by a dictionary or suitable look-up list.

The HTTP scheme was designed by Phillip Hallam-Baker at CERN in 1993 and does not incorporate subsequent improvements in authentication systems, such as the development of keyed-hash message authentication code (HMAC). Although the cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.^{[1][citation needed]} However, claims in 2006 (Kim, Biryukov2, Preneel, Hong, “On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1”) cause some doubt over other MD5 applications as well. So far, however, MD5 collision attacks have not been shown to pose a threat to digest authentication, and the RFC 2617 allows servers to implement mechanisms to detect some collision and replay attacks.

[edit]HTTP digest authentication considerations

[edit]Advantages

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes; e.g., “significantly stronger than (e.g.) CRAM-MD5 …” (RFC2617).

Some of the security strengths of HTTP digest authentication are:

• The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss DIGESTAuth) to store HA1 rather than thecleartext password.
• Client nonce was introduced in RFC 2617, which allows the client to prevent Chosen-plaintext attacks (which otherwise makes e.g. rainbow tables a threat to digest authentication schemes).
• Server nonce is allowed to contain timestamps. Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks.
• Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse.

[edit]Disadvantages

Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.

In terms of security, there are several drawbacks with digest access authentication:

• Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode.
• Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server’s identity.
• Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.^[2]
• It prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable).

[edit]Alternative authentication protocols

Some strong authentication protocols for web-based applications include:

• Public key authentication (usually implemented with HTTPS / SSL client certificates).
• Kerberos or SPNEGO authentication, primarily employed by Microsoft IIS running configured for Integrated Windows Authentication (IWA).
• Secure Remote Password protocol (preferably within the HTTPS / TLS layer).

Weak cleartext protocols are also often in use:

• Basic access authentication scheme
• HTTP+HTML form-based authentication

These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that digest access authentication is designed to prevent.

[edit]Example with explanation

The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each request and response. Note that only the “auth” (authentication) quality of protection code is covered – at the time of writing, only the Opera and Konqueror web browsers are known to support “auth-int” (authentication with integrity protection). Although the specification mentions HTTP version 1.1, the scheme can be successfully added to a version 1.0 server, as shown here.

This typical transaction consists of the following steps.

• The client asks for a page that requires authentication but does not provide a username and password. Typically this is because the user simply entered the address or followed a link to the page.
• The server responds with the 401 “Unauthorized” response code, providing the authentication realm and a randomly-generated, single-use value called a nonce.
• At this point, the browser will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a username and password. The user may decide to cancel at this point.
• Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code.
• In this example, the server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might retu