A Case Study |
Abstract
1. Introduction 2. The eLearnTS Environment 3. Basic HTTP authentication 4. Web authentication with PHP 5. Conclusions 6. References 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 eLearnTS. We take into account three different aspects for each system: how it solves logging in phase, user tracking and logging off. 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 eLearnTS 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. 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:
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:
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:
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>"; } ?>In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page. In this case, the $REMOTE_USER variable can be used to identify the externally authenticated user. 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 )) || ($PHP_AUTH_USER != 'an_user') || ($PHP_AUTH_PW != 'a_password') ) 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 ); // a password pair and attempt to match them to // $PHP_AUTH_USER and $PHP_AUTH_PW. $auth = false; foreach ( $lines as $line ) { 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: exit; } 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"); ?> You have successfully logged out.<br> <a href="login.php">Login page</a>
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:
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. [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 ] |