Authentication and session management with HTTP

Date : March 10, 2010

The HTTP protocol, which relies on TCP, is a client/server protocol in which requests are processed independently of each other. It is a stateless protocol.

This limitation is problematic for certain web applications which may need:

  • to recognize requests from the same user,
  • to associate a profile to a user,
  • to take into account the history of queries during their processing,
  • …

Applications with such needs generally bypass this limit by using techniques allowing authentication and session tracking.

The aim of this paper is to present the authentication and session tracking techniques the most frequently used with HTTP.
Next month a new article will cover the developments that browsers or the HTTP protocol use to improve the session tracking.

 

HTTP authentications
 

While the RFC 2616, which specifies the HTTP protocol, lays the foundation for a stateless protocol, RFC 2617 specifies two authentication methods.

These methods in which authentication identifiers are transmitted from client to server via HTTP headers are:

  • the HTTP Basic authentication
  • the HTTP Digest authentication


We will briefly introduce these two methods.
 

The HTTP Basic authentication

 
This method is the simplest and least secure. It is strongly recommended to use it only with an HTTPS connection, and furthermore with both client-side and server-side certificate verifications.

The client handles authenticated session by sending the name and password of the user (base64 encoded) in every request sent to the server.

 Notes:

  • This authentication method is particularly sensitive to traffic sniffing.
    Indeed, an attacker which can get the base64 representation of its victim’s identifiers, can then use it to connect to the server and spoof its victim identity.
  • To avoid having to ask the name and password to the user each time a request is sent, browsers put this information in cache.

 

The HTTP Digest authentication


This method implements a "challenge-response" mechanism in which the server and the client share a secret.

For each query, the server sends a challenge to the client, which returns a value computed with the challenge and the shared secret.

The server does the same operation and compares the two results to ensure it is in communication with the legitim client.

 
This mechanism has the advantage:

  • to prevent the replay of queries, which could be sniffed on the network by a malicious person as for each request, the challenge changes on every request,
  • to protect the users from malicious or compromised servers, by not providing identifiers to such servers.

 
Note:

  • As in the case of HTTP Basic authentication, in order not to query the user name and password on each request, the browser caches this information.

 

Session management through cookies

 

This is probably the most widely used techniques for managing user sessions in web applications.

As a reminder, a cookie is a character string appearing in the headers of HTTP requests and responses, used to retain information when accessing different pages of a website or when a user returns later on this website.
This information can be stored by the client either in memory (session cookies) or on a disk (persistent cookies).
The cookie mechanism is defined in RFC 2965, "HTTP State Management Mechanism”.

Persistent cookies are frequently used by commercial websites to store customer preferences and habits. But another common use of cookies is the session management.
 

A session generally begins with the following authentication process:

  • the user enters his credentials (login name / password) in an HTML form,
  • this IDs are sent to the server that controls them,
  • if these identifiers are valid the server sets a cookie to track the session,
  • this cookie will be exchanged and checked between the client and the server throughout the session,
  • when the user logs out or when the session expires, the server sends an empty session cookie to the browser of the user.


Notes:

  • The data related to the session are stored on the server and the cookie value is used as an index.
  • The value of the cookie is usually a random value.

 

For more information:
 

Previous Previous Next Next Print Print

© 2024 Cert-IST