No matter how securely you code your site, someone with a valid password can access that which you mean to keep private. The best solution is, of course, to keep any and all pages that require the input of a password protected using an SSL certificate. In reality, not all sites can afford the luxury of their own SSL certificate. Another, entirely free, method of keeping passwords from being transmitted across the web in clear text is to use a challenge-response system for logins.

The basic idea behind a challenge-response system is that the page requesting a password will have some extra information embedded in it – information that is unique to that particular login attempt – which is used to encode the password before it is sent across the network. In this tutorial, we’ll see how to generate this extra information, called the salt and how to incorporate it into a secure hash using SHA1

The work upfront

First of all, we’ll take a look at things on the client end of things. We will need a javascript implementation of the SHA1 algorithm. I found one as done by a guy named Chris Vaness. I am not sure where I found it, but I did maintain his copyright as requested. Grab it for your own use here: sha1.js. For CakePHP, place this file in the app/webroot/js directory. All you really need to know about this file is that it defines a function sha1Hash that takes one argument – the string to hash – and returns the hashed value.

Now we need a form for logging in to a site. The html code for a simple login is shown in snippet #1.

Snippet #1: HTML code for our simplified login.

<p class="error_message">The login credentials you supplied could not be recognized. Please try again.</p>
 
<form method="post" action="/admin/login">
    <label class="label" for="username">Username:</label>
    <?php input('User/username', array('size' => 20, 'class' => 'TextField', 'id'=>'username')); ?>
    <?php tagErrorMsg('User/username', 'Username is required.')?>
    <label class="label" for="password">Password:</label>    
    <?php password('User/password', array('size' => 20, 'class' => 'TextField', 'id'=>'password')); ?>
    <?php tagErrorMsg('User/password', 'Password is required.')?>
    <?php submit('Login', array('class'=>'Button'));?>
</form>

Of course, the code in Snippet #1 is just the login bits of the page, you’ll want to embed that in a full page (and hopefully pretty it up with some CSS) for production use. In our controller, we’ll need to generate the salt to embed in the page. Code for doing this is shown in Snippet #2.

Snippet #2: Adding the salt in the controller.

function login()
{
    if(!empty($this->data))
    {
         //handle the login - we'll get to this later
    }
    else
    {
        //create the salt by creating an MD5 Hash of the current time
        $salt = md5(time());
        //make the salt available to the view
        $this->set('special_sauce',$salt);
        //store the salt in the session
        $this->Session->write('salt', $salt);
    }
}

As you can see, generating the salt and making it available in a variable which we can access in the view is really a trivial matter. A couple of points bear explanation. First of all, why am I using MD5 here when using SHA1 for the hashing itself? Well, this particular use of a hash is simply to generate a random assortment of characters to use as salt, therefore we can use the less secure MD5 algorithm which will run a little faster than SHA1. It really makes no difference, and is more a matter of preference than anything else. For the actual hashes, however, you should use SHA1 as it is more secure. Secondly, you may wonder why I am saving the salt in the session when I have made it available to the view (yes, I am going to be placing it in a hidden form element). The reason for this is to ensure that we use the salt generated here when we do our comparisons later on. If we were to place it in the form element and use that return to check the stored password, an attacker could simply supply the salt he wanted to use in that form element and he could bypass our security. This way, we are protected against clever people like that.

With our form defined and our salt available we need to write some javascript to process the user input before sending it to the server. Specifically, we are going to take the entered password, run the SHA1 algorithm on it, concatenate the resulting hash with the salt and run the algorithm on it again. Following that process we write our new password value into the password field and let the form submit. Javascript to accomplish this is shown in Snippet #3.

Snippet #3: Javascript transform_login function

function transform_login()
{
  var password = document.getElementById('password').value;
  var salt = document.getElementById('special_sauce').value;
 
  var hashed_pass = sha1Hash(password);
  var hashed_and_salted_pass = hashed_pass + salt;
  var salted_hash_pass_hash = sha1Hash(hashed_and_salted_pass);
 
  document.getElementById('password').value = salted_hash_pass_hash;
 
}

