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

Access Control, User Authentication, and Data Encryption

So far, we have not discussed the control of access to an HTTP server or the encryption of data transmitted between client and server. This section briefly discusses those mechanisms that are currently supported by most Web browsers and/or servers.

For low-level security, most servers can be configured to restrict access to machines in an authorized Internet domain or subdomain. For example, servers can be configured such that only machine domain names (or numeric IP addresses) belonging within a particular domain (e.g., for example, all machines with domain name ending in .middle.earth.edu ) are permitted access. In general, this restriction can be applied on a per directory basis, although some servers can apply restrictions file-by-file. This is not very secure, however, since a clever cracker can spoof (mimic) a domain name and access the data. It is also not very specific, since anyone who can log in on a machine inside the domain can access the restricted material.

Finer, user-specific control is possible via user authentication. The “Basic” user-authentication scheme is part of the HTTP 1.0 protocol, and lets a server restrict access to users who can provide verifiable usernames and passwords. When users request a password-protected file, the browser prompts them for username and password information, which is sent to the server with the request. The server then checks the name and password against a designated password file. However, in the Basic authentication scheme, the username and password are sent over the Internet in an essentially unencrypted format, so that it is easy for anyone sniffing the network traffic to extract the username and password. Thus, the Basic scheme is not secure, unless the underlying data are also encrypted in some way. And, of course, you need some other mechanism for getting the usernames and passwords onto the server in the first place.

A second method, known as digest authentication, has recently been developed and is implemented experimentally by NCSA’s Mosaic browser and the NCSA HTTP server. This is similar to the Basic scheme, but passes usernames and passwords in an encrypted string. This is a significant improvement over Basic authentication, but still requires that a username/password database exist on the server. Although experimental in HTTP 1.0, digest authentication is an integral part of HTTP 1.1.

Secure communication and user authentication requires encryption of the data being sent between client and server. The most common mechanisms employ negotiated encryption. Negotiated encryption means that the server and client exchange information, usually encryption keys, that allows each to send encrypted information that can only be decoded by the other. This requires that both client and server support the same encryption and decryption software and that they both understand the encryption protocol used to send messages between the two.

There are two main encryption schemes currently in use, but as yet no common standard. In addition, all of the encryption algorithms used by these schemes are regulated by U.S. trade and security restrictions (the algorithms are considered “munitions,” with tight export controls), which place severe limits on the quality of encryption software that can be exported outside the United States. This significantly restricts the deployment of highly secure Web-based applications, although the medium grade encryption that can be exported is sufficient in many cases.

Example 19: The “Basic” Authentication Scheme

The Basic authentication scheme is the only user authentication scheme universally available on the World Wide Web. This scheme is not secure, as username and password information are not encrypted when sent from client to server (they are encoded, however, which at least hides them from nonexperts). You should, consequently, not think of this as a secure authentication scheme, unless it is combined with an encryption mechanism such as the Netscape SSL technology (discussed later).

The Basic scheme uses special HTTP request and response header fields. The following example follows a request for a resource that requires user authentication and illustrates how these fields negotiate the request for authentication information.

Step 1: Client Requests the Resource

The client first makes a regular request for the resource (here, an HTML document). A typical request header is shown in Figure 9.11.

Step 2: Server Response—Authentication Required

The response message is shown in Figure 9.12. The server status message

HTTP/1.0 401 Unauthorized

tells the client that the resource was not returned because the resource requires user authentication. In this regard, the server sends the additional header field:

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

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

HTTP/1.0 401 Unauthorized
Date: Thursday, 03-Aug-95 14:38:57 GMT
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html
WWW-Authenticate: Basic realm="[email protected]"
<HEAD><TITLE>Authorization Required</TITLE></HEAD>
<BODY><H1>Authorization Required</H1>
     Browser not authentication-capable or
     authentication failed.
</BODY>

WWW-Authenticate:tells the client which authentication scheme to use (Basic), and also what realm is involved, here realm="[email protected]" (realms are discussed a bit later on). The response message includes a short HTML document that is displayed by a browser if the user chooses not to provide authentication information, or if the browser does not understand WWW-Authenticate headers.

Step 3: Client Requests Resource

The client, upon receipt of a 401 HTTP response header, prompts the user for his or her username and password. The client takes the username and password and forms the string:

username:password

This strings is then uuencoded into a pseudo-encrypted string (I say pseudo-encrypted, because it is trivial to decode). The client then tries, once again, to access the resource, this time passing the encoded username and password information within an Authorization request header field, of the form

Authorization: Basic aWFuOmJvb2J5

where the string aWFuOmJvb2J5 is the encoded username and password. Figure 9.13 shows a typical request header containing this authentication information.