The overall purpose of this document is to provide the new user with 
a common sense definition and understanding of HTTP authentication at
the HTTP Header Level. 
There are currently 2 modes of authentication built into HTTP 1.1 protocol,
termed 'Basic' and 'Digest' Access Authentication.
Basic Authentication transmits the username:password pair in an unencrypted
form from browser to server and in such should not be used for sensitive 
logins unless operating over an encrypted medium such as SSL [1]. 
Digest Authentication sends the server a one way hash of the username:password
pair calculated with a time sensitive, server supplied salt value. 
Here a couple definitions are in order: 
One way hash:  A mathematical calculation of a string so that no two strings 
can have the same hashed value. The term one way in conjunction 
with this signifies that the original string cannot be recovered 
from the hashed value by calculation and could only be determined 
by brute force comparisons with the hashed values of known strings. 
Salt value: The salt value is an arbitrary string of data generated by the 
server for the client to included in the hash calculation.

The use of a salt value means that every authentication attempt with the same username:password pair will result in a unique
hash and is not vulnerable to replay attacks. 
The Digest Authentication Mechanism was developed to provide a general use,
simple implementation, access control that could be used over unencrypted 
channels. Users should note that it is not as secure as Kerberos or client-side 
private-key authentication mechanisms. It is also important to note that only the
username:pasword is protect by the hashing mechanism and that without the use of 
an encrypting medium such as SSL all retrieved documents will still be visible 
to all parties with access to network traffic. 
With the terminology and background in place we will now move on to stepping through an 
actual Basic Authentication exchange between Client (Web browser) and Server.
1. Client sends standard HTTP request for resource 
GET /download/report.doc HTTP/1.1 
Accept: application/msword, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 
Host: 10.0.0.5:81 
Connection: Keep-Alive 
2. Server reads configuration files and determines that resource falls within a protected directory. 
Server can only allow access to known users. 
3. Server Sends HTTP 401 Authorization Required Response 
HTTP/1.1 401 Authorization Required 
Date: Sat, 20 Oct 2001 19:28:06 GMT 
Server: Apache/1.3.19 (Unix) 
WWW-Authenticate: Basic realm="File Download Authorization" 
Keep-Alive: timeout=15, max=100 
Connection: Keep-Alive 
Transfer-Encoding: chunked 
Content-Type: text/html; charset=iso-8859-1 
[ html error page for browser to show if user hits cancel ] 
3. Browser displays Username/ Password prompt displaying host name and authentication realm.
[image auth.jpg] 
5. Client Resubmits Request with Username/ Password 
GET /download/report.doc HTTP/1.1 
Accept: application/msword, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 
Host: 10.0.0.5:81 
Connection: Keep-Alive 
Authorization: Basic ZnJlZDp0aGF0cyBtZQ== 
6. Server compares client information to its user/password list.

a. username : password is valid:  server sends requested content. 
b. authorization fails:  server resends 401 Authorization Required header 
c. Client hits cancel:  browser shows error message sent along with 401 message. 
From the above dialogue you will notice several special fields have been added to the 
various Http headers. In step 3 when the server sends the the 401 response it includes 
a special field: 
WWW-Authenticate: Basic realm="File Download Authorization" 
The value "Basic" denotes that we are requesting the browser to use Basic Authentication.
The Realm information is an arbitrary string sent to be displayed to the user commonly 
containing a sight message, or feedback. The image in Step 4 shows Internet Explorer's 
HTTP Authorization Dialogue and how it displays the sight and realm data received. [2] 
The user fills in the form and clicks ok. The browser automatically resends the request 
as seen in step 5. Here you will notice a new field has been added to the standard 
http request: 
Authorization: Basic ZnJlZDp0aGF0cyBtZQ== 
This is where the web browser sends the actual authorization information to the server. 
The Authorization field shown is composed of two values. The word Basic denotes that 
the login is being send in accordance with the Basic Authentication method. The block
of data that follows that is the actual login as supplied by the browser. Dont let the 
logins appearance fool you. This is not an encryption routine, but a base 64 transfer 
encoding. 
The plain-text Login can be trivially decoded to its underlying username:password format 
ZnJlZDp0aGF0cyBtZQ==   -> base64Decode() -> "fred:thats me" 
The Implementation of the Digest Authentication is exactly the same as that of the Basic
Authentication process outlined above, the only difference being the number of arguments
supplied to the Browser and the format of the login returned. 
Both Basic and Digest do have respected places in the web developers toolbox, however 
they should not be considered high grade protection for sensitive information 
or access as they do not address network level attacks. Nevertheless many functions 
remain for which Basic and Digest authentication is both useful and appropriate. [3]
Related Documents: 
Configuring Apache to require Authentication:
http://www.apacheweek.com/features/userauth 

Less Technical Description of HTTP Authorization 
http://frontier.userland.com/stories/storyReader$2159
More Technical Description - RFC 2617 HTTP Authentication
http://www.ietf.org/rfc/rfc2617.txt 

Implementing HTTP Authorization from PHP 
http://www.php.net/manual/en/features.http-auth.php 

[1]- Even over SSL Basic Auth may not be wise unless your script specifically determines 
that the request was for https and not http or else logins could easily fall victim 
from an uncarefully (or specifically) written links 
[2]- Users should be cautioned to look at the Sight: entry carefully before submitting any 
login data. As the Realm information is supplied arbitrarily by the remote server 
it could contain any information even claiming to be another sight. 
[3]- For in-depth coverage of limitations, security concerns, and applicable usage of HTTP 
Authentication refer to Section 4 of RFC 2617 ( http://www.ietf.org/rfc/rfc2617.txt )