Kabel .NET - About HTTP Digest

About HTTP Digest

On this page:
The Mechanism: How Credentials are exchanged
Tickets
Security
Availability
References

HTTP Digest is an extension to the HTTP protocol, which allows more secure authentication than the earlier HTTP scheme called Basic Authentication. Unlike this predecessor, HTTP Digest is conceptualized so that passwords are never exchanged in clear-text and cannot be decrypted from the secure communication’s data stream.

The Mechanism: How Credentials are exchanged

Like most of today’s authentication schemes, HTTP Digest relies on the concept that server and client know a common secret, a password, which one can use to authenticate the other. Specifically, HTTP Digest implements a so-called Challenge/Response scheme whose process works in the following steps:

The Client requests a protected resource on the Server, without passing any credentials at first
The Server will reject this initial request but respond with a uniquely generated message (“challenge”), which the Client must manipulate subsequently.
The Client now uses his password to apply a hashing function to the received challenge. It then tries to re-access the original resource from step 1, now sending the hashed challenge (“response”) along with his plain-text username to the Server for verification.

A “hashing function” is a special cryptographic algorithm which turns data of any length into a unique sequence of constant length. It is impossible to reverse the output of a hashing function and two sequences will only match if the original data was identical. Thus, hashing can effectively be used to compare two hashed values without knowing the original, plain-text values.
The Server looks up the username and retrieves the corresponding password for it. Now it applies the same hashing function as the Client to the original challenge.
If the hash that the Server generated matches the hash that the Client submitted with his second request, then the Client should be authenticated because at this point, it is cryptographically guaranteed that the Client knew the correct password. If the hashes do not match, authentication fails and the Server rejects the Client’s request for the protected resource.
Important to remember: A hash cannot be reversed; if an intruder were to wire-tap the Client/Server communication, he could not extract the password from the hashed challenged.
On subsequent requests by the authenticated Client, the Server has control over the lifetime of the authentication’s validity. Specifically, the Client will continue to use the previously hashed challenge until the Server responds with a “staleness” – or expiration – notice and an entirely new challenge. At this point, the Client is required to re-prove his identity by using the “fresh” challenge and his password to generate the appropriate hash. This introduces the more advanced concepts of tickets...

Realms

Each web application using HTTP Digest has a distinctive Realm property (sometimes also called Domain), which can be thought of as a name for the application, which the Client can commonly identify. Besides identifying the application to the Client, it also serves as a protection against password fraud: the Realm is included in the hashes, which Client and Server exchange; thus, when a hashed challenge for Realm A is compromised, it cannot be used for Realm B.

Tickets

The challenges generated by the Kabel .NET implementation of HTTP Digest do not simply contain random data. Instead, these more “meaningful” challenges contain specially encoded information which the Server later re-uses to determine whether a challenge is possibly too old (“expired”, “stale”), has been used too many times, or is otherwise inappropriate for the requested resource.

Note on Terminology: Kabel .NET, in its implementation and documentation,
will use the term “ticket” to refer to these “more meaningful” challenges.
The general term used for “challenge” in the original HTTP Digest is “nonce”. [1]

The use of tickets becomes necessary because often, a verified challenge will be used for multiple subsequent requests. An advanced intruder could spy on a communication and pick-up an already verified challenge, attach it to his own request and make the Server believe he was the challenge’s original Client. These attacks are called replay attacks but through the use of specialized challenges, the Server is able to recognize and reject them.

When a Client is technically authenticated successfully but the ticket he used has become invalid for any above reasons, the Server returns the old ticket as “stale” and returns a new one, which the Client must instead from now on. This re-authentication between Client and Server is handled with interruption to the overall communication; a “stale” ticket does not generate an error (such as “Access Denied”) on the client side, rather the Client will automatically make the same request again using the new challenge.

Tickets in Kabel .NET: Timeouts, Usage Counts, Resource Dependence

In its base (or “out-of-the-box”) implementation, Kabel .NET offers three ways of specializing tickets.

Timeouts: All issued tickets are configured to be valid for only a limited amount of time (by default, 5 minutes).
An expired ticket will be returned as “stale”.
Usage Counts: Additionally, a maximum number of successful requests per ticket may be specified.
Setting this value to 1 will result in one-time tickets and the client will be issued a new ticket after each successful request to be used for the next one; the possibility of replay attacks can thus be eliminated.
Resource Dependence: Lastly, tickets may contain information about the original resource (URL) they were issued for. An example: The Client received a ticket with reference to resource A but an intruder snatched this ticket and wants to access resource B with it; when employing resource-dependent tickets, the Server will require re-authentication for B, so that the intruder is denied and his harm effectively contained.

Security

As acknowledged by the Working Group responsible for drafting the HTTP Digest standard, this mechanism is not as secure as Kerberos or Public Key infrastructures, but still provides adequate protection of Client credentials and Server resources for the purposes of most web applications. [1]

While passwords are exchanged securely with this method, be aware that after all HTTP Digest (like any password-based system) is only secure as your shortest and most obvious password.

Availability

One of the great advantages of HTTP Digest today is its relatively broad availability on client platforms. Thus, client-side implementation of Digest authentication is provided out-of-the-box in the communication APIs of Microsoft Windows as well as Internet Explorer and Opera browsers. Furthermore, it is supported on different SOAP platforms, including the .NET Framework [2], the open-source Ximian Soup [3], Java-based TME Glue [4] and is also expected to ship with version 1.4 of the popular PocketSOAP [5].

References

[1] HTTP Digest Specification: Formatted | Original
[2] Microsoft .NET Framework
[3] Ximian Soup
[4] The Mind Electric Glue
[5] PocketSOAP; Reference to Version 1.4