Security - Digest Access Authentication

1 - About

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

Digest access authentication is a method use to negotiate credentials (such as username or password) with a user's web browser.

It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of encryption, making it non-secure unless used in conjunction with TLS.

Technically, digest authentication is an application of MD5 cryptographic hashing with usage of nonce values to prevent replay attacks. It uses the HTTP protocol.

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.

3 - Concept

  • client (your app) will call required API
  • server will reject it, but in response it will send a string containing random hash (=challenge).
  • client uses that string in combination with some other string (=password) (already embedded in app) to generate a new hash (=digest)
  • client will call same API again but this time using newly created digest as authentication parameters.
  • server will validate that digest and will proceed

Example with explanation

4 - Advantage / Disadavantage


  • The password is not sent clear to the server, thus preventing Phishing attacks if the user is tricked into accessing the wrong web site.
  • The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations to store HA1 rather than the cleartext password
  • Client nonce (introduced in RFC 2617) (allows the client to prevent chosen-plaintext attacks, such as rainbow tables)
  • 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


  • 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
  • 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)
  • Since the MD5 algorithm is not allowed in FIPS, HTTP Digest authentication will not work with FIPS-certified crypto modules.

5 - Documentation / Reference

security/auth/digest.txt ยท Last modified: 2018/04/18 15:17 by