Access Control and Authentication





One of the most fundamental elements of the World Wide Web security framework is Access Control Methods and Authorisation schemes. All the encryption algorithms are of little use, if a mechanism for utilising them is not put in place. In this section we will examine the existing access control mechanisms and authentication tehcniques, and we will discuss their qualities. We will then examine proposed schemes to improve the security of these techniques.




Access Control Mechanisms

Access control mechanisms in a system are a way of deciding which users have the ability to access which files. On a HTTP server this is accomplished through the use of Access Control Lists (ACL). Each directory on the server contains an ACL file, specifying which users and groups have access to which files. An ACL entry usually consists of a file name, and a list of usernames and IP adresses (optional) which have access to the file. HTTP's approach to verifying a users identity and allowing them access to a file, uses the challenge-response paradigm.


The server challenges the client to authenticate itself. The client authenticates itself using an appropriate authentication mechanism. Once the server is satisfied that the client has authenticated itslef, it checks the appropriate ACL file to see if the user has authorisation to access the requested file. If the user has authorisation, the server sends the file to the client.

This system works fine assuming that the authentication scheme used is satisfactory, and that the user is accesing the machine through HTTP. However if the user happened to bypass the HTTP server, by using ftp to access the machine for example, it would also bypass the ACL file. This would mean that if any file in the directory the user is accessing, is world-readable, the user can access it. So in other words it is possible to bypass this access control mechanism.

Perhaps an improvement on this scheme would be to place the access control information for a particular file in the header of that file, and not use a single ACL file for a whole directory. This would mean that files would store information themselves regarding who is entitled to access them. This should facilitate the upholding of access restrictions, no matter how the user is accessing the machine. However there is a penalty to pay in that if the server administrator wished to change the access authorisations on every file in a directory, this would mean accessing every file in that directory instead of changing just one ACL file.


Authentication Schemes

Access control mechanisms can tell us if a particular user is entitled to access a file, but how do we know that a user is who he says he is, and equally how does the user know that the server is really the server that he thinks it is? This is the goal of WWW authentication schemes, is to authenticate the client to the server and vise-versa. In this section we will look at message based authentication schemes. These schemes operate sending signed and/or encrypted messages across the network, the "security smarts" are in the application layer.

We will first look at the authentication scheme which is currently being used, the Basic Authentication Scheme and we discuss its qualities. We will then look at the Digest Authentication scheme, which is a proposed inclusion in the forthcoming HTTP/1.1 specification. Finally we will briefly look at some other alternatives to these schemes.



Basic Authentication Scheme

The Basic Authentication scheme is an authentication scheme based on username/password pairs. Files on the server contain lists of user/password. Password files are stored in encrypted form. This system is the scheme being used in the current version of HTTP, and so is the system being used for client authentication on the World Wide Web.


1.Server sends an unauthorized status.

Once a server receives a request without an Authorisation field to access a document that is protected, it sends an Unauthorised 401 status code, and a set of WWW-Authenticate fields specifying the realm. The realm is a used password file for different trees of documents. Thus the client can figure out which password to use at any given time.


2. Client authenticates himself

The browser prompts for user name and password, constructs a string - username:password, and encodes it into printable characters. This is then sent with the next request in the Authorization field.


3. Server checks authentication and authorisation



The Basic Authentication scheme has many good qualities. It is a simple scheme to understand and to implement and this is probably why it was adopted in the current version of HTTP. The server administrator has full control. The password file is encyrpted on the server, so if attackers gained access to files on the server, they would not be able to find out users' passwords.

However the scheme has many failings, and under examination does not prove to be very secure. The biggest fault being that passwords are sent "in the clear" accross the network. This leaves the system open to network "snoopers". If an attacker was to intercept the correct packet, he/she cold easily decode the user's username/password pair. This would mean that this attacker could gain access to this server masquerading as an authorised user. If the server administrator choose the option to include the user's IP address in the ACL file, the attacker would only be able to access the server from this IP address. This is little comfort however, as it is common for users to use the same password for several different servers. This means that this attacker now has the ability to access any services for which the user used this particular password.



The scheme described above is clearly not secure enough to be used as an Authentication scheme for any network. It is a trivial task for a snooper, while wathcing a network, to decode a users username and password. Given that, it is alarming to see that it is the only authentication system in widespread use on the World Wide Web. There is clearly a need for agreement on an improved scheme. Such a scheme is the Message Digest Authentication System.



Message Digest Authentication System


Message Digest Authentication is a propsed extension to HTTP. Before we examine its operation and consider its merits we will first look at the goals of the system:


