Abstract

In many web applications, it is compulsory to have a good authentication system. Indeed, at least the administrative part of a web sites need to be very secure.

A web authentication system generally ensures unique login name and password for user, before he is accessing pages. Despite of this common way, there are many possibilities to implement this, each with different advantages and disadvantages. In this paper we try to summarise our conclusions about the strengths and weaknesses of various methods that we have considered in developing the online learning environment eLearn_TS. We take into account three different aspects for each system: how it solves logging in phase, user tracking and logging off.

1. Introduction

In many web applications, it is compulsory to have a good authentication system. Indeed, at least the administrative part of a web sites need to be very secure.

A web authentication system generally ensures unique login name and password for user, before he is accessing pages. Despite of this common way, there are many possibilities to implement this, each with different advantages and disadvantages. In this paper we try to summarise our conclusions about the strengths and weaknesses of various methods that we have considered. We take into account three different aspects for each system: how it solves logging in phase, user tracking and logging off.

The paper starts with a short description of the online learning environment eLearn_TS developed at Timsoft Ltd. Then it presents two common aspects at the level of Web authentication: basic HTTP authentication that is supported by most browsers and HTTP servers, and custom PHP authentication.

Other Web technologies like CGI, JSP, Java or several server-side web development packages (such as Microsoft's Active Server Pages or Allaire's Cold Fusion) provide also a variety of mechanisms for authentication systems implementation. They will be not described here. That is mainly because internally, they all work in much the same way like methods described here.

2. The eLearn_TS Environment

The online learning environment developed by Timsoft LTD is used for delivering online courses and also as collaboration space for online communities.

The main components of the environment and their functions are:

1. Authoring system - An authoring component used by the space administrator in creation and edition of the materials.
2. Registration system -The database with the participants specific information.
3. A content delivery function - The content may be in the form of text, images, sounds, animations. However the basic functionality that can be expected from an online learning environment is the creation of plain text and HTML documents.
4. A navigation model - Syllabus, calendar, class lists, links.
5. Online assessment - Tools for delivering and managing tests.
6. Synchronous tools - The chat-rooms allow the course members to communicate in real time with the facilitator; the environment offers the facility of Live Chat, being visible when the facilitator is online . The transcript of a chat discussion can be published.
7. Asynchronous tools - e-mail and conferences ( web-forums). The conferences constitute the central part of the environment, that assure the interaction between all the members. This leads to the building of the dynamic part of the course, the knowledge shared by the participants.
8. Security system - A component for controlling the access to the virtual environment. It is the subject of this paper.

3. Basic HTTP authentication

The basic HTTP authentication mechanism is defined inside the HTTP protocol standards [1] to which all HTTP-server programs and web browsers are expected to conform.

Essentially all HTTP server daemons and Web browsers support basic authentication. It is thus by far the most widely used authentication method.

Enable of basic authentication consists in changing of configuration of HTTP server daemon in order to let it to know that certain documents require authentication to access. The necessary changes vary with different HTTP servers.

First, all documents to which access is to be restricted are placed in some common directory under your server's document root. In that directory is paled a file named “.htaccess” which contains directives giving at least the following information:

• Authorization Real Name - Some label that identifies which services this authorization is for.
• User Database Name - These describes where the database of valid users and user passwords is stored.
• Restricted Operation - A list of which kinds of HTTP transactions authentication is required for.

Suppose the user attempts to access an HTML page that is stored in (or below) the directory with the “.htaccess” file. The sequence of events defined by the HTTP protocol specification for basic authentication goes like this:

1. The user's browser sends an HTTP request to the server, asking for the page.
2. The HTTP daemon on the server starts up. It notices that the request is for a file in a directory with a “.htaccess” file so it reads the file. It discovers that authentication is required to access files in this directory, and it sees that no authentication was included in the request. It therefore rejects the request with a response that says authentication is required.
3. The user's web browser receives the rejection. It searches its memory to see if it has a login/password combination saved for that authentication realm name on that server. If it does not, it pops up a dialog box, asking the user for a login and password to use for that authentication realm name at that server. If the user supplies them, it stores them in its memory, so it will have them in the future.
4. Now that the browser has a login and password to use for this particular realm at this particular site, it resends the same request that it previously sent in step (1), but this time it includes the login and password.
5. The HTTP daemon on the server starts up again to process the new request, just as in step (2). It again discovers and reads the “.htaccess” file, and again discovers that an authentication is required. But this time, it finds a login and password included in the request.
6. The HTTP server daemon then looks up the login name in its user database, and checks the password that was in the request against the one it has stored in its database. If the account doesn't exist or the passwords don't match, the HTTP server daemon sends a rejection back to the browser.
7. If they do match, the HTTP server daemon may make some further checks (it is possible to permit documents only to some groups of users). If these fail it may still reject the request.
8. If all access tests succeed, and the target is an HTML page, the HTTP server transmits the page. If the target is a CGI program, then it runs the CGI program.

