Community Pick: Many members of our community have endorsed this article.
Editor's Choice: This article has been selected by our editors as an exceptional contribution.

A Better Website Login System, the EE Collaborative Login System

Published:
Preface

This article introduces an authentication and authorization system for a website.  It is understood by the author and the project contributors that there is no such thing as a "one size fits all" system.  That being said, there is a certain set of common functionalities that should be employed in a website authentication and authorization system.

One article can not discuss all aspects of such a system at the level of detail required for every web developer, so this will be one of several articles.

The purpose of this article in to introduce an open source, collaborative project by various Experts-Exchange contributors, in providing a safe, secure, robust and extensible authentication system suitable for many websites.  The Login System is more aptly called an authentication and authorization system as will be discussed in more detail in the following articles.  At the end of this article you will have all you need for a login page.

Only you as a web developer can determine the needs of your website or web application.  For the very impatient developer you can skip to Section "1. Prerequisites"

Introduction

"I need a login page for my website." A very common question here at Experts-Exchange, but not one which is simply answered.  Why? Because a login page alone is insufficient. ΒΆ

Any useful login system will be based on some type of database.  If not directly tied to a network directory service provider such as Active Directory, LDAP/x500, or Novell eDirectory then a back end database is needed.  On the internet a most websites use such a database driven system and not a directory service provider.  The following discusses a complete authentication and authorization system for a website which will use a database and not be integrated with a network directory service provider.

General Considerations

Given that the Login System will be backed by a database, a website owner or developer will have a number of tasks to perform to have a website login.  The user's database will need to be established and passwords assigned.  There will need to be a means of removing or locking user accounts. Users will inevitably forget their userid or password, or will want to ability to change their password, all adding additional administrative overhead.  All of this information must be communicated to the user in a secure manner, and plain email is not secure.  Given a popular site with many users, these functions could consume a large amount of time for the webmaster.

Any popular site, be it a social networking site or just a forum has not just a login page but a "Login System" consisting of many pages with various functions.

Commonly one would find a
Registration page,
Registration Verification page, (more about this later,)
A Cancel Registration page, (optional,)
The Login page,
A Log out page,
A Recover Password page,
A Change Password page,
A Cancel Account page, and
A few others pages to support those listed.

Yet Another Authentication System?  -- Some Background

When you were a child maybe you had a tree house, or a group of friends started a club.  You would agree on a code or special way of acknowledging your membership.  This worked because you had direct contact with the other members of the "club" and could share a secret with little difficulty.

This ability to share a secret became more and more difficult over the years.  Many "secret" code systems were developed by military commanders since ancient times and many times those systems failed or were compromised by the enemy.  A famous example was the breaking of the Enigma code system by Allied forces during World War II.

In the early 70's a group of computer scientists recognized that in the emerging digital world it was going to be even more difficult to keep secrets as there would be no reliable way to share a secret code.  These men, Ron Rivest, Adi Shamir, and Len Adleman pioneered many cryptographic functions we now take for granted.  RC4 and MD5 are two cryptographic algorithms still in use today. (They went on to found RSA security which is their initials)

Two important keys to the success of their works were:
1.  The first (known) method of a cryptographic method using a public and private key such that a person could create a secret message using the private key and a person possessing the public key could decrypt the secret message.  Brute forcing the message was computationally infeasible, and if the public key was published you had non-repudiation.  You could prove the only person who created the message possessed the private key; ergo S/MIME.
2.  More important here, was that they published the method of encryption for all to see.  As a result, many mathematicians and cryptographers had the opportunity to scrutinize the work and discover early on any flaws.
This second part has led to the axiom that no one (short of a highly trained cryptographer or mathematician) should develop their own cryptographic system as it will probably not hold up to public scrutiny.

Given the argument that a just a login page is not sufficient for a web site, and having examined many examples of "Login System" tutorials which exist on the web; those were generally found to have unaddressed, known security flaws, (XSS, CSRF, and SQL injection to name a few).  As a result, a group of expert contributors from Experts Exchange began an open source Web Login Project to provide essentially a plug-and-play solution for web developers.

It was troubling to the experts involved that the same or similar vulnerabilities plague websites, and have done so for many years.  Among other security organizations, the OWASP publishes as Top Ten list of web vulnerabilities, found here: OWASP_Top_Ten_Project.  Just as it is ill-advised for a developer to create their own cryptographic software without being an expert in the field of cryptanalysis and having their work examined by many other experts to ensure it is viable and safe, it is safe to draw a similar parallel, and say that a web-based authentication system should be produced by people with a demonstrated expertise in web development and should have been vetted by many other web developers to ensure the code is robust and correct.  With that in mind, the primary goals of the Web Login Project focused on three areas:
1.   Provide code for a robust and secure Login System which can easily be implemented by web developers of all skill levels,
2.   Provide a means for web developers to chose which functions of the Login System they wish to implement, and
3.   Provide a project home where bugs, security vulnerabilities and feature enhancements may be tracked
.
Of the three, the last one is the most important.  No matter how many people may have been involved in the creation of the code, bugs and security vulnerabilities can be overlooked.  Yet unknown vulnerabilities can be discovered in the future.  Having a project home where these issues can be tracked and corrected is paramount in achieving the goal of providing robust and secure code, and ensuring it continues to remain that way.

