Digest access authentication: Difference between revisions

Revision as of 17:55, 19 July 2021

Revision as of 19:26, 7 August 2021

Line 90:

| date = 2005-10-08

| publisher = [[JBoss]]

}}</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:

* 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 web

* 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<ref>{{cite web

| url = https://tools.ietf.org/html/rfc2617#section-4.13

| title = HTTP Authentication: Basic and Digest Access Authentication: Storing passwords

Line 108:

| publisher = [[IETF]]

}}</ref>

* ItDigest 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