From a security point of view, this is not very satisfactory. It means sending the user's password over the network in clear text for every single page accessed (unless you are running HTTP on top of some secure lower-level protocol like SSL, in which case everything sent and received is encrypted). Thus the user is very vulnerable to any packet sniffers on the net. (In the HTTP 1.1 protocol the login and password are encoded, but only in a trivially decodable manner).

From an efficiency point of view it is also less than impressive. The need to ask twice for every page means that ordinary delays due to net latency are doubled.

The effort required from the HTTP server is also significant. It has to process each request twice, rejecting it once, and then accepting it.

An important problem with basic authentication as currently implemented is that there is no way for a user to log off without exiting the browser.

4. Web authentication with PHP

PHP [2] offers several ways to implement Web authentication. We will discuss here about three of them. The first is using basic HTTP authentication and extend it with additional functionality. The second is using custom login and session variables in order to validate access to a set of Web pages. The last use an existing PHP library phplib [3] - available from SourceForge under LGPL license.

4.1. HTTP authentication with PHP

The HTTP Authentication hooks in PHP are only available when it is running as an Apache module and is hence not available in the CGI version. In an Apache module PHP script, it is possible to use the header() function to send an "Authentication Required" message to the client browser causing it to pop up a Username/Password input window. The “401” header, combined with a "WWW-Authenticate" header, will activate an authentication dialog box.

Once the user has filled in a username and a password, the URL containing the PHP script will be called again with the variables, $PHP_AUTH_USER, $PHP_AUTH_PW and $PHP_AUTH_TYPE set to the user name, password and authentication type respectively.

An example script fragment that would force client authentication on a page would be the following:

<?php
  if (!isset($PHP_AUTH_USER)) {
    header(‘WWW-Authenticate: Basic 
        realm="Private"’);
    header("HTTP/1.0 401 Unauthorized");
    echo "Text to send if user hits Cancel 
        button\n";
    exit;  } 
  else {
    echo "<p>Hello $PHP_AUTH_USER.</p>";
    echo "<p>You entered $PHP_AUTH_PW as 
        your password.</p>";
    }
?>

The code sequence above does not really authenticate a user, since it only checks that a value exists, but not a specific value. However, it is necessary to add an if...else statement in an attempt to validate the user input:

if ( (!isset( $PHP_AUTH_USER )) ||

Instead of using hard-coded values within the script it is possible to use a flat (text) file to authenticate the users. This manner enables an easier management against multiple users:

// Read the entire file into

// the variable $file_contents

$filename = '/path/to/file.txt';

$fp = fopen($filename, 'r');

$file_contents=fread($fp, filesize($filename));

fclose($fp);

$lines = explode ( "\n", $file_contents );

if (($username == "$PHP_AUTH_USER") &&

($password == "$PHP_AUTH_PW"))

{

$auth = true;

// A match is found, meaning the user

// is authenticated. Stop the search.

break;

}

}

A more elaborate way will use a database table to store users information and passwords [4]. To exact a match for both a username and a password, your SQL statement could be:

SELECT * FROM users

WHERE

username='$PHP_AUTH_USER' and

password='$PHP_AUTH_PW'

From the above example, a positive result will be returned when the values for $PHP_AUTH_USER and $PHP_AUTH_PW both match exactly with their username and password field counterparts, as entered in the users table.

4.2. Custom authentication with PHP

Most custom authentication systems (either PHP, CGI, Pearl …) are set up so that if an un-authenticated user tries access a protected information, the user gets re-directed to a page containing a login form. Typically the login form includes a text input box for the user ID, a password input box for the password, and a submit button. The form can include other controls, like switches to select different options. It can be a much prettier and more informative page than the pop-up box used with basic HTTP authentication. A basic login page should include the following code:

<form method="post" action="login.php”>

Username:

<input type="text" name="user"><br>