As the project was conceptualized, some additional benefits were added to the design. Since the Login System must be flexible enough to be used in nearly any web site, it was designed to:

Be easy to incorporate in an existing website and be styled to take on the correct look and feel of the site (probably via CSS), and
Provide a centralized configuration file which not only reduces the complications of implementing the Login System but which also provides the ability for the Login System to be internationalized by changing text and phrases used in those pages to languages other than US English.
For the impatient, I will save the Login System design details for a follow-up article and get to the point on how you can obtain and implement the Login System on your website or web application.  The initial code is being offered in PHP and ASP and while deemed functional and safe, already has additional enhancements in the works.  Versions in English, French, German, Swedish, Spanish and Vietnamese have been developed and translations to Danish and Hindi are underway.  Versions of the Login System in other web development languages and frameworks are planned as well as having additional languages supported.

The remainder of this article will discuss:
1.  Prerequisites of the website,
2.  How to protect individual pages from unauthorized access,
3.  How to obtain the code for the Login System,
4.  How to set up the necessary back-end database, and
5.  How to implement the pages you wish to include in your website.

1

PrerequisitesIn that the current release is in ASP and PHP code, the website will need to support one of those server-side languages.

The web site will need a database to store user registration and authentication details as well as an optional logging table for auditing purposes. The initial code release supports:
MS Access on a Windows Server,
MS SQL (including an express version, formerly MSDE), or
MySql.
The web server will need a valid SSL certificate.  Without a SSL certificate it is not possible to implement a secure authentication system.  A setting was added the Login System's configuration file which may allow some websites to use a shared SSL certificate, if offered by their hosting provider. This may not work for all ISP implementations of shared SSL, but may make the Login System more accessible to some developers.

It is assumed the web site has the following pages:
The home page
A contact page, (for contacting the webmaster,)
A page to direct unauthorized users, which we will refer to as the "Forbidden" page, and
A form error page (an example is supplied with the Login System code.)

2

How to protect individual pages from unauthorized access.Due to the customizations possible and the ability to translate the Login System into various world languages, constant values are extensively used.  This may appear confusing to some in the following code examples.

All pages to be protected need a small amount of code near the beginning of the page to check that the user is logged on and authorized to see the page.

To protect an ASP page, the page would obviously need the extension of .asp and would contain the following code at the beginning of the page.
<%
                      Option Explicit
                      Session.CodePage=65001
                      Response.Charset="UTF-8"
                      %>
                      <!--#include file="include/loginGlobals.asp"-->
                      <%
                      If NOT Session("login") Then
                          Response.Redirect "http://" & lg_domain & lg_loginPath & lg_loginPage &_
                          "?p=" & Request.ServerVariables("SCRIPT_NAME")
                      End If
                      
                      ' Your page code here
                      %>

Open in new window

To avoid a certain type of potential web vulnerabilities related to character set canonization issues, it is explicitly stated in the server side code which character set will be used.  The above example sets up for UTF-8 which is needed to support various languages.

The Login System's global configuration (and language) file is included as it is needed by the code that follows to determine the domain of the website, the path to the login page and the name of the login page.

The code determines if the users is logged in, and if not, redirects the user to the login page.  The protected (current) page is passed as a parameter so that if the user successfully authenticates he would be redirected back to this page.

If the user is logged in, execution will continue with the code following the login check.

To protect a PHP page it must have a .php extension and include the following code.  As with the ASP example, we are explicitly setting our codepage to UTF-8, are including the Login System's global configuration file, and finally checking to see if the user is logged in.
<%
                      <?PHP
                      setlocale(LC_ALL, 'English_United States.65001');
                      if (!isset($_SESSION)) {
                          session_start();
                      }
                      include "include/loginGlobals.php";
                      
                      if (!$_SESSION["login"]) {
                          header("Location: https://" . lg_domain . lg_loginPath . lg_loginPage ."?p=" . $_SERVER["SCRIPT_NAME"]);
                      }
                      
                      ' Your page code here
                      ?>

Open in new window

3

How to obtain the code for the Login SystemThe official downloads of the latest version of the Login System code and supporting HTML or XHTML markup can be found under the downloads tab at the code project's home on Google Code, at http://code.google.com/p/loginsystem-rd/.

