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 TLS.
Digest access authentication was originally specified by RFC2069 (An Extension to HTTP: Digest Access Authentication). RFC 2069 specifies roughly a traditional digest authentication scheme with security maintained by a server-generated nonce value. The authentication response is formed as follows (where HA1 and HA2 are names of string variables):
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 RFC2617 (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 attackcryptanalysis.
If the algorithm directive's value is "MD5" or unspecified, then HA1 is
HA1 = MD5(username:realm:password)
If the algorithm directive's value is "MD5-sess", then HA1 is
If the qop directive is unspecified, then compute the response as follows:
response = MD5(HA1:nonce:HA2)
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 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 hashing function replaced with SHA-256 and SHA-512-256. However, as of July2021[update], none of popular browsers, including Firefox[2] and Chrome,[3] support SHA-256 as the hash function. As of October2021[update], Firefox 93[4] officially supports "SHA-256" and "SHA-256-sess" algorithms for digest authentication. However, support for "SHA-512-256", "SHA-512-256-sess" algorithms and username hashing[5] is still lacking.[6]As of August2023[update], Chromium 117 (then Chrome and Edge) supports "SHA-256".[7]
Impact of MD5 security on digest authentication
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. 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)– perhaps aided by a dictionary or suitable look-up list, which for MD5 is readily available.[8]
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 cryptographic construction that is used is based on the MD5 hash function, collision attacks were in 2004 generally believed to not affect applications where the plaintext (i.e. password) is not known.[9] However, claims in 2006[10] cause some doubt over other MD5 applications as well.
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[11]) 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 attacks, such as rainbow tables 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 attacks
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 (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.[12]
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 algorithm is not allowed in FIPS, HTTP Digest authentication will not work with FIPS-certified[note 1] 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:
The following example was originally given in RFC 2617 and is expanded here to show the full text expected for each request and response. Note that only the "auth" (authentication) quality of protection code is covered– as of April2005[update], only the Opera and Konqueror web browsers are known to support "auth-int" (authentication with integrity protection).[citation needed] 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.[note 2] Typically this is because the user simply entered the address or followed a link to the page.
The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly generated, single-use value called a 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.
(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 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 URI is calculated, e.g. of "GET" and "/dir/index.html". 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 MD5() 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.
At this point the client may make another request, reusing the server nonce value (the server only issues a new nonce for each "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– otherwise an attacker could simply "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 stale=TRUE 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– 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 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 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 management systems.
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).
↑ 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.
Related Research Articles
The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.
In computing, the Challenge-Handshake Authentication Protocol (CHAP) is an authentication protocol originally used by Point-to-Point Protocol (PPP) to validate users. CHAP is also carried in other authentication protocols such as RADIUS and Diameter.
Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.
SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded. A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.
In computer security, challenge-response authentication is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated.
A cryptographic hash function (CHF) is a hash algorithm that has special properties desirable for a cryptographic application:
passwd is a command on Unix, Plan 9, Inferno, and most Unix-like operating systems used to change a user's password. The password entered by the user is run through a key derivation function to create a hashed version of the new password, which is saved. Only the hashed version is stored; the entered password is not saved for security reasons.
An authentication protocol is a type of computer communications protocol or cryptographic protocol specifically designed for transfer of authentication data between two entities. It allows the receiving entity to authenticate the connecting entity as well as authenticate itself to the connecting entity by declaring the type of information needed for authentication as well as syntax. It is the most important layer of protection needed for secure communication within computer networks.
Integrated Windows Authentication (IWA) is a term associated with Microsoft products that refers to the SPNEGO, Kerberos, and NTLMSSP authentication protocols with respect to SSPI functionality introduced with Microsoft Windows 2000 and included with later Windows NT-based operating systems. The term is used more commonly for the automatically authenticated connections between Microsoft Internet Information Services, Internet Explorer, and other Active Directory aware applications.
In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.
FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.
The Secure Remote Password protocol (SRP) is an augmented password-authenticated key exchange (PAKE) protocol, specifically designed to work around existing patents.
In cryptography, CRAM-MD5 is a challenge–response authentication mechanism (CRAM) based on the HMAC-MD5 algorithm. As one of the mechanisms supported by the Simple Authentication and Security Layer (SASL), it is often used in email software as part of SMTP Authentication and for the authentication of POP and IMAP users, as well as in applications implementing LDAP, XMPP, BEEP, and other protocols.
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system which is governed by Group Policy settings, for which different versions of Windows have different default settings.
TSIG is a computer-networking protocol defined in RFC 2845. Primarily it enables the Domain Name System (DNS) to authenticate updates to a DNS database. It is most commonly used to update Dynamic DNS or a secondary/slave DNS server. TSIG uses shared secret keys and one-way hashing to provide a cryptographically secure means of authenticating each endpoint of a connection as being allowed to make or respond to a DNS update.
MSN Chat was the Microsoft Network version of IRCX, which replaced Microsoft Chat, a set of Exchange-based IRCX servers first available in the Microsoft Comic Chat client, although Comic Chat was not required to connect.
In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic communication. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. They can also be useful as initialization vectors and in cryptographic hash functions.
.htpasswd is a flat-file used to store usernames and password for basic authentication on an Apache HTTP Server. The name of the file is given in the .htaccess configuration, and can be anything, although ".htpasswd" is the canonical name. The file name starts with a dot, because most Unix-like operating systems consider any file that begins with a dot to be hidden. The htpasswd command is used to manage .htpasswd file entries.
SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the Simple Mail Transfer Protocol (SMTP) whereby a client may log in using any authentication mechanism supported by the server. It is mainly used by submission servers, where authentication is mandatory.
In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
