HTTP Authentication

By astalavista.net

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. [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 )

Source :http://www.governmentsecurity.org/