An example MS Access database file is available as are the SQL scripts needed to create either a MS SQL or MySql database.

In addition to listing the project's initial contributors, the implementation page on the Wiki and the Issue Tracking tabs should be consulted for any pertinent details not included in this article.

For example: if a Cold Fusion or .NET version is released, implementation details will most likely appear first on the project's Google Code home before this article is updated.

While the download packages may change in the future, a web developer will need to select for of the following downloads.
1.  ASP or PHP code for the Login System in their choice of language,
2.  The corresponding HTML 4.01 Strict markup templates if their site does not uses XHTML,
3.  A database file or SQL script for creating the necessary database.

4

How to set up the necessary back-end databaseThere are currently three supported database back ends for the Login System.
1.  MS Access (on Windows)
2.  MS SQL Server (2000-2008 on Windows), and
3.  MySql (on any supported OS).
The first is provided as a file.  The web user will need read and write permissions on this file.  To accomplish this without leaving the database available for download requires some knowledge of your web server and folder permissions.  If you are not comfortable in setting the correct permissions, please post a question in the Miscellaneous Web Development or MS Access zones on Experts Exchange.

The MS SQL Server and MySql databases are created by executing the supplied SQL scripts.  If you do not know how to execute these scripts to create the necessary databases please post a question in the Miscellaneous Web Development, MS SQL or MySql zones at Experts Exchange.  Note:  You will want a separate account for the web user on those databases with Select, Update, Insert, and Delete permissions only.  Do not run the Login System under an administrator's account.

5

How to implement the pages you wish to include in your website.It is suggested you add a directory under the web root called "login-system" and add a directory called "include" under the "login-system" directory.  In fact, this is how the Login System files are packaged for delivery.  As packaged, the files in the "login-system" directory are simply meant as examples.  They include the bare minimum information for you to incorporate the Login System into your web pages and are intended to be replaced by your pages (with the necessary modifications to incorporate the Login System.)

The files in the /login-system/include/ directory do all the work and should not be altered.

Implementing the Login System in your web pages simply means you would include certain library files and (X)HTML markup in your pages to obtain the Login System functionality.  It also means you would at a minimum include the META tag for UTF-8 support:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Open in new window

If you look at your website, it is likely that most if not all pages share a common "template" (for lack of a better term).  You likely have a banner, a common navigation menu, and possibly a footer with links to such pages as Copyright, Privacy Policy and Terms of Use.  There may be other shared content on your pages, but there is on each page a "common content area."

An examination of the source code for the page shows (abbreviated) the following general markup structure.  It is important to note the area above the top of the <!DOCTYPE...> declaration and the bolded area where the main content would appear.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
                      <html lang="en">
                      
                      <head>
                      <title>HTML & DOM Tips And Tutorials</title>
                      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
                      </head>
                      
                      <body>
                      <div id="topmenu">...</div>
                      <div id="banner">...</div>
                      <div id="mainmenu">...</div>
                      <div id="middle">
                        <div id="content">
                          <div><a name="main_content">...</div>
                        </div> <!--content-->
                      </div> <!--nav-->
                        <div id="right">...</div>
                      </div> <!--middle-->
                      
                      </body>
                      </html>

Open in new window


To make this a login page using the supplied Login System code would require some code be included in the page at these two locations.  Above the <DOCTYPE...> we plug in the files which enable the login page functionality as well as setting the UTF-8 code page 65001.  In the main content area we plug in the markup for the login form.  That's it!  You have a functional login page, e.g. Plug and Play.
<?PHP
                      setlocale(LC_ALL, 'English_United States.65001');
                      if (!isset($_SESSION)) {
                            session_start();
                      }
                      
                      include "include/generalPurpose.php";
                      include "include/form_token.php";
                      include "include/loginGlobals.php";
                      include "include/database.php";
                      include "include/login.php";
                      ?> 
                      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> 
                      <html lang="en"> 
                      
                      <head> 
                      <title>HTML & DOM Tips And Tutorials</title> 
                      <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
                      </head> 
                      
                      <body> 
                      <div id="topmenu">...</div> 
                      <div id="banner">...</div> 
                      <div id="mainmenu">...</div> 
                      <div id="middle"> 
                        <div id="content"> 
                          <div><a name="main_content"><?PHP include "include/login-markup.php"; ?></div> 
                        </div> <!--content--> 
                      </div> <!--nav--> 
                        <div id="right">...</div> 
                      </div> <!--middle--> 
                      
                      </body> 
                      </html>

Open in new window