Password:

<input type="password" name="passwd">

<br><input type="submit" value="Submit">

</form>

The login script could extract information about legal users either “hard-coded”, from a file or from a database. Actual user information will come into the auto generated PHP variables that have the same names like form’s input fields:

global $HTTP_POST_VARS;

if (isset($HTTP_POST_VARS["username"])){

$strName= $HTTP_POST_VARS["username"];

$strPassword=$HTTP_POST_VARS["passwd"] );

$encryPassword=md5($strPassword);

The remaining problem is how to protect several pages with just one authentication. To achieve this goal, the session variables could be used. Sessions are used for sharing variables between different web pages accessed by the same user. That is, somehow server has to know that it's the same user accessing different pages. Thus some way is required to identify the user. PHP provide functions to create sessions and to register global variables:

*) session_start();

// starting session

// session variables must be global

global $strName, $encryPassword;

// registering session variables

session_register("strName");

session_register("encryPassword");

Indeed, all the pages belonging to the same session have now knowledge about current user:

<?

// Same header to start the session and

// use it's variables

*)

// checking if user is not authenticated

if (!isset($strName) ||

$aUserDb[$strName] != $encryPassword) {

// redirecting user to the login page

header("Location:

Using this method a login out sequence is now possible:

<?

// Same header to start the session and

//use it's variables

session_start(); // starting session

// unregistering session variables

session_unregister("strName");

The PHP Library is a toolkit for PHP developers supporting them in the development of Web applications. It provides easy ways to handle sessions, authentication and permissions in PHP applications.

The main features added are: customizing the login screen and the permission level, creating new user, creating an unprotected session page, creating an protected session page and protected functionality.

Using PHPlib, the authentication is done inline, with HTML forms, not with HTTP authentication.

Authentication could be fully customized by extending the PHPLib class “Auth” to implement own auth_* functions.

To use default authentication and provide support for default public users, is necessary to create a subclass of Auth with the nobody flag set. If you set the nobody flag, $auth will not create a login screen to force a user to authenticate, but will authenticate the user silently as nobody. The application must offer a login button or other facility for users with accounts to change from that id to their real user id.

class My_Default_Auth extends Auth {

var $classname = "My_Default_Auth";

var $nobody = true;

}

The page that uses default authentication will call the page management functions:

<?php

// using Default Authentication

page_open(array("sess"=>; "My_Session",

"auth"=>"My_Default_Auth"));

$auth->login_if($again);

if ($auth->auth["uid"] == "nobody") :

?>

<A HREF = "

<?php $sess->

purl('$PHP_SELF?again=yes') ?>">

Relogin</A> to this page.

<?php endif ?>;

4.4. Discussion on PHP authentication

PHP-based authentication isn't like “.htaccess” or server-based authentication. A layer of security is not placed over all the contents of an entire directory. Instead, PHP-based authentication takes place on a page-by-page basis. If you redirect the user to a new page, you should still check for a value for $PHP_AUTH_USER and $PHP_AUTH_PW, to avoid direct-access by rogue visitors to the target redirection page.

Custom authentication has several advantages over HTTP authentication:

• It can be undone: A session can be un-authenticated, the user can "log out".
• It can expire: A session can automatically be un-authenticated after a given idle time.
• It can be personalized: You are not limited to user/password pairs. It could be database based. Authentication is being done against a database of your design, not a htpasswd text file.
• It is per page. You decide on a per-page basis which pages are authenticated and which aren't.
• It is integrated with a permission checking scheme.

We explored in this paper the security problem of user authentication, taking into account three different aspects for each system: how it solves logging in phase, user tracking and logging off.

Our current efforts are concentrated in developing the authentication for a Learning Management System.

6. References

[1] R. Fielding, J. Gettys - “RFC2068 - Hypertext Transfer Protocol HTTP/1.1”, http://www.cis.ohio-state.edu/cs/Services/rfc/rfc-text/rfc2068.txt , Jan 1997

[2] S. Bakken, Al. Aulbach -“PHP manual”, http://www.php.net/, Apr 2002

[3] K. Kohntopp, B. Erdmann, S. Schumann - “Sourceforge phplib documentation. Version 7”, http://www.sanisoft.com/phplib/manual/, January 2002

[4] J. Meloni - “PHP-Based User Authentication”, http://www.zend.com/zend/tut/authentication.php, May 2000

[ Back ]