View source for Digest access authentication

{{Short description|Method of negotiating credentials between web server and browser}}
{{HTTP}}
'''Digest access authentication''' is one of the agreed-upon methods a [[web server]] can use to negotiate credentials, such as username or password, with a user's [[web browser]]. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. 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 hashing, making it non-secure unless used in conjunction with [[Transport Layer Security|TLS]].

Technically, digest authentication is an application of [[cryptographic hash]]ing with usage of [[cryptographic nonce|nonce]] values to prevent [[replay attack]]s. It uses the [[Hypertext Transfer Protocol|HTTP]] protocol.

DIGEST-MD5 as a [[Simple_Authentication_and_Security_Layer|SASL]] mechanism specified by {{IETF RFC|2831}} is obsolete since July 2011.<ref>[https://datatracker.ietf.org/doc/html/rfc6331 Moving DIGEST-MD5 to Historic, July 2011].</ref>

== Overview ==

Digest access authentication was originally specified by {{IETF 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 ''[[Cryptographic nonce|nonce value]]''. The authentication response is formed as follows (where HA1 and HA2 are names of string variables, ''method'' is the HTTP method verb, and ''digestURI'' the URI to be accessed):

:<syntaxhighlight lang="text">
HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)
</syntaxhighlight>

An MD5 hash is a 16-byte value. The HA1 and HA2 values used in the computation of the response are the hexadecimal representation (in lowercase) of the MD5 hashes respectively.

RFC 2069 was later replaced by {{IETF 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 algorithm directive's value is "[[MD5]]" or unspecified, then HA1 is

:<syntaxhighlight lang="text">
HA1 = MD5(username:realm:password)
</syntaxhighlight>

If the algorithm directive's value is "MD5-sess", then HA1 is

:<syntaxhighlight lang="text">
HA1 = MD5(MD5(username:realm:password):nonce:cnonce)
</syntaxhighlight>

If the qop directive's value is "auth" or is unspecified, then HA2 is

:<syntaxhighlight lang="text">
HA2 = MD5(method:digestURI)
</syntaxhighlight>

If the qop directive's value is "auth-int", then HA2 is

:<syntaxhighlight lang="text">
HA2 = MD5(method:digestURI:MD5(entityBody))
</syntaxhighlight>

If the qop directive's value is "auth" or "auth-int", then compute the response as follows:

:<syntaxhighlight lang="text">
response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)
</syntaxhighlight>

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

:<syntaxhighlight lang="text">
response = MD5(HA1:nonce:HA2)
</syntaxhighlight>

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

In September 2015, RFC 7616 replaced RFC 2617 by adding 4 new [[Algorithm|algorithms]]: "SHA-256", "SHA-256-sess", "SHA-512-256" and "SHA-512-256-sess". The encoding is equivalent to "MD5" and "MD5-sess" algorithms, with [[MD5|MD5 hashing function]] replaced with [[SHA-256]] and [[SHA-256|SHA-512-256]]. 

In {{As of|2021|10|bare=yes}}, Firefox 93<ref>{{cite web |title=Bug 472823: SHA 256 Digest Authentication |url=https://bugzilla.mozilla.org/show_bug.cgi?id=472823 |website=Mozilla Bugzilla}}</ref> implemented the "SHA-256" and "SHA-256-sess" algorithms for digest authentication. However, support for "SHA-512-256", "SHA-512-256-sess" algorithms and username hashing is still lacking.<ref>{{cite web |title=Mozilla-central: support SHA-256 HTTP Digest auth |url=https://hg.mozilla.org/mozilla-central/rev/7a4994734e00 |website=Mozilla-central}}</ref>{{Verify source|date=December 2025}} 

In {{As of|2023|8|bare=yes}}, Chromium 117 implemented "SHA-256".<ref>{{cite web |title=Chrome Feature: RFC 7616 Digest auth: Support SHA-256 and username hashing|url=https://chromestatus.com/feature/5139896267702272?context=myfeatures}}</ref>

== Impact of MD5 security on digest authentication ==

The [[MD5]] calculations used in HTTP digest authentication is intended to be "[[one-way function|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]])&nbsp;– perhaps aided by a [[dictionary attack|dictionary]] or [[rainbow table|suitable look-up list]], which for MD5 is readily available.<ref>[http://project-rainbowcrack.com/table.htm List of rainbow tables, Project Rainbowcrack]. Includes multiple MD5 rainbow tables.</ref>

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 [[cryptography|cryptographic]] construction that is used is based on the MD5 hash function, [[collision attack]]s were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.<ref name="CryptoRes-2004">{{cite web
  | title       = Hash Collision Q&A
  | url         = http://www.cryptography.com/cnews/hash.html
  | date        = 2005-02-16
  | publisher   = [[Cryptography Research]]
  | archiveurl  = https://web.archive.org/web/20100306180648/http://www.cryptography.com/cnews/hash.html
  | archivedate = 2010-03-06
}}{{better source needed|date=June 2010|reason=NOTE: Specific information not given; needs quote from exact version of this page originally cited.}}</ref> However, claims in 2006<ref>{{cite web
  | url       = https://eprint.iacr.org/2006/187.pdf
  | title     = On the Security of HMAC and NMAC Based on HAVAL, MD4, MD5, SHA-0 and SHA-1
  |author1=Jongsung Kim |author2=Alex Biryukov |author3=Bart Preneel |author4=Seokhie Hong | publisher = [[International Association for Cryptologic Research|IACR]]
}}</ref> cause some doubt over other MD5 applications as well. 

== HTTP digest authentication considerations ==
{{Unreferenced section|date=July 2024}}

=== Advantages ===

HTTP digest authentication is designed to be more secure than traditional digest authentication schemes, for example "significantly stronger than (e.g.) [[CRAM-MD5]] ..." (RFC 2617).

Some of the security strengths of HTTP digest authentication are:

* The password is not sent clear to the server.
* The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. [[JBoss]]<ref>{{cite web
 |url          = https://community.jboss.org/wiki/DIGESTAuth
 |title        = DIGEST Authentication (4.0.4+)
 |author       = Scott Stark
 |date         = 2005-10-08
 |publisher    = [[JBoss]]
 |access-date  = 2013-03-04
 |archive-date = 2015-10-18
 |archive-url  = https://web.archive.org/web/20151018155102/https://community.jboss.org/wiki/DIGESTAuth
 |url-status   = dead
}}</ref>) to store HA1 rather than the cleartext password (however, see disadvantages of this approach)
* Client nonce was introduced in RFC 2617, which allows the client to prevent [[chosen-plaintext attack]]s, such as [[rainbow table]]s that could otherwise threaten digest authentication schemes
* Server nonce is allowed to contain timestamps. Therefore, the server may inspect nonce attributes submitted by clients, to prevent [[replay attack]]s
* Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse
* It prevents [[Phishing]] because the plain password is never sent to any server, be it the correct server or not.  (Public key systems rely on the user being able to verify that the URL is correct.)

=== Disadvantages ===

There are several drawbacks with digest access authentication:
* The website has no control over the user interface presented to the end user.
* 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 attack|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
* A server can store HA1 = MD5(username:realm:password) instead of the password itself. However, if the stored HA1 is leaked, an attacker can generate valid responses and access documents in the realm just as easily as if they had access to the password itself. The table of HA1 values must therefore be protected as securely as a file containing plaintext passwords.<ref>{{cite journal
  | url       = https://tools.ietf.org/html/rfc2617#section-4.13
  | title     = HTTP Authentication: Basic and Digest Access Authentication: Storing passwords
  | date      = June 1999
  | publisher = [[IETF]]
| doi = 10.17487/RFC2617
 | last1 = Franks
 | first1 = J.
 | last2 = Hallam-Baker
 | first2 = P.
 | last3 = Hostetler
 | first3 = J.
 | last4 = Lawrence
 | first4 = S.
 | last5 = Leach
 | first5 = P.
 | last6 = Luotonen
 | first6 = A.
 | last7 = Stewart
 | first7 = L.
 | s2cid = 27137261
 | url-access = subscription
 }}</ref>
* Digest access authentication 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)

Also, since the [[MD5|MD5 algorithm]] is not allowed in [[FIPS 140-2|FIPS]], HTTP Digest authentication will not work with FIPS-certified<ref name="FIPS approved functions" group="note">The following is a list of FIPS approved algorithms: {{cite web
  | url       = http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf
  | title     = Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules
  | date      = January 31, 2014
  | publisher = National Institute of Standards and Technology
}}</ref> crypto modules.

=== Alternative authentication protocols ===

By far the most common approach is to use a [[HTTP+HTML form-based authentication]] cleartext protocol, or more rarely [[Basic access authentication]]. These weak cleartext protocols used together with [[HTTPS]] network encryption resolve many of the threats that digest access authentication is designed to prevent. However, this use of HTTPS relies upon the end user to accurately validate that they are accessing the correct URL each time to prevent sending their password to an untrusted server, which results in [[phishing]] attacks.
Users often fail to do this, which is why phishing has become the most common form of security breach.

Some strong authentication protocols for web-based applications that are occasionally used include:

* [[Public key]] authentication (usually implemented with a [[HTTPS]] / [[Secure Sockets Layer|SSL]] [[client certificate]]) using a client certificate.
* [[Kerberos (protocol)|Kerberos]] or [[SPNEGO]] authentication, employed for example by [[Microsoft IIS]] running configured for [[Integrated Windows Authentication]] (IWA).
* [[Secure Remote Password protocol]] (preferably within the [[HTTPS]] / [[Transport Layer Security|TLS]] layer).  However, this is not implemented by any mainstream browsers.
* [[JSON Web Token]] (JWT) is a [[JSON]]-based standard RFC 7519 for creating [[access token]]s that assert some number of claims.

== Example with explanation ==

The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each [[HTTP request|request]] and [[HTTP response|response]]. Note that only the "auth" (authentication) quality of protection code is covered&nbsp;– {{as of|2005|04|lc=y}},<!-- https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&diff=prev&oldid=12216793 --> only the [[Opera (web browser)|Opera]] and [[Konqueror]] web browsers are known to support "auth-int" (authentication with integrity protection).{{Citation needed|date=December 2025}}{{Update inline|date=December 2025}} 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.<ref group="note">A client may already have the required username and password without needing to prompt the user, e.g. if they have previously been stored by a web browser.</ref> Typically this is because the user simply entered the address or followed a link to the page.
# The server responds with the [[HTTP 401|401 "Unauthorized"]] response code, providing the authentication realm and a randomly generated, single-use value called a ''[[cryptographic nonce|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 return the "401" response code and the client would prompt the user again.

----

; Client request (no authentication):
<syntaxhighlight lang="http">
GET /dir/index.html HTTP/1.0
Host: localhost
</syntaxhighlight>
(followed by a [[Newline|new line]], in the form of a [[carriage return]] followed by a [[line feed]]).<ref>{{cite web
  | url       = http://www.w3.org/Protocols/HTTP/1.0/spec.html#Request
  | title     = Hypertext Transfer Protocol -- HTTP/1.0: Request
  | author    = [[Tim Berners-Lee]], [[Roy Fielding]], [[Henrik Frystyk Nielsen]]
  | date      = 1996-02-19
  | publisher = [[W3C]]
}}</ref>

; Server response:
<syntaxhighlight lang="http">
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>
</syntaxhighlight>
; Client request (username "Mufasa", password "Circle Of Life"):
<syntaxhighlight lang="http">
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"
</syntaxhighlight>
(followed by a blank line, as before).

; Server response:
<syntaxhighlight lang="http">
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984
</syntaxhighlight>
(followed by a blank line and HTML text of the restricted page).

----

The "response" value is calculated in three steps, as follows. Where values are combined, they are [[delimiter|delimited]] by colons.

# The MD5 hash of the combined username, authentication realm and password is calculated. The result is referred to as HA1.
# The MD5 hash of the combined method and digest [[Uniform Resource Identifier|URI]] is calculated, e.g. of <code>"GET"</code> and <code>"/dir/index.html"</code>. The result is referred to as HA2.
# The MD5 hash of the combined HA1 result, server nonce (nonce), request counter (nc), client nonce (cnonce), quality of protection code (qop) and HA2 result is calculated. The result is the "response" value provided by the client.

Since the server has the same information as the client, the response can be checked by performing the same calculation. In the example given above the result is formed as follows, where <code>MD5()</code> represents a function used to calculate an [[MD5 hash]], backslashes represent a continuation and the quotes shown are not used in the calculation.

Completing the example given in RFC 2617 gives the following results for each step.

    HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
        = 939e7578ed9e3c518a452acee763bce9
 
    HA2 = MD5( "GET:/dir/index.html" )
        = 39aff3a2bab6126f332b942af96d3366
 
    Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
                     dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                     00000001:0a4f113b:auth:\
                     39aff3a2bab6126f332b942af96d3366" )
             = 6629fae49393a05397450978507c4ef1

At this point the client may make another request, reusing the server nonce value (the server only issues a new nonce for each [[HTTP 401|"401" response]]) but providing a new client nonce (cnonce). For subsequent requests, the hexadecimal request counter (nc) must be greater than the last value it used&nbsp;– otherwise an attacker could simply "[[replay attack|replay]]" an old request with the same credentials. It is up to the server to ensure that the counter increases for each of the nonce values that it has issued, rejecting any bad requests appropriately. Obviously changing the method, URI and/or counter value will result in a different response value.

The server should remember nonce values that it has recently generated. It may also remember when each nonce value was issued, expiring them after a certain amount of time. If an expired value is used, the server should respond with the "401" status code and add <code>stale=TRUE</code> to the authentication header, indicating that the client should re-send with the new nonce provided, without prompting the user for another username and password.

The server does not need to keep any expired nonce values&nbsp;– it can simply assume that any unrecognised values have expired. It is also possible for the server to only allow each nonce value to be returned once, although this forces the client to repeat every request. Note that expiring a server nonce immediately will not work, as the client would never get a chance to use it.

== The .htdigest file ==

.htdigest is a [[Flat file database|flat-file]] used to store usernames, realm and passwords for digest authentication of [[Apache HTTP Server]]. The name of the file is given in the [[.htaccess]] configuration, and can be anything, but ".htdigest" is the canonical name. The file name starts with a dot, because most [[Unix-like]] operating systems consider any file that begins with dot to be hidden. This file is often maintained with the [[shell (computing)|shell]] command "htdigest" which can add, and update users, and will properly encode the password for use.

The "htdigest" command is found in the '''apache2-utils''' package on [[dpkg]] package management systems and the '''httpd-tools''' package on [[RPM Package Manager|RPM package management]] systems.

The syntax of the htdigest command:<ref name="htdigest">{{cite web|url=http://httpd.apache.org/docs/2.2/programs/htdigest.html|title=htdigest - manage user files for digest authentication|work=apache.org}}</ref>
 htdigest [ -c ] ''passwdfile realm username''

The format of the .htdigest file:<ref name="htdigest" />
 user1:Realm:5ea41921c65387d904834f8403185412
 user2:Realm:734418f1e487083dc153890208b79379

== SIP digest authentication ==

[[Session Initiation Protocol]] (SIP) uses basically the same digest authentication algorithm. It is specified by RFC 3261.

== Browser implementation ==

Most browsers have substantially implemented the spec, some barring certain features such as auth-int checking or the MD5-sess algorithm. If the server requires that these optional features be handled, clients may not be able to authenticate (though note mod_auth_digest for Apache does not fully implement RFC 2617 either).

* [[Amaya (web browser)|Amaya]]
* [[Gecko (layout engine)|Gecko]]-based: (not including auth-int<ref>{{cite web
  | url    = https://bugzilla.mozilla.org/show_bug.cgi?id=168942
  | title  = Bug 168942 - Digest authentication with integrity protection
  | date   = 2002-09-16
  | author = Emanuel Corthay
  | work   = [[Mozilla]]
}}</ref>)
** [[Mozilla Application Suite]]
** [[Mozilla Firefox]]
** [[Netscape (version 7)|Netscape 7+]]
* [[Chromium (web browser)|Chromium]]-based: (since 2023<ref>{{cite web
  | url    = https://chromium-review.googlesource.com/c/chromium/src/+/4611879
  | title  = RFC 7616 HTTP digest auth: Add support for SHA-256 and username hashing
  | date   = 2023-07-27
  | author = Deomid "rojer" Ryabkov
  | work   = [[Chromium (web browser)]]
}}</ref>)
** [[Google Chrome]]
** [[Microsoft Edge]]
** [[Samsung Internet]]
** [[Opera (web browser)|Opera]]
* [[ICab|iCab 3.0.3+]]
* [[KHTML]]- and [[WebKit]]-based: (not including auth-int<ref>{{cite web
 |url=https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf 
 |title=HTTP Digest Integrity: Another look, in light of recent attacks 
 |author=Timothy D. Morgan 
 |date=2010-01-05 
 |publisher=vsecurity.com 
 |url-status=dead 
 |archiveurl=https://web.archive.org/web/20140714192236/https://secure.vsecurity.com/download/papers/HTTPDigestIntegrity.pdf 
 |archivedate=2014-07-14 
}}</ref>)
** [[iCab]] 4
** [[Konqueror]]
** [[Google Chrome]]
** [[Safari (web browser)|Safari]]
* [[Tasman (layout engine)|Tasman]]-based:
** [[Internet Explorer for Mac]]
* [[Trident (layout engine)|Trident]]-based:
** [[Internet Explorer 5|Internet Explorer 5+]]<ref>{{cite web
  | url   = https://technet.microsoft.com/en-us/library/cc738318(v=ws.10).aspx
  | title = TechNet Digest Authentication
  | date  = August 2013
}}</ref> (not including auth-int)
* [[Presto (layout engine)|Presto]]-based:
** [[Opera (web browser)|Opera]] (Opera switched away from Presto in 2013)<ref>{{cite web |last1=Anthony |first1=Sebastian |title=Opera admits defeat, switches to Google's Chromium |url=https://www.extremetech.com/computing/148312-opera-drops-presto-switch-to-google-and-apples-webkit-rendering-engine |website=Extreme Tech |publisher=Ziff Davis |access-date=19 January 2024 |date=February 13, 2013}}</ref>
** [[Opera Mobile]]
** [[Opera Mini]]
** [[Nintendo DS Browser]]
** [[Nokia 770]] Browser
** [[mylo (Sony)|Sony Mylo 1]]'s Browser
** [[Wii browser|Wii Internet Channel Browser]]

== Deprecations ==
Because of the disadvantages of Digest authentication compared to Basic authentication over HTTPS it has been deprecated by a lot of software e.g.:
* Bitbucket<ref>{{Cite web |last=DeLorenzo |first=Ike |date=2015-04-03 |title=Fare-thee-well, Digest access authentication |url=https://bitbucket.org/blog/fare-thee-well-digest-access-authentication |access-date=2025-01-21 |website=Bitbucet |archive-url=https://web.archive.org/web/20240423145906/https://bitbucket.org/blog/fare-thee-well-digest-access-authentication |archive-date=2024-04-23}}</ref>
* Symfony PHP framework<ref>{{Cite web |title=[RFC] Deprecate HTTP Digest authentication · Issue #24325 · symfony/symfony |url=https://github.com/symfony/symfony/issues/24325 |access-date=2025-01-21 |archive-url=https://web.archive.org/web/20231012074234/https://github.com/symfony/symfony/issues/24325 |archive-date=2023-10-12 |website=GitHub |language=en}}</ref>

== See also ==
* [[AKA (security)]]
* [[JSON Web Token]] (JWT)
* [[Basic access authentication]]

== Notes ==
{{Reflist|group=note}}

== References ==
{{Reflist}}

{{Cryptography hash}}

== External links ==
* [https://datatracker.ietf.org/doc/html/rfc7235 RFC 7235]
* [https://datatracker.ietf.org/doc/html/rfc6331 RFC 6331]
* [https://datatracker.ietf.org/doc/html/rfc2617 RFC 2617] (updated by RFC 7235)
* [https://datatracker.ietf.org/doc/html/rfc2069 RFC 2069] (obsolete)

[[Category:Cryptographic protocols]]
[[Category:Hypertext Transfer Protocol]]
[[Category:Request for Comments]]
[[Category:Computer access control protocols]]

[[de:HTTP-Authentifizierung#Digest Access Authentication]]
[[fr:HTTP Authentification#Méthode Digest]]