The nextnonce mechanism allows one-time nonces but impairs HTTP pipelining because each response must be processed before the next request can be authorized. The spec recommends considering the nc parameter as a way to retain most security benefits without blocking pipelining.

http, security

The "-sess" algorithm variants (e.g., SHA-256-sess) hash the user credentials once and then incorporate the server and client nonces into A1, creating a per-session key. This limits the amount of material hashed with any one key and enables third-party authentication servers that need only H(A1) rather than the cleartext password.

http, security, crypto

The URI is duplicated in the Authorization header field (even though it is already in the Request-Line) to protect against intermediate proxies that may alter the request target in transit; the digest over the client's original URI lets the server detect such alterations.

http, security

MD5 is retained for backward compatibility with RFC 2617 but is explicitly NOT RECOMMENDED. SHA-256 is mandatory to implement in all new implementations. Backward compatibility with RFC 2069 (which omitted qop) is deprecated.

http, crypto, security

A user agent MUST choose to use the strongest auth-scheme it understands when a server offers multiple authentication schemes, as the effective security is only as strong as the weakest scheme used.

http, security

For historical reasons, senders MUST use quoted-string syntax for realm, domain, nonce, opaque, qop (in WWW-Authenticate), and MUST NOT use quoted-string syntax for stale and algorithm. In Authorization, MUST use quoted-string for username, realm, nonce, uri, response, cnonce, opaque; MUST NOT for algorithm, qop, nc.

http

Proxies MUST be completely transparent in Digest authentication: they MUST forward the WWW-Authenticate, Authentication-Info, and Authorization header fields untouched. Proxy authentication uses the separate Proxy-Authenticate and Proxy-Authorization header fields.

http, security

Sending both username and username* in the same Authorization header field MUST be treated as an error. The username* parameter (RFC 5987 extended notation) is used only when userhash is false and the username contains characters not allowed in a quoted-string.

http

SHA-256 is mandatory to implement; SHA-512/256 serves as a backup algorithm; MD5 is retained only for backward compatibility. When receiving multiple challenges, the client SHOULD use the first one it supports unless local policy dictates otherwise.

http, crypto, security

The authenticating server MUST assure that the resource designated by the "uri" parameter matches the resource in the Request-Line; if they differ, the server SHOULD return a 400 Bad Request error.

http, security

The cnonce parameter MUST be used by all implementations. It is an opaque ASCII-only string chosen by the client to prevent chosen plaintext attacks, provide mutual authentication, and provide limited message integrity protection.

http, security

The nc (nonce count) parameter MUST be used by all implementations and MUST be exactly 8 hexadecimal digits (e.g., "00000001"). The server uses it to detect replay attacks by checking that the same nc value is not seen twice.

http, security

The qop parameter MUST be used by all implementations. The server lists supported quality-of-protection values ("auth", "auth-int") in WWW-Authenticate, and the client selects one for the Authorization field. Unrecognized options MUST be ignored.

http, security

When a server sends multiple challenges in a 401 response, each MUST use a different digest algorithm, and challenges MUST be ordered from most preferred to least preferred algorithm.

http, security

A1 is computed as unq(username) ":" unq(realm) ":" passwd for plain algorithms, or as H(unq(username) ":" unq(realm) ":" passwd) ":" unq(nonce-prime) ":" unq(cnonce-prime) for the "-sess" session variants, enabling third-party authentication servers.

http, crypto, security

A2 is Method ":" request-uri when qop is "auth" or unspecified, and Method ":" request-uri ":" H(entity-body) when qop is "auth-int". The entity-body hash is computed before transfer encoding.

http, crypto, security

The Authentication-Info header field (RFC 7615) MAY carry nextnonce, qop, rspauth, cnonce, and nc in successful responses. The rspauth parameter provides mutual authentication by proving the server knows the user's secret.

http, security

The Authorization header field carries the client's Digest response with parameters: username (or username*), realm, uri, qop, cnonce, nc, response, userhash, and opaque. The opaque and algorithm values MUST match those supplied in the WWW-Authenticate challenge.

http, security

The Digest response value is computed as KD(H(A1), unq(nonce) ":" nc ":" unq(cnonce) ":" unq(qop) ":" H(A2)) when qop is "auth" or "auth-int". KD(secret, data) = H(concat(secret, ":", data)).

http, crypto, security

The WWW-Authenticate header field carries the Digest challenge with parameters: realm, domain, nonce, opaque, stale, algorithm, qop, charset, and userhash. The server sends this in a 401 response when an acceptable Authorization is absent.

http, security

Username hashing computes username = H(unq(username) ":" unq(realm)) using the same algorithm as the credential hash. The client MUST include userhash=true in the Authorization field when sending a hashed username.

http, privacy, security

RFC 7616 creates the "Hash Algorithms for HTTP Digest Authentication" IANA registry under the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" category. Initial entries are MD5 (128-bit), SHA-256 (256-bit), and SHA-512-256 (256-bit); each may have a "-sess" variant. Update policy: Specification Required.

registry, http, crypto

RFC 7616 updates the existing "Digest" entry in the HTTP Authentication Scheme Registry (RFC 7235 framework) to add a reference to this specification.

registry, http

A MITM or malicious server can execute chosen plaintext attacks by choosing the server nonce. The countermeasure is the client cnonce parameter, which varies the hash input in a way not controlled by the attacker. cnonce also defends against precomputed dictionary attacks and batch brute-force attacks.

security, http, crypto

Digest Authentication is vulnerable to man-in-the-middle attacks: a hostile proxy can strip strong auth challenges and substitute a Basic-only challenge, then use the captured cleartext credentials to authenticate to the origin server using the stronger scheme.

security, http

HTTP Digest Authentication with human-memorable passwords is vulnerable to dictionary attacks. It SHOULD be used only with passwords of at least 128 bits of entropy, and SHOULD be used only over a secure channel such as HTTPS.

security, http

The security of the protocol is critically dependent on the randomness of the client and server nonces. These MUST be generated by a strong random or properly seeded pseudorandom source (see RFC 4086).

security, http, crypto

The server password file typically stores H(A1) = H(username ":" realm ":" password). A compromised file gives an attacker immediate access to the protected realm without decryption; the password file must therefore be protected as if it contained cleartext passwords.

security, http

Digest values are encoded as lowercase hexadecimal strings: MD5 produces 32 hex characters (128 bits), SHA-256 produces 64 hex characters (256 bits), and SHA-512/256 produces 64 hex characters (256 bits). Bits are converted most-significant to least-significant, four bits at a time.

http, crypto