HTTP basic authentication

Pros and cons of this widely used authentication method.

Whatever kind of Web activity you're running, it may be that you want to allow access to certain portions of that activity to outsiders. So how do you ensure that the access is granted to people who should have it and not to those who shouldn't? One mistake here can be catastrophic, so you want to get it right. This tip, which is excerpted from InformIT, discusses HTTP basic authentication, the most common kind of authentication used...

for such purposes and lists some pluses and minuses. The tip comes from the book Quality Web Systems: Performance, Security, and Usability by Elfriede Dustin, Douglas McDiarmid Jeff Rashka.


HTTP basic authentication is the standard method of access control provided by most major browsers. Basic authentication is supported at the HTTP level by most Web servers and requires little or no development effort to implement. Unfortunately, because HTTP basic authentication does not provide protection of the user ID and password during transmission from the user's computer to the site's Web server, that information may be intercepted by a third party. Such protection usually requires the establishment of a secure HTTP connection, typically through the use of SSL.

HTTP basic authentication is readily identifiable by its use of the access control dialog box. Basic authentication is also compatible with proxy servers and firewalls, so it is preferable to some of the other, platform-specific authentication techniques. When the Web system uses the Microsoft Internet Information Server (IIS) on a Windows NT/2000 platform, user accounts and permissions are integrated with the operating system's user database, allowing management of Web user accounts through the familiar, operating system?provided tools. Most UNIX-based Web servers use a separate user ID and password file, although some are capable of using a Lightweight Directory Access Protocol (LDAP) directory server for authentication.

[Consider] an exchange of packets, or messages, between a browser and a Web server engaging in HTTP basic authentication captured through the use of the Windows 2000 network monitor. Each frame number lists one packet sent from the source host to the destination host during the retrieval of a secured, or private, page. In [the] example to follow, LOCAL is the client machine running the browser, and HOMER is the Web server machine.

In this example, LOCAL, the client computer, is performing a simple retrieval using the HTTP GET method -- the most common way that Web browsers retrieve pages from Web servers. When it receives the request, HOMER, the Web server computer, examines the data in the request. HOMER examines the request, checks for authorization, and responds once it has completed its examination of the data. Following is the message data sent from LOCAL to HOMER in the GET request:

 GET /secured/secure.html HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword Referer: http://Homer/ Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: Homer Connection: Keep-Alive

HOMER is configured to protect the page -- that is, it is not accessible by anonymous users -- so it therefore requires that authentication data be provided by the client computer. HTTP basic authentication enables the client computer to deliver the authentication within the HTTP request, using the authorization field in the request message. In this case, that field is not present in the initial message sent by the LOCAL, as reflected in frame 1, so HOMER returns an error to LOCAL, indicating that the page cannot be delivered without this information. Frames 2?4 represent HOMER's response to LOCAL, conveying error 401.2 -- Unauthorized. The message is spread across three packets, as the maximum transmittable unit (MTU) of the network in this example is 1,500 bytes. HOMER's response includes a nicely formatted error page, so it is quite long (more than 4,000 bytes).

After receiving these three packets, LOCAL knows that it must prompt the user for the user ID and password in order to give HOMER the information it needs and so displays a login dialog box. Once the user enters the user ID and password and clicks OK, the browser will lightly encode them, using a base64 encoding algorithm. The browser then resends the request for the page to the Web server, HOMER, including the encoded user ID and password. Note the term encoded, which is not the same as encrypted. The next example reflects the action of LOCAL in resending the request to the Web server, this time with the encoded user ID and password. The message data sent... is as follows:

 GET /secured/secure.html HTTP 1.1 . . . Authorization: BASIC aG10aGVyZTplbmNvZGVk

HOMER receives this request and validates the user ID and password that the user entered, by decoding the authorization string and attempting to perform a logon with the supplied credentials. In our example, the logon succeeds, and HOMER sends back the requested page, in frame 6. An important thing to note here is that the next time a page is requested from the "secured" directory on HOMER, the browser will automatically include the encoded user ID and password string within the request. This condition remains true until the browser is closed, at which point the encoded user ID and password string is discarded.

As illustrated [the] message data [above], the authorization field is the encoded user ID and password. This field is in plaintext and, as we have seen, can be captured by a third party using a network monitor or any one of a number of other tools.

Once this plaintext is captured, the third party can either decode the user ID and password and attempt to use this information to log on to the system or replay the authorization string to retrieve pages from the server.

This potential situation highlights the primary security issue with HTTP basic authentication: plaintext transmission of user IDs and passwords across the Internet. To protect this information, the only real option is to use SSL or an equivalent secure protocol. Using basic authentication over an unsecured connection is extremely hazardous and allows a third party to possibly intercept the request and decode the user ID and password. Note that it is not sufficient to use SSL only during the initial logon when using HTTP Basic Authentication, since the Authorization string is retransmitted with each request. Therefore, it is necessary to encrypt the entire session with SSL in order to protect the user's credentials.

An SSL-encrypted session would render the captured packets unreadable by a third party. For example, if the same sequence of frames were exchanged over an SSL connection, frame 5 would look something like the following string of text:

 ________?____h&|3⁄4e˙ Eo?H@ qA˘ R"Px_Y_}y'Q{||.N_Z:0%_?_ {_?]R?P]yl/??@e˙ 9j {z2ee˘ $_˘N

If a third party captures that string of text, considerable time would be needed to decrypt the character string into something meaningful.


To read this entire tip, click over to InformIT. You have to register there, but the registration is free.


This was first published in February 2002

Dig deeper on Windows File Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close