HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

The server takes the contents of the Authorization field, unpacks the contents to obtain the username and password, and checks these values against its own list of usernames and passwords. If there is a match, then the user is authenticated, and the server returns the resource. If there is no match, then the server indicates the failure by again returning the response shown in Figure 9.12, which causes the browser to once again prompt the user for a username and password.

GET /SecDir1/foo.html HTTP/1.0
User-Agent: Mozilla/1.1N (X11; I; IRIX 5.3 IP22)
Accept: *.*
Accept: image/gif
Accept: image/x-xbitmap
Accept: image/jpeg
Authorization: Basic aWFuOmJvb2J5

The Meaning of a Realm

A realm is simply a way of grouping username and password information, so that the browser need not prompt the user for this information if subsequent requests access the same realm. For example, suppose that a server administrator creates two secure directories, SecDir1 and SecDir2, and controls access to them using the password files pass1 and pass2, respectively. The administrator must also assign realm names to these directories so that, in communicating with a client, the server can inform the client which realm is involved, without giving away the name of the password file. In this example, we assume the administrator assigned the name “[email protected]” to the directory SecDir1 and the name “[email protected]” to the directory SecDir2.

The first time a user accesses a document in SecDir1, he or she is prompted for a username and password. The browser stores this name/password string under the realm name “[email protected].” On subsequent accesses to this directory or to any subdirectory of this directory (e.g. SecDir1/subdir2/ ), the browser sends an Authentication header field containing the authentication username and password already stored under this realm name and does not prompt the user for this information.

If, on the other hand, the user requests a document from SecDir2, then the browser does not sent the Authentication: header, since the password under the “[email protected]” realm does not apply to this directory. As a result, the server sends back a header containing a second WWW-Authenticate field:

WWW-Authenticate: Basic realm="[email protected]"

to tell the browser that authentication is required for this new, as yet unentered, realm. As the browser has never accessed this realm, it has no record of an appropriate username and password and therefore prompts the user for this information. This information is then stored on the browser under the second realm keyword.

Note how all the realm names in these examples contained the domain name of the server housing the access-controlled documents. This is not required, but is useful in that it guarantees unique realm names.

---

NOTE: Security Issues with the Basic Password Scheme

With most browsers, usernames and passwords are preserved until the user exits the browser. This can create security concerns when browsers are running on public-area workstations, since once a user has entered his or her username, this information can be reused by the next user of the machine.

---

Client-Server Data Encryption

As mentioned in the previous section, any authentication scheme is insecure if the messages and data passed between client and server are unencrypted: If the username and password are not encrypted, then they can be copied and used by someone else; if the transported data are not encrypted, then the data can be intercepted and read regardless of any password protection. There are two main approaches to encryption currently being deployed on the Web, and these are summarized in the following sections. Detailed information about these schemes is found in the references at the end of this chapter.

Netscape’s Secure Sockets Layer (SSL)

The Secure Sockets Layer protocol is designed as an encryption layer below the HTTP protocol. Thus, HTTP messages are unaffected, with encryption occurring just prior to converting the messages into TCP/IP packets for transmission over the Internet. To indicate the special nature of this connection, Netscape created the new URL https (HTTP-Secure) scheme, identical to http URLs save for the initial string https:. The default port for https URLs is 443, and not 80, so that a single machine can run secure and non-secure HTTP servers at the same time.

In principle, SSL can be used for any Internet tool that uses the underlying TCP/IP protocol for data communications. For example, Netscape markets NNTP news and LDAP directory servers employing SSL and intends to implement SSL widely in the future.

SSL works at several levels. At the encryption level, SSL employs a sophisticated security handshake protocol: When a client contacts a secure server, they exchange encryption keys, which are subsequently used to encrypt all data passed between the server and client. Encryption keys are never reused, to ensure that keys cannot be intercepted and used by an unauthorized party. The server also sends the client a cryptographic certificate that tells the client which server it is in contact with and that is used to validate that the server is indeed who it claims to be. Finally, the client and server send, ahead of the transmitted data, a message digest calculated from the data; the receiving party uses this message digest to ensure that the data content has not been modified by any intervening party.

Version 3 of the SSL protocol includes mechanisms for client certificates, which allow users to authenticate themselves using digital signatures just as servers are currently authenticated.

At present, almost all commercial browsers and servers support SSL.

Secure HTTP Protocol (S-HTTP)

Secure HTTP, or S-HTTP, is a second Web encryption and authentication scheme. S-HTTP is implemented as part of the HTTP protocol and involves additional HTTP request and response headers that negotiate the type of encryption being used, the exchange of encryption keys, the passing of message digest information, and so on. This is roughly similar to the Basic authentication scheme, except that S-HTTP allows the client and server to exchange cryptographic certificates and encryption keys within the HTTP headers, so that each party can authenticate the other and encrypt data being sent to the other.

S-HTTP and SSL are complementary schemes. SSL has the advantage of encrypting all underlying communication, but the disadvantage that the same encryption is applied to all messages. There is no easy way to change the encryption scheme based, for example, on the personal encryption key of a user (some variation is possible in SSL version 3, however). S-HTTP, on the other hand, allows for this type of flexible encryption, since the keys can be passed in the HTTP headers. With luck, the various vendors will arrive at a compromise that adopts the best features of both approaches.