Content deleted Content added
→Overview: Mention limitations from browsers |
m Open access bot: url-access updated in citation with #oabot. |
||
| (37 intermediate revisions by 30 users not shown) | |||
Line 1:
{{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
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
:<syntaxhighlight lang="text">
Line 16 ⟶ 19:
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
If the algorithm directive's value is "MD5" or unspecified, then HA1 is
Line 56 ⟶ 59:
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]]. However, {{as of
== Impact of MD5 security on digest authentication ==
Line 69 ⟶ 72:
| 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 ===
Line 85 ⟶ 89:
* 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
|title
|author
|date
|publisher
|access-date = 2013-03-04
}}</ref>) to store HA1 rather than the cleartext password▼
|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
Line 102 ⟶ 110:
* 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
}}</ref>▼
| last1 = Franks
* 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)▼
| 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>
▲*
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
Line 127 ⟶ 152:
* [[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 [[
== 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 – {{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=January 2024}} 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:
Line 291 ⟶ 316:
}}</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]]
Line 301 ⟶ 326:
== 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 ==
Line 319 ⟶ 344:
== 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]]
| |||