At the top of the page, generalPurpose.php, form_token.php, loginGlobals.php, and database.php are library files common to most of the Login System pages.  The login.php page contains the code for the login page to function and the login-markup.php code contains the form.
<!-- XHTML 1.1 Strict --> 
                      <!-- 19 APR 2010 alpha 0.1 --> 
                      <div id="login-system"> 
                      ...the form markup 
                      </div> 

Open in new window


All Login System markup looks similar to the above.  There are two comments with the type of markup and the revision.  The content is contained within division tags with the ID of "login-system." All items in the markup have the necessary IDs or other attachment hooks for CSS styling, allowing the markup to be styled as desired by the web developer implementing the login system.  All pages in the Login System (but one) are the same.  There is code to included above the <!DOCTYPE...> as well as a corresponding markup file to be included in the main content area.  The logout page can be used as delivered as it is only momentarily executed before redirecting to the "logged out" page.

6

Global configurationThe loginGlobals.php page is the configuration file and holds the constants needed on each Login System page. Some important configuration details are:
The domain, set in the constant lg_domain (and lg_domain_secure).  The second constant is primarily intended for persons using a shared SSL certificate which may have a different domain name than the main site's domain.
The webmaster e-mail address, set in lg_webmaster_email and lg_webmaster_email_link.
The path to the Login System files.  Usually you would leave that as "/login-system/" but an advanced user may wish to relocate those files.
The full paths and names of the home page, the contact page, the form_error page and the forbidden page.  These need not, and probably will not, be in the /login-system/ directory.
Database configuration details, (host or path, database catalog, userid and password.) These are in the loginGlobals page for ASP code and in the database.php file for PHP code.
The settings for SSL, debugging, and logging logins.  As delivered, the setting for lg_useSSL, and lg_debug are set to false.  Assuming you have an SSL certificate your would change lg_useSSL to true and leave lg_debug set to false.  lg_debug set to true would reveal very sensitive data not for the public's viewing.  It should only be enabled if your were asked to do so by an expert assisting you with a problem.
Lastly, lg_log_logins is set to true.  This is important so you have an audit trail of activity (as well as the entries in the loginAttempts table.) It is suggested you leave that constant set to true.

7

What is set by the Login System?Assuming a successful login, the session variables "login" is set to true, "userid" is set to the user's userid, and "name" is set to the user's name.

Session("login") or $_SESSION["login"] is what you use to determine on protected pages if the user has already authenticated.

Session("userid") or $_SESSION["userid"] is for displaying content specific for that user.  You would never display the userid on any web page in your site. T hat may allow a malicious user to attempt a brute force attack on that userid. Display the user's name, (Session("name") or $_SESSION["name"]) instead.

If the user selected "Remember Me" from the login form, a permanent cookie called "login" is stored with that user's userid.

If you are using the ASP code, a cookie containing a cryptographic token (hash) is stored as part of an anti-Session Fixation method.

8

Where do I get the code?The Login System home is the Google Code repository located at:
The code releases are under the Downloads tag.  It is strongly suggested you watch the Wiki and Issue tracker for any new developments in the code.

9

Where can I see the code in use?The Login System maintains a web host at http://www.webloginproject.com/ where you will find many demonstration sites.

10

Where do I get help?
For help implementing the Login System or creating the database needed you should post a question at Experts Exchange in Miscellaneous Web Development, PHP or ASP, and/or the appropriate database forum.  (You are allowed three topic areas for your question.)

11

I want to help.We want your help! If you can translate the Login System into another language, implement a version in another web development code, (Cold Fusion, VB.NET, C#.NET, Zend framework), please contact the author.

12

Why should I use this Login System?It was developed by over 16 Experts with an average rank of Genius or above and a combined point total of over 59 million Expert Points.  It is robust, secure and vetted code.  It has been placed in the public domain and will continue to be developed not only by the original experts, but by other experts long after the original experts are gone.

13

What are the key features, design philosophy, and development requirements of the Login System?Read the next article:
The EE Collaborative Login System Part Two - Design Considerations

Contributors:
    rdivilbiss     Project Lead

Alphabetically
    b0lsc0tt
    jason1178
    jkr
    kaushal
    lherrou
    mark_wills
    ModernMatt
    mplungjan
    mwvisa1
    Netminder
    Ray_Paseur
    roonaan
    RQuadling
    stone5150
    sunnycoder
18
6,294 Views

Comments (2)

Top Expert 2005

Author

Commented:
@ericpete:

Maybe you can get younghv to translate to Marine...

Not sure how the shouting would be handled if it were translated to Marine, but we could translate to Palin speak, and all Success messages would become "You betcha."

CERTIFIED EXPERT
Author of the Year 2011
Top Expert 2006

Commented:
What a great demonstration of the capability of the EE Experts.
Thanks to all who helped put this together.
Big "yes" vote above.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.