Overview of HTTP Authentication

The HTTP 1.x protocol has a built in mechanism for requiring a valid
username/ password to gain access to web resources. This mechanism is
known as HTTP Authentication and can be initiated by either a CGI
script or by the web server itself.

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.