Example 9-1. An unauthorized response sent by Apache
HTTP/1.1 401 Authorization Required Date: Mon, 21 May 2001 23:40:54 GMT Server: Apache/1.3.19 (Unix) PHP/4.0.5 WWW-Authenticate: Basic realm="Marketing Secret" Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>401 Authorization Required</TITLE> </HEAD><BODY> <H1>Authorization Required</H1> This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.<P> <HR> <ADDRESS>Apache/1.3.19 Server at dexter Port 80</ADDRESS> </BODY></HTML>
The WWW-Authenticate header field contains the challenge method, the method by which the browser collects and encodes the user credentials. In the example the method is set to Basic. The header field also contains the name of the realm the authentication applies to.
The realm is used by the browser to label usernames and passwords and is displayed when credentials are collected; Figure 9-1 shows the realm Marketing Secret. A browser can automatically respond to a challenge if the browser has previously collected credentials for the realm. The browser stores authentication credentials for each realm it encounters until the browser program is terminated. Once the browser has collected the credentials, it resends the original request with the additional Authorization header field. Example 9-2 shows a request containing encoded credentials in the Authorization header field.
Example 9-2. An authorized request sent by the browser after the credentials have been collected
GET /auth/keys.php HTTP/1.0 Connection: Keep-Alive User-Agent: Mozilla/4.51 [en] (WinNT; I) Host: localhost Accept: image/gif, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8 Authorization: Basic ZGF2ZTpwbGF0eXB1cw==
The Basic encoding is just that: basic! The string that is encoded into the Authorization header field is simply the username and the password separated by a colon character and then base-64 encoded. Base-64 encoding isn't designed to protect data; rather it allows binary data to be transmitted over a network, and therefore provides no real protection of the username and password. The Basic encoding of the credentials provides protection from casual inspection only.
Some web servers, including Apache, support the Digest encoding method. The Digest method is more secure than the Basic method because the password isn't sent over the network. When the Digest method is used, the server generates a random string to send with the authorization challenge. The browser then encrypts the random string using the password provided by the user as an encryption key. The encrypted string is sent back to the server in the Authorization header field, as the resource is rerequested. The server uses a copy of the password stored at the server to encrypt the same random string and compares it to the encrypted string that has just arrived. If they match, the server has authenticated the user. The advantage is that only the encrypted random string is exchanged, not the user password.
Both the web server and the browser need to support the Digest encoding method. Unfortunately, most browsers support only Basic. Microsoft has developed a proprietary method for use with HTTP authentication called NTLM that is supported only by Internet Explorer and Microsoft's IIS web server.
While the Basic encoding method provides no real security, the Secure Sockets Layer (SSL) protocol can protect the HTTP requests and responses sent between browsers and servers. Because of SSL, there is little pressure on browser builders to implement more secure schemes. For web database applications that transmit sensitive information, such as passwords, we recommend SSL be used. We discuss SSL later in this chapter.