The key feature of the scheme is that the users password is not sent across the network. The scheme uses one way hashing algorithms to encode the users password. Two algorithms are used for this, one to produce the digest, and the other to produce the checksum.

For example, the string obtained by applying the digest algorithm to the data "data" with secret "secret" is denoted

KD(secret, data)

and the string obtained by applying the checksum algorithm to the data "data" is denoted



Basic Operation

The digest scheme, like the basic scheme, is based on a simple challenge-response paradigm. The diagram above shows the three basic operation steps.

After receiving an unautorised request for an object, the server responds with a challenge. This challenge has a WWW-Authenticate header containing the nonce, an opaque string of data, a string specifying the realm, the domain, a stale flag and a string specifying a pair of algorithms used to produce the digest and checksum.

Both the nonce and the opaque string are server specified strings. The opaque string must be returned by the client unchanged. The value of the nonce which the server uses to the challenge the client is implementation dependant. An example would be H(client-IP:time-stamp:private-key). With a nonce of this form a server would normally recalculate the nonce after receiving the cleint authentication.

A valid response from the client has a Authorization Request header containing the nonce, username, realm, the opaque string and KD(H(username:realm:password), nonce : H(HTTP method : Requested URI)). This digest is calculated on the client, and so the password is not sent "in the clear".

When the server receives this response, it looks up its stored H(username:realm:password) for that particular user. Then the server must perform the same digest operation performed by the client, and compare the result to the given response digest. Note that the server need not know the users cleartext password.

There is an optional digest field that can be used when the client is authenticating itself, or when the server is sending the client the object. This field contains a digest of the object body. This can be useful, as it can insure the integrity of data being put to the server, or the integrity of the served document.



Now that we seen the basic operation of the scheme, we can discuss its qualities.

The scheme is very flexible and to an extent, the level of security is left up to the implementor. This applies in particular to the value chosen to be the nonce. If an implementation chose to have a time-stamped nonce, a clients authorisation information would only be valid for a single request, or a specified period of time. Even when the time period for which a nonce is valid has elapsed there is flexibility in how the server should handle this. For example if a client has made a successful request from a server, it may remember the username, password and nonce values for future requests. When the client makes another request the server may choose to accept the old authorisation information, even though the nonce value may not be fresh. Alternatively the server could return a 401 response with a new nonce value, causing the client to retry the request. By setting the stale flag to true with this response, the server hints to the client that the request should be retried with the new nonce, without reprompting the user for a new username and password. The server knows that the user has the correct username and password, as it was able to read the checksum information in the request.

There is also flexibility in the choice of hasing algorithms to use. The server specifies which algorithms to use when it challenges the client. The default is the MD5 pair of algorithms to produce the digest and checksum.

Flexibility may be regarded as an advantage or a disadvantage of a security system. If the administrator on the server is knowlegeble of this security mechanism, and is aware of exactly what level of security his server needs, flexibility is an advantage. If there is no real need to use for time-stamped nonces, then the system should not use them. However if the system administrator, is not so knowlegeble about the mechanism, his implementation may be either over-secure or not secure enough. This clearly is a problem which could be avoided if there was less flexibility in the scheme.


Digest Authentication does not provide a strong authentication mechanism, and most needs for secure HTTP transactions cannot be met by it. For these needs SHTTP is more appropriate. This scheme cannot be used for any transaction requiring encrypted content. However the goal of the scheme was to make an improvement on the Basic Authentication scheme, and this it does. This is shown by an analysis of some attacks:

1. Replay

For applications where no possibility of replay attack can be tolerated, the server can use one-time response digests which will not be honored for a second use. This requires the overhead of the server remembering which digests have been used until the nonce time-stamp has expired.

2. Man-in-the-Middle

The scheme is vulnerable to attacks from a hostile or compromised proxy. A simple but effective attack would be to replace the digest challenge with a basic challenge to spoof the client into revealing their password. To protect against this, clients should remember if a site has used Digest Authentication in the past, and warn the user if the site stops using it. This is clearly not an ideal situation. Some method of guaranteing that a challenge ot response is not modified is needed.

3. Spoofing by Counterfeit Servers

Digest Authentication is vunerable (like Basic Authentication) to this type of attack. However, it is more difficult with Digest Authentication - but the client must know to demand that Digest Authentication be used. Again this is not an ideal situation. The security of the communications is relying on the client to keep a list of sites using Digest Authentication.

4. Analysis of Messages

It is beleived that the digest scheme is not vulnerable to this. Analysis of the messages cannot be used to reveal either the password or information allowing access security to be defeated.

5. Analysis of password file leading to compromise of password

Not vulnerable. The password file does not store passwords themselves but a site and username specific one way encrypted hash of the password.

6. Compromise of One system leading to Compromise of others

Not vulnerable. The password file is specific to a particular realm.

7. Communication of Access Data

System vulnerability. Security of the system is dependant on the shared secret (key) being communicated between the participants without discovery by a third party. This security scheme does not protect against this vulnerability.


The digest scheme is an improvement over Basic Authentication in all areas except one - Basic Authentication uses an encrypted password file, whereas Digest Authentication does not. Digest Authentication requires that a "password file" contains pairs of username and H(username:realm:password). If this password file was compromised, an attacker gains immediate access to documents on the server using this realm. Including the realm in the digested data sotred in the password file ensures that other digest authentication password files with the same username and password are not compromised. However it does expose them to brute force attack.

The consequences of this are that more rigorous security is needed on the server machine, and that the realm string should be unique among all realms which any single user is likely to use.


There are efficieny worries over the inclusion of the digest option, which would contain the digest of the message or object body. If this digest was placed in the message header, it would mean that the signature must be calculated before a message is sent which may be unsatisfactory for large documents stored as files since the file would have to be read twice. One alternative is to place the digest at the very end of the message which would require only the length of the message to be known in advance, this is not signigicant. However this significantly deviates from the HTTP model of having all the access data in the header.


By modern cryptographics standards, Digest Authentication is weak. However it is a valuable replacement for Basic Authentication as it remedies many of the weaknesses of the Basic system. Its strength may vary on the implementation, in particular the structure of the nonce may affect the ease of mounting a replay attack. There are certain trade-offs between server overhead and the choice of nonce or digest. Some improvements could be made to the scheme, such as employing encryption of messages and replies, however such a system would have to justify its existence as a seperate entity from the public key extensions proposed in S-HTTP.






Kerberos is an Authentication System for Open Network Systems. Some work has been done in using Kerberos in WWW applications. Kerberos has the following features:

Using Kerberos in Web applications allows mutual authenication between Web client and server. The server can use client authentication for access control, and the system allows for the encryption of client request and the server response.

Mediated Digest Authentication


For more information see the MDA internet draft.



CCI-Based Security using PGP

A design has been developed for a Common Client Interface based Security system using Pretty Good Privacy. This design provides both authentication of clients and servers, and confidentiality and integrity of information as it travels across the network. Pretty Good Privacy is used to sign and/or encrypt requests and responses.

A PGP-CCI application is developed as a front end to PGP. This application acts as a link between the Web browser and PGP. The application also acts as a viewer for documents that have been encrypted or signed by PGP. PGP enhanced messages are routed through the CCI application viewer, while non-enhanced messages are handled as normal by the browser.

This facilitated by the creation of a new MIME type for PGP enhanced messages, and registering hte PGP-CCI application as a viewer for this new MIME type.

Hyperlinks pointing to documents to be retrieved using PGP-CCI contain special anchor attributes giving the server's public Key ID, as well as other optional information such as whether the HTTP request should be signed, encrypted, or both.

A request for a hyperlink containing the PGP-CCI-related attributes proceeds as follows:

  1. When the user clicks on such a link, the browser tells the CCI application that the http URL has been requested. The browser also passes to the CCI application the complete HTTP request it would normally send to the server, as well as the anchor attributes for the desired hyperlink.
  2. The CCI application uses PGP to enhance the request, this involves encrypting the request using the servers public key. This key can either be found on the clients key-ring or from the anchor attributes. Before signing or encrypting the request, the CCI application adds a Date header, and a header containing a randomly-generated session key. This protects against a replay attack.
  3. The request is then encapsulated within a generic HTTP request, which is sent to the browser.
  4. The server uses PGP to decrypt and/or verify the signature on the request. PGP checks the configuration files to determine if the request is properly signed and/or encrypted for that URL, and whether or not the autenticated agent is authorised to access the requested document. If the request was not authorized, the server send a "401 : Unauthorized" response with the HTML body containing a link for the requested document (including anchor attributes needed to resubmit the request). If the request was properly authorised, the server's response is processed by PGP, and is then sent to the client. This response could be signed and/or encrypted using the session key contained in the client's request.
  5. If the server's response is a 401, the server's HTML error message will be displayed in the browser. If the server's response was a PGP-enhanced HTTP message, its content-type will cause the full HTTP response to be given to the PGP-CCI application.
  6. The CCI application uses PGP to decrypt and/or verify the signature on the server's response. The plaintext of the response is sent to the browser (by PGP) by means of a temporary local file. The browser processes this response as normal while the PGP_CCI application displays the relevant information to the user, including the server's PGP username and Key.

This design enables the standard web browser to handle security-enhaced mail without any changes to the code.