The Improvements of Digest Authentication

13.1 The Improvements of Digest Authentication

Digest authentication is an alternate HTTP authentication protocol that tries to fix the most serious flaws of basic authentication. In particular, digest authentication:

                Never sends secret passwords across the network in the clear

                Prevents unscrupulous individuals from capturing and replaying authentication handshakes

                Optionally can guard against tampering with message contents

                Guards against several other common forms of attacks

Digest authentication is not the most secure protocol possible. [2] Many needs for secure HTTP transactions cannot be met by digest authentication. For those needs, Transport Layer Security (TLS) and Secure HTTP (HTTPS) are more appropriate protocols.

[2] For example, compared to public key-based mechanisms, digest authentication does not provide a strong authentication mechanism. Also, digest authentication offers no confidentiality protection beyond protecting the actual passwordthe rest of the request and response are available to eavesdroppers.

However, digest authentication is significantly stronger than basic authentication, which it was designed to replace. Digest authentication also is stronger than many popular schemes proposed for other Internet services, such as CRAM-MD5, which has been proposed for use with LDAP, POP, and IMAP.

To date, digest authentication has not been widely deployed. However, because of the security risks inherent to basic authentication, the HTTP architects counsel in RFC 2617 that "any service in present use that uses Basic should be switched to Digest as soon as practical." [3] It is not yet clear how successful this standard will become.

[3] There has been significant debate about the relevance of digest authentication, given the popularity and widespread adoption of SSL-encrypted HTTP. Time will tell if digest authentication gains the critical mass required.

13.1.1 Using Digests to Keep Passwords Secret

The motto of digest authentication is "never send the password across the network." Instead of sending the password, the client sends a " fingerprint " or "digest" of the password, which is an irreversible scrambling of the password. The client and the server both know the secret password, so the server can verify that the digest provided is a correct match for the password. Given only the digest, a bad guy has no easy way to find what password it came from, other than going through every password in the universe, trying each one! [4]

[4] There are techniques, such as dictionary attacks, where common passwords are tried first. These cryptanalysis techniques can dramatically ease the process of cracking passwords.

Let's see how this works (this is a simplified version):

                In Figure 13-1 a, the client requests a protected document.

                In Figure 13-1 b, the server refuses to serve the document until the client authenticates its identity by proving it knows the password. The server issues a challenge to the client, asking for the username and a digested form of the password.

                In Figure 13-1 c, the client proves that it knows the password by passing along the digest of the password. The server knows the passwords for all the users, [5] so it can verify that the user knows the password by comparing the client-supplied digest with the server's own internally computed digest. Another party would not easily be able to make up the right digest if it didn't know the password.

[5] In fact, the server really needs to know only the digests of the passwords.

                In Figure 13-1 d, the server compares the client-provided digest with the server's internally computed digest. If they match, it shows that the client knows the password (or made a really lucky guess!). The digest function can be set to generate so many digits that lucky guesses effectively are impossible . When the server verifies the match, the document is served to the clientall without ever sending the password over the network.

Figure 13-1. Using digests for password-obscured authentication

figs/http_1301.gif

We'll discuss the particular headers used in digest authentication in more detail in Table 13-8 .

13.1.2 One-Way Digests

A digest is a "condensation of a body of information." [6] Digests act as one-way functions, typically converting an infinite number of possible input values into a finite range of condensations. [7] One popular digest function, MD5, [8] converts any arbitrary sequence of bytes, of any length, into a 128-bit digest.

[6] Merriam-Webster dictionary, 1998.

[7] In theory, because we are converting an infinite number of input values into a finite number of output values, it is possible to have two distinct inputs map to the same digest. This is called a collision . In practice, the number of potential outputs is so large that the chance of a collision in real life is vanishingly small and, for the purpose of password matching, unimportant.

[8] MD5 stands for "Message Digest #5," one in a series of digest algorithms. The Secure Hash Algorithm (SHA) is another popular digest function.

128 bits = 2 128 , or about 1,000,000,000,000,000,000,000,000,000,000,000,000,000 possible distinct condensations.

What is important about these digests is that if you don't know the secret password, you'll have an awfully hard time guessing the correct digest to send to the server. And likewise, if you have the digest, you'll have an awfully hard time figuring out which of the effectively infinite number of input values generated it.

The 128 bits of MD5 output often are written as 32 hexadecimal characters , each character representing 4 bits. Table 13-1 shows a few examples of MD5 digests of sample inputs. Notice how MD5 takes arbitrary inputs and yields a fixed-length digest output.

Table 13-1. MD5 digest examples

Input

MD5 digest

"Hi"

 C1A5298F939E87E8F962A5EDFC206918 

"bri:Ow!"

 BEAAA0E34EBDB072F8627C038AB211F8 

"3.1415926535897"

 475B977E19ECEE70835BC6DF46F4F6DE 

"http://www.http-guide.com/index.htm"

 C617C0C7D1D05F66F595E22A4B0EAAA5 

"WE hold these Truths to be self-evident, that all Men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the Pursuit of HappinessThat to secure these Rights, Governments are instituted among Men, deriving their just Powers from the Consent of the Governed, that whenever any Form of Government becomes destructive of these Ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its Foundation on such Principles, and organizing its Powers in such Form, as to them shall seem most likely to effect their Safety and Happiness."

 66C4EF58DA7CB956BD04233FBB64E0A4 

Digest functions sometimes are called cryptographic checksums, one-way hash functions, or fingerprint functions.

13.1.3 Using Nonces to Prevent Replays

One-way digests save us from having to send passwords in the clear. We can just send a digest of the password instead, and rest assured that no malicious party can easily decode the original password from the digest.

Unfortunately, obscured passwords alone do not save us from danger, because a bad guy can capture the digest and replay it over and over again to the server, even though the bad guy doesn't know the password. The digest is just as good as the password.

To prevent such replay attacks, the server can pass along to the client a special token called a nonce , [9] which changes frequently (perhaps every millisecond, or for every authentication). The client appends this nonce token to the password before computing the digest.

[9] The word nonce means "the present occasion" or "the time being." In a computer-security sense, the nonce captures a particular point in time and figures that into the security calculations.

Mixing the nonce in with the password causes the digest to change each time the nonce changes. This prevents replay attacks, because the recorded password digest is valid only for a particular nonce value, and without the secret password, the attacker cannot compute the correct digest.

Digest authentication requires the use of nonces, because a trivial replay weakness would make un-nonced digest authentication effectively as weak as basic authentication. Nonces are passed from server to client in the WWW-Authenticate challenge.

13.1.4 The Digest Authentication Handshake

The HTTP digest authentication protocol is an enhanced version of authentication that uses headers similar to those used in basic authentication. Some new options are added to the traditional headers, and one new optional header, Authorization- Info , is added.

The simplified three-phase handshake of digest authentication is depicted in Figure 13-2 .

Figure 13-2. Digest authentication handshake

figs/http_1302.gif

Here's what's happening in Figure 13-2 :

                In Step 1, the server computes a nonce value. In Step 2, the server sends the nonce to the client in a WWW-Authenticate challenge message, along with a list of algorithms that the server supports.

                In Step 3, the client selects an algorithm and computes the digest of the secret password and the other data. In Step 4, it sends the digest back to the server in an Authorization message. If the client wants to authenticate the server, it can send a client nonce.

                In Step 5, the server receives the digest, chosen algorithm, and supporting data and computes the same digest that the client did. The server then compares the locally generated digest with the network-transmitted digest and validates that they match. If the client symmetrically challenged the server with a client nonce, a client digest is created. Additionally, the next nonce can be precomputed and handed to the client in advance, so the client can preemptively issue the right digest the next time.

Many of these pieces of information are optional and have defaults. To clarify things, Figure 13-3 compares the messages sent for basic authentication ( Figure 13-3 a-d) with a simple example of digest authentication ( Figure 13-3 e-h).

Figure 13-3. Basic versus digest authentication syntax

figs/http_1303.gif

Now let's look a bit more closely at the internal workings of digest authentication.

 



HTTP. The Definitive Guide
HTTP: The Definitive Guide
ISBN: 1565925092
EAN: 2147483647
Year: 2001
Pages: 294

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net