This new javascript function requires that we make some changes to our login code, as shown in Snippet #4.

Snippet #4: Modfied login form.

<script src="/js/sha1.js" language="javascript"></script>
<script src="/js/login.js" language="javascript"></script>
<?php if ($error): ?>
    <p class="error_message">The login credentials you supplied could not be recognized. Please try again.</p>
<?php endif; ?>
<form action="/admin/login" method="post")>
        <label for="username" class="label">Username:</label>
        <?php echo $html->input('User/username', array('size' => 20, 'class' => 'TextField', 'id'=>'username')); ?>
        <?php echo $html->tagErrorMsg('User/username', 'Username is required.')?>
        <label for="password" class="label">Password:</label>
        <?php echo $html->password('User/password', array('size' => 20, 'class' => 'TextField', 'id'=>"password")); ?>
        <?php echo $html->tagErrorMsg('User/password', 'Password is required.')?>
        <?php echo $html->submit("Login", array('class'=>'Button', 'onclick'=>"Javascript:return transform_login();")); ?>
        <input type="hidden" name="special_sauce" id="special_sauce" value='<?php echo $special_sauce; ?>'>
</form>
<?php if ($error): ?>
    <script language="javascript">
        document.getElementById('password').value = "";
        document.getElementById('username').value = "";
    </script>
<?php endif; ?>

As you can see, we have added code to include the sha1.js and login.js files which contain our sha1 functions and login function transform_login. We have also inserted our hidden value with the salt in it, called special_sauce here. Finally, we have added an onclick to the submit button to call the javascript function and transform our password. This should be everything we need on the client end of things.

The login process in the controller

Earlier, in Snippet #2, we passed over the code in the controller that actually handles the processing of the login. Now it is time to revisit the controller and finish off our secure login. The goal here is to replicate the actions taken in the javascript function transform_login and compare the results of the server-side transform and that done on the client end.

Since we embedded the salt in the login form using a hidden form value, that value will be available to us here in the controller. We never want to use that value, however, because we can never be sure of the source of any information coming to us from a web form. It is very easy to construct a duplicate form which submits faulty information in an attempt to gain access to a secured system. What we will do is take the password from the user’s database record and the salt stored in the session and put that information through the same transformations as we did on the client side. If the values match then we know the user entered the right password and can be granted access. Snippet #5 contains the full code of the final controller method.

Snippet #5: Completed controller login code.

function login()
{
     // If a has submitted form data:
     if (!empty($this->data))
     {
         $someone = $this->User->findByUsername($this->params['data']['User']['username']);
 
         //the password from the database           
         $password = $someone['User']['password'];
         //the salt value from the session
         $salt = $this->Session->read('salt');
         //hash the password
         $hashed_password = sha1($password);
         //add the salt to the hashed password
         $salted_and_hashed_password = $hashed_password . $salt;
         //salt the salted and hashed password
         $salted_hash_pass_hash = sha1($salted_and_hashed_password);
 
         //do our comparison
         if($salted_hash_pass_hash == $this->params['data']['User']['password'])
         {
              // This means they were the same. We can now build some basic
              // session information to remember this user as 'logged-in'.
              $this->Session->write('User', $someone['User']);
 
              // Now that we have them stored in a session, forward them on
              // to a landing page for the application.
              $this->redirect('/logged_in/');
         }
         // Else, they supplied incorrect data:
         else
         {
             //Remember the $error var in the view? Let's set that to true:
             $this->set('error', true);
         }
     }
     else
     {
         $salt = md5(time());
         $this->set('special_sauce',$salt);
         $this->Session->write('salt', $salt);
     }
}

Summary and Caveats

That’s really all there is to securing your logins with a challenge-response system. Of course, if you have an SSL certificate available to you, using it would be in your best interests. There is, however, nothing stopping you from using both at the same time. You can never have too much security.

A few words of warning, however. This is not intended to be a complete solution for your login needs. There are several aspects of a login system that have been overlooked in the name of brevity. Not the least of these are validating required fields and protecting all input fields from SQL Injection vulnerablilities. This only provides you with the means of obscuring password data in transit over public networks. I recommend that you do your research up front on a complete solution to prevent getting burned by something simple you may have overlooked.

An Example Scenario

To best illustrate this method we will need an example scenario to work with. As I mentioned in my blog entry on Single Table Inheritance, it is particularly helpful when creating a site like Digg. For our example, let’s consider building a site called Excavate. Our requirements are rather simple: a site for people to input links with descriptions. Once a link has been entered it will be considered an "upcoming" entry. Once enough members (only people who have signed up can view and excavate upcoming items) excavate an item it gets green-lighted and becomes a "current" entry. We will store both types of entry in one database table.

The Database Bits

The basic information we need for both kinds of entry is the same: a title, a description, a url, an author name, an author email address, and a created date. A current posting will also require the date which it was green-lighted to order the postings chronologically. To these required fields we will be adding a type field which will hold a reference to which object the record references, upcoming or current. Snippet 1 shows the SQL code for creating our table in MySQL.

Snippet #1: SQL Code for our entries table.

CREATE TABLE `entries` ( 
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `title` varchar(255) NOT NULL, 
    `description` text NOT NULL, 
    `url` var char(255) NOT NULL,
    `author_name` varchar(255) NOT NULL,
    `author_email` varchar(255) NOT NULL,
    `created` datetime DEFAULT NULL,
    `greenlit` datetime DEFAULT NULL,
    `type` varchar(255) NOT NULL DEFAULT 'BlogEntry',
    PRIMARY KEY  (`id`), )
    ENGINE=MyISAM DEFAULT CHARSET=latin1;

There are a few things to check with your database code to ensure that everything will function smoothly. First of all, ensure that your `created` field is called created. CakePHP will automagically handle setting this value for you when you are saving your model. Secondly, ensure that you do not set any model-specific fields to NOT NULL. If, for example, we had set the `greenlit` field to be NOT NULL we would run into troubles when saving an upcoming object, as that object has not been greenlit yet.

The Models

Now that we have the database table in place to hold our data it is time to write the Model classes for our two objects. We will need to add several variable to the models and override several methods from the parent class AppModel. Let’s start by looking at the Current model.

Snippet #2: Class definition and variables
for the Current Model.

class Current extends AppModel
{
    var $name = 'Current';
 
    //single table inheritance vars
    var $__table = 'entries';
    var $__fields = array('Current.id', 'Current.title','Current.description', 
'Current.author_name','Current.author_email','Current.created',
'Current.greenlit');
    var $__type_field = 'type';

The first variable we need to define is $name. This is required in CakePHP if you are using PHP4 but not in PHP5. Nevertheless, we will be using it as it will make many things we are going to do much easier. Ensure that the value of this variable matches exactly the name of your class. The next variable $__table contains the name of the database table in which we are storing our objects. $__fields is an array containing a list of the fields that belong to this model. Note that each field is prefixed with the name of the class it belongs to – even though the name of the table is not Current this will work because the queries created by CakePHP will have FROM `entries` AS `Current` to make everything play nicely. Also of note is the fact that we are not specifying that the type field is a part of the model – this is because it is not. The type field determines which model a record is but we will be handling that automatically and so do not need to manipulate the field directly. Finally, we place the name of the field in which we are storing our type into the variable $__type_field.

With the above variables in place, we can turn our attention to the methods we need to override. Any methods which involve reading or writing records need to be modified to take our changes into account. For my particular needs, I have found that I needed to override __construct, findAll, findCount, findAllThreaded and save. __construct is modified to supply the tablename to the __construct method of AppModel and, as such, is the simplest modification we will be making. The modifications to the save method are a little more significant by equally easy to accomplish. All that needs doing is to add a reference to the type field and its value to the $data variable before passing it to the parent.

The data retrieval methods findAll, findCount and findAllThreaded require a little more work than the fields detailed above. There are two things that need to be done here: modify the conditions to include a reference to the value of the type field and check for the fields being queried. The latter requires a little more explanation. Since we are storing the information for both objects in one table there are certain fields which belong to one model but not to the other. We need to make sure that we are only grabbing the fields that belong to the model in question. In our example, we need to check that we are not querying the greenlit field if we are querying for an Upcoming model. If the fields are not being queried specifically and $fields is null, then we will substitute our $__fields array for $fields to only return that which belongs to this model. Snippet #3 contains the completed code for our Current model.

Snippet #3: Complete definition for the Current Model.

class Current extends AppModel
{
     var $name = 'Current';
 
     //single table inheritance vars
    var $__table = 'entries';
    var $__fields = array('Current.id', 'Current.title', 'Current.description', 'Current.author_name', 'Current.author_email', 'Current.created', 'Current.greenlit');
    var $__type_field = 'type';
 
    function __construct($id = false,$ignore_table = null, $ds = null)
    {
        $table = $this->__table;
        parent::__construct($id,$table,$ds);
    }
 
    function findAll($conditions = null, $fields = null, $order = null, $limit = null, $page = 1, $recursive = null)
    {
        if($conditions == null)
        {
            $conditions = $this->name. "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
 
        if($fields == null)
        {
            $fields = $this->__fields;
        }
        else
        {
            foreach($fields AS $field)
            {
                if(!array_search($field,$this->__fields))
                {
                    throw new Exception("Field " . $field . " does not exist in Model " . $this->name);
                }
            }
         }
 
         return parent::findAll($conditions, $fields, $order, $limit, $page, $recursive);
    }
 
    function findCount($conditions = null, $recursive = 0)
    {
        if($conditions == null)
        {
            $conditions = $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        return parent::findCount($conditions, $recursive);
     }
 
    function findAllThreaded($conditions = null, $fields = null, $sort = null)
    {
        if($conditions == null)
        {
            $conditions = $this->__table . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        if($fields == null)
        {
            $fields = $this->__fields;
        }
        else
        {
            foreach($fields AS $field)
            {
                if(!array_search($field,$this->__fields))
                {
                    throw new Exception("Field " . $field . " does not exist in Model " . $this->name);
                }
            }
        }
        return parent::findAllThreaded($conditions, $fields, $sort);
    }
 
    function save($data = null, $validate = true, $fieldList = array())
    {
        $data[$this->name][$this->__type_field] = $this->name;
        return parent::save($data, $validate, $fieldList);
    }
}

Snippet #4 contains the complete code for our Upcoming Model. Notice that it does not reference the greenlit field whereas the Current Model did.

Snippet #4: Complete definition for the Upcoming Model.

class Upcoming extends AppModel
{
    var $name = 'Upcoming';
 
    //single table inheritance vars
    var $__table = 'entries';
    var $__fields = array('Upcoming.id', 'Upcoming.title','Upcoming.description', 'Upcoming.author_name','Upcoming.author_email', 'Upcoming.created');
    var $__type_field = 'type';
 
    function __construct($id = false,$ignore_table = null,$ds = null)
    {
        $table = $this->__table;
        parent::__construct($id,$table,$ds);
    }
 
    function findAll($conditions = null, $fields = null, $order = null, $limit = null, $page = 1, $recursive = null)
    {
        if($conditions == null)
        {
            $conditions = $this->name. "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
 
        if($fields == null)
        {
            $fields = $this->__fields;
        }
        else
        {
            foreach($fields AS $field)
            {
                if(!array_search($field,$this->__fields))
                {
                    throw new Exception("Field " . $field . " does not exist in Model " . $this->name);
                }
            }
        }
 
        return parent::findAll($conditions, $fields, $order, $limit, $page, $recursive);
    }
 
    function findCount($conditions = null, $recursive = 0)
    {
        if($conditions == null)
        {
            $conditions = $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        return parent::findCount($conditions, $recursive);
    }
 
    function findAllThreaded($conditions = null, $fields = null, $sort = null)
    {
        if($conditions == null)
        {
            $conditions = $this->__table . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        else
        {
            $conditions = $conditions . " AND " . $this->name . "." . $this->__type_field . " = '" . $this->name . "'";
        }
        if($fields == null)
        {
            $fields = $this->__fields;
        }
        else
        {
            foreach($fields AS $field)
            {
                if(!array_search($field,$this->__fields))
                {
                    throw new Exception("Field " . $field . " does not exist in Model " . $this->name);
                }
            }
        }
        return parent::findAllThreaded($conditions, $fields, $sort);
    }    
 
    function save($data = null, $validate = true, $fieldList = array())
    {
        $data[$this->name][$this->__type_field] = $this->name;
        return parent::save($data, $validate, $fieldList);
    }
}

As you can see, aside from the values of the variables at the top, these two models are nearly identical for our simple example. In a real system you would likely add other methods to your models to handle more than just the simplest of situations. An example here would be for the green-lighting process. A method in the Upcoming model which sets the value of the greenlit field and changes the type field to ‘Current’ would effectively change the model of the record and have it show up where needed. I’ll leave that code as an exercise.

Given the fact that the modified methods are the same in both models, this method lends itself to scaffolding quite easily. One of these days I am going to look into modifying / extending the CakePHP script bake.php to allow for scaffolding Single Table Inheritance models. If someone has a chance to do this before I do, please drop me a line!

Controllers and Views

With the database table and Model classes taken care of it is time to look at the Controllers and Views. What needs to be done specially to handle the Single Table Inheritance? Nothing! This is the realy beauty of a setup like this, you make your changes at the Database and Model levels but your controllers and views are handled like they are for any other models. As far as you are concerned when writing the controllers and views, there are two database tables – one for Upcoming and one for Current – and you can handle them as you would normally.

Caveats

As I mentioned at the beginning of this, not every scenario will be covered by this method. Depending on your needs you may need to override more or less methods from AppModel. I am currently using this on two projects in addition to on this site. If anyone else manages to get some use out of it or if you have any questions/comments/error reports, please feel free to leave a comment below.

Implementing Single Table Inheritance In CakePHP

Secure Logins With Challenge-Response

The entire story could have been told in half of a movie but it was stretched to a whole one. If you’ve heard that this movie has much more gore than the previous two, you have not been misled. I am all for gore in a horror movie, but in tis one it felt unnecessarily tacked on. Long portions of the movie between gory scenes were just too drawn out. One example is the story of the character named Jeff. The movie leaves his story to tell other aspects and it feels like an eternity before the focus returns to him. As such, there is very little to make me care about him or his situation. The first two movies did a much better job of telling different stories or different angles on stories without making any of those stories suffer. In the third, however, the movie as a whole suffers.

I recommend this movie if you are a fan of horror flicks. Just don’t expect anything as good as the previous two.

With all that has been going on I found myself getting very angry very easily, all of the time. Stress has a way of doing that to a person. Since that realisation, I have been working on learning to be more Zen. Reading a few books on the subject has helped a great deal. My stress levels have become more manageable and I can actually start considering taking on some more again.

Additionally, a few things are changing which could very well indicate that this is a good time in my life to initiate changes. I just sold my car and placed a deposit on a new Dodge Caliber. The Passat was a great car but we are finding an increasing need for more space. the Caliber has the dual benefit of lots of storage space and of being a very cool car. Also, when Lindsay and I were getting married I said I wanted two good years of marital bliss before we even consider the idea of having kids. Well, 2 years is coming up in July and I am not happy with where I am. I want to be in good shape and healthy before we have kids because making drastic changes to my health and routine after that will be impossible – well, making drastic changes will likely be par for the course but making conscious drastic changes will probably be more difficult.

Another change is my friend Ralph got himself a new job. With that he’ll be leaving Cover-All and he’s looking to make some changes in his life too. Such changes on my part will no doubt be a little easier if I know someone going through similar changes at the same time – especially if we can turn it all into some kind of competition

So, what does this mean for my blog? Well, I should be making more frequent entries. There should also be more entries about my life and such with perhaps less tech/geek entries. Maybe less geek, not likely but possible. I am also going to abandon development on this blogging engine. It was a great project for learning CakePHP but such development these days takes away from the time I have to create content. Look for this site to become powered by WordPress in the near future. I will still keep a copy of this codebase on my development machine so I will continue to write tutorials for CakePHP and anything esle I can think of. Such development will not be readily apparent on this site in the future, however, unless I start writing WordPress plugins.

Wish me luck as I start down this new road. It is said that even the longest journey starts with a single step and for me, on this site, that first step is this post.

The first of these isn’t really a site. Well, it is but that isn’t the important part of it. This morning I noticed that all of a sudden 30% of the traffic I received over the past week was attributed to a site called stumbleupon.com. This happened overnight. Last night going to bed the major contributer to my traffic was groups.google.com at about 21% of total traffic. Then this morning a site I had never heard of rocketed to 30%. I had to check this site out.

What StumbleUpon turned out to be is the homepage for a browser plug-in. Think of it as digg for every single page you browse to. You can register your vote, either thumbs-up or thumbs-down on any page. You can also click the Stumble button in the SU toolbar and be taken to a random page that matches your interests (you choose some categories of interest when initially configuring the toolbar). So far, the choices have been quite accurate. The very first page I stumbled to was killer. It has to be the best music site I have ever visited.

By far I have found the best way to learn of new bands that appeal to me is talking to friends. I mention a band I like, they say they like them too and, hey, have you ever heard these guys? Pandora Internet Radio has harnessed this power in a website. You go there, enter the name of a band you like and an Internet radio station is configured for you full of bands that are similar in nature to the one you already like. The first band I tried was Orson, my current favourite, but alas, they are still only big in Britain and weren’t found in the db. Next I tried Brand New, another favourite of mine. I have been listening to songs for the past half hour inspired by my like of Brand New and I have yet to hear a bad one. This works seriously well. Try it out, you won’t be disappointed!

Single Table Inheritance is a method of using one database table to hold the information of multiple objects. For example, if you had tutorials and blog entries that had basically the same fields and were going to be treated in basically the same manner, you could store them all in one table and use Single Table Inheritance to have them treated differently in your application. This is, in fact, what I have done with this site. (see my tutorial Implementing Single Table Inheritance in CakePHP for information on how to accomplish this with CakePHP).

You may be wondering why we would want to bother with this when it is just as easy to create two tables and scaffold them seperately. In this case, yes, you are correct. Let’s take a look at another example which might shed some more light on the power of Single Table Inheritance. Let’s take a look at a site like Digg. With this site there are two types of entry that can be viewed: those on the front page and those that are “Upcoming”. They are identical except for the fact that one has been given the “green-light” (in the case of Digg, an algorithm determines this based on popularity and time and any number of other factors) and the other has not. If we were creating a site like this using Ruby on Rails or CakePHP without Single Table Inheritance, we would have two almost identical tables and the process of “green-lighting” would involve deleting a post from one table (upcoming) and inserting it into another (current).

With Single Table Inheritance, however, we can have everything in one table with an added field which specifies the type of object we are dealing with: Upcoming or Current. In this setup, “green-lighting” is as simple as changing the type field on the record. So, with Single Table Inheritance we get the benefit of having everything in one table and the benefits of being able to programmatically treat each as a different object. We can have entirely different methods of displaying, adding, editing or deleting the two even though they are held in the same table.