Digest Authentication

Hello again. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today I will focus on Digest Authentication.

Digest Authentication is a challenge-response authentication protocol used to authenticate users over the network. Challenge/response protocols require an authenticating server to generate a challenge containing some amount of unpredictable data. A client then uses a key derived from the user’s password to encrypt the challenge and forms a response. The server, or a trusted service such as Active Directory, can verify that the user possesses the correct password by comparing the client’s encrypted response to a response generated by Domain Controller based on the credential associated with the user in Active Directory or by the server account database for local users. If the responses match, the user is authenticated.

Digital authentication is very similar to NTLM protocol or basic authentication where a simple challenge-response paradigm is used. In the digest authentication mechanism, the client is presented with a nonce, a randomly generated value sent by the server to the client. The client proves knowledge of the password by computing a keyed hash over parameters sent by the server and parameters generated locally by the client.

Once the server has validated the keyed hash by performing the same computation, it can authenticate itself to the client by computing another keyed hash and returning it to the client. Because the correct keyed hash results can only be created by someone who knows the password, the two parties are assured of the other knowing the password.

The Digest Authentication protocol is designed for use with Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) exchanges.

HTTP example:

When you open the browser and attempt to connect to the website which requires Digest Authentication, your first connection which is anonymous (frame 58 below) will be refused. The server will send you the Challenge (frame 59) containing nonce, charset that can be used, information about algorithm and the realm name. Also, server signals that it supports channel binding by invoking the following 12 characters in the server nonce: "+Upgraded+v1"

A valid response contains a checksum (by default, the MD5 checksum) of the username, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear.

In the response from the client we also can see cnonce - which is client nonce that contains 128 bits of entropy by using a random-number generator as well as a NC - nonce counter used for replay detection attacks.

Now the server needs to verify the challenge response. It will query the Domain Controller for a user password hash and compute the MD5 hash again on the user name, password hash and the nonce. This information will be encapsulated by the NRPC protocols while querying Domain Controller and will be using method netrLogonSamLogonEx. Once the computation is done, server will compare the result with the received challenge response from the client. If the keyed hash is the same – that means user is successfully authenticated. Note: server doesn’t have to have access to user cleat-text password.

Of course, your server should be configured to require Digest Authentication. For example default installation of Windows Server IIS role doesn’t contain Digest Authentication module. You should install it from the Server Manager first. Once it is installed you can go to the Authentication section in the IIS Management Console and enable it:

If you don’t want to bother with UI, you can do it directly in web.config file by adding the section:

<digestAuthentication enabled='true' />

The realm is set to the domain name of the server by default. This can be overridden at the server by configuration options. The user is prompted and has the chance to override the realm value sent by the server (that is, the user can enter a realm other than the one sent by the server).

From now every request going to the digest.contoso.com will require authentication. User experience will be a little different for Internet Explorer and Edge:

Edge:

Internet Explorer:

SASL Example:

User opens the LDP.exe and perform a BIND to active directory with Digest Authentication.

First the user will initiate the connection without sending any credentials but with information that Digest Authentication should be used:

Server similarly to the HTTP example will send us challenge:

And then we need to answer to that challenge by sending our credentials with nonce and domain name to the server:

Logging:

Assuming proper auditing is configured we can expect following events in the Security Log:

Server side: Event ID 4672

Domain Controller side:

Success (Event ID 4776, error code 0x0):

Failure (Event ID 4776, error code 0xC000006A – bad user name or password)

There are some articles on the Internet that say if you want to use Digest Authentication you have to store your password in Active Directory by using reversible encryption.

There are 2 settings for this:

Global in the Domain Password Policy (GPO):

Or individually on the User account:

This configuration was required prior to Windows 2008 where IIS really required passwords in the clear text from Active Directory to verify the Challenge’s response from the client. However, since Advanced Digest Authentication has been introduced (now there is no differentiation) Web Server can use pre-computed MD5 Hashes of user credentials that are stored in AD.

There are 29 variations of credentials stored as part of Suplemental-Credetntials attribute of user object in Active Directory:

Below is an example of table with MD5 hash for credentials for user “u1” and password: “password”:

1) u1:CONTOSO:password >> B57D463D9044A36BF3283CBEF5B76014

2) u1:contoso:password >>EA3B92F0D84D212CC057E63A81E36244

3) U1:CONTOSO:password >> A109619CE218D1DD95EA94A7D5BD466F

You can review the MD5 w-digest construction logic under: https://msdn.microsoft.com/en-us/library/cc245680.aspx

Kerberos and public key–based authentication offer stronger security guarantees both in terms of initial authentication and subsequent confidentiality and integrity of client/server traffic. The digest authentication mechanism can be used in environments where these stronger mechanisms are not available and can serve for interoperability purposes with multiple vendors, browsers, web servers, and directory services.