CodeBolt

We all know that storing passwords in plain text in a database (or any other data-store) is an absolute no no. Now in my time I’ve seen some quite silly stuff one that comes to mind is a developer who has ‘refactored’ his (or hers) application from using the dreaded plain text pass words to use an MD5 hash. The auth query went something along the lines of :-

SELECT *
FROM Users
WHERE Username = :username
AND (	Password = :password OR
	Password = :hashedPassword)

The problem with the query above is the OR in the Password check the fact that the plain text passwords still works means that if some unauthorized person was to gain access to the database they would still be able to log in to the application using the hash in the password field. Obviously this is not a good thing.

An alternative way to do this would have been to migrate the data at the time that the code was deployed using a migration script (sometimes called a database patch).

Now for the next issue when the developer chose to hash the passwords they chose to do so with an unsalted md5 hash. Many years go (around 5 to 10) when computing power was not as readily available as it is today, md5 was a very fash “1 way” hashing algorithm. I put the one was in quote because now a days it is possible to use rainbow tables that are readily available from the Internet (they are hundreds of gigs) to find a string that collides with the actual password.

Collisions in hashing functions refer to the fact that many strings can produce the same hash, any one of these string can be used in place of the actual password. From the limited searching I have just done it seems that most rainbow tables are only mapped out for dictionary words and all strings under 10 characters in length, although they are always being expanded.

So without enforcing that our users passwords have to be really long we can we try stop our hashes from being reversed by adding arbitrary strings to the beginning and/or end of the password before we hash the password, this is called a salt. I would recommend always salting your passwords with a different salt for each application.

The last this is the use of MD5, MD5 was once the defacto choice for hashing passwords now-a-days due to the excess of processing power available, the easy of which people can acquire rainbow tables and the relatively high level of collisions that occur in MD5 dew to its short hash length. It is there for better to use a slower hashing algorithm that will generate a longer hash. My personal preference is for the whirlpool algorithm which in PHP is available in the pecl hash extension or be default in PHP as of version 5.1.3. An example use is included below.

hash( 'whirlpool', $preSalt . $password . $postSalt)

So I’ve just reinstalled my PC at home and had to go through the rigmarole of setting up my PHP stack (PHP, Apache and MYSQL) on windows. Now first of all I’d like to say that although i currently have a windows desktop at home my  prefered development operating system is mac os. On most operating systems this is quite easy, your either treated to pre installed version of the software the packages or the use of a nice easy to use package manager. On windows we don’t have such luxuries so we have to find and install the packages our self.

First of all we need to install Apache httpd which can be downloaded from http://httpd.apache.org.

Installation of apache is quite a simple process and by excepting all the defaults allows you to get the web server up and running in no time.

Once the installation is complete we need to make a few changes to the config changes in order to set up vhosts. On windows 7 and vista we need to edit the config file as the administrator, this requires us to find the executable for your favorite text editor (mine is gvim on windows) right click it and press launch as administrator.

Open the apache config file located by default at

C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf.

Locate and uncomment (remove the #) the line #Include conf/extra/httpd-vhosts.conf.

We now need to allow access to out sites directory by adding:

<Directory "C:/path/to/Sites">
    Options Indexes FollowSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

The last thing we need to do in this file with regards to setting up vhosts is add the line:

Include "C:/path/to/vhosts/*.conf"

Now we can add files such as “C:\path\to\vhosts\example.conf” with the content:
e now need to allow access to out sites directory by adding:

<VirtualHost *:80>
    DirectoryIndex index.php

    DocumentRoot "C:/path/to/Sites/example/public"
    ServerName example.localhost
    ErrorLog "C:/path/to/logs/example-error.log"
</VirtualHost>

At this point we should now be able to restart apache by right clicking on the icon in the system tray and clicking restart, If every thing is set up correctly apache should come back up and you shouldn’t see the icon go red.

Apache is now set up to serve vhosts by we need to tell our system that the addresses were using for the vhost (example.localhost in this case) can be accessed by the system. The easiest way to achive this is to modify the systems hosts file. This is the file that windows will check before attempting any dns lookup, it is located at “C:\windows\system32\drivers\etc\hosts” and needs to be edited as an administrator.

Add the line:

127.0.0.1 example.localhost

Only this left to do now is open up our web browser and try visiting example.localhost, if all is well we should see our example site. Good luck