I was looking around for concepts in building a reasonably secure HTML login form without using SSL, and I came across an interesting article (link at end of post). The concept it outlines is fairly simple, and I’m a little annoyed that I didn’t think of this myself earlier.

Essentially, the idea is that the password never actually leaves the client machine. Instead, the client sends a cryptographic hash of the password. For other security reasons, we also don’t want the server to store the password in plain text, so it should only store the hash value of the password.

Of course, this alone isn’t enough, because anyone scanning the wire could simply capture the hash and send that along to the server and authenticate. What we need is a way for the server and the client to agree that they have the same hash value for the password, without actually sending it. To accomplish this, we can set up the server to generate a random string and send that to the client. Then, both server and client append the password’s hash to the random string and perform a hash sum on the combined string. The client then sends that string to the server and if it agrees with the result the server got, we have a valid authentication.

The article referenced above included some sample code to illustrate this functionality, but I believe I can simplify it even further. It’s not a practical, real world example, because we’re not sending a user name or retrieving a password from a stored location on the server. But it should be enough to illustrate the concept and give a developer a head start in however they wish to implement. Personally, I plan to instantiate the code in a class and use XMLHttpRequest instead of traditional POST methods.

Anyway, on to the example code. Note: This example doesn’t actually look up any stored user login information. Instead it simply uses a pre-defined password: ‘password’.

We’ll need two files. The first file generates the server’s shared key and passes along the value to the client as well as the HTML and JavaScript needed to input a password, generate hash values and submit the form to the server.

Create main.php with the content:

// We'll use PHP's session handling to keep track of the server-generated key


// Function to generate a random key.
// Modified from code found at: http://www.totallyphp.co.uk/code/create_a_random_password.htm

function randomString($length) {
    $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
    $str = NULL;
    $i = 0;
    while ($i < $length) {
        $num = rand(0, 61);
        $tmp = substr($chars, $num, 1);
        $str .= $tmp;
    return $str;

// Call the function and set the shared key

$key = $_SESSION['key'] = randomString(20);

    <!-- JavaScript that contains the functions which perform the actual hashing -->
    <script type="text/javascript" src="http://pajhome.org.uk/crypt/md5/sha1.js"></script>

    <!-- The following function creates the hash of the concatenated key and password hash
and submits the content to the server via a form -->
    <script type="text/javascript">
	function login() {
		var p = hex_sha1(document.getElementById('pass').value);
		var k = document.getElementById('key').value;
		var h = hex_sha1(k+p);
		var hash = document.getElementById('hash');
		hash.value = h;
		var f = document.getElementById('finalform');
    <form action="javascript:login()" method="post" >
	<input type="hidden" id="key" value="<?php echo $key; ?>" />
	<input type="password" id="pass" />
	<input type="submit" value="Submit" />
    <form action="login.php" method="post" id="finalform">
	<input type="hidden" name="hash" id="hash" />

Next we need the file to handle the submitted values and compare the results. Create login.php with the following contents:

$hash = $_POST['hash'];

$pass = sha1('password');
$key = $_SESSION['key'];

$server_hash = sha1($key.$pass);

if ($server_hash == $hash) {
	echo "MATCH!";
} else {
	echo "NO MATCH!";

That’s pretty much it. If you want to see a little more fluid example in action, see: http://www.lightcubesolutions.com/~jhuntwork/secure_login/

Referenced article: PHP – Implementing Secure Login with PHP, JavaScript, and Sessions (without SSL)

It’s been around for a long time, and it’s had its fair share of abuse. If you’re like me, perhaps you can recall when one of the most popular uses of JavaScript was for dynamic looking buttons. Do a little mouse over on the button and the button glows, or changes shape, or some other little effect which really amounted to swapping out an image. It was often being used more obnoxiously than elegantly.

Then came Flash. Everyone loved it. And again, everyone over-abused it. Finally, it became obvious (at least to me…) that people tend to prefer simpler design with occasional purposeful animation. In walks JavaScript (again).

Developers began using JavaScript in much more powerful, interesting, and ultimately elegant ways. One of the biggest ways being accessing and modifying the DOM. By listening to user initiated events (mouse clicks, keyboard entries), a developer can dynamically alter, rearrange, delete or create new document objects, all on the client side. A user can even initiate a server request (via the XMLHttpRequest object) and receive its reply without reloading the entire page.

The power, flexibility and standard implementation of JavaScript make it a powerful tool in building web-based applications. It would be a mistake to ignore it. I’m certainly getting my hands dirty with it (honestly, more by chance than anything else) and I’ve been loving the experience. A book that I’ve really found a great tool in helping me get the most out of the experience is called The Art & Science of JavaScript. I’d recommend it to anyone in the business or habit of building web-based applications.

Just adding to my previous argument to move away from massive spreadsheets (See WebApp vs. Data Tennis) is the infoSoft Global application FusionCharts. I’m a huge proponent of being able to visualize data in a way that will make the most impact for your audience. This shouldn’t be sacrificed just because the application is on the web. As a matter of fact, it should be even more impacting with the speed of which information can be transfered and displayed.

We recently came across FusionCharts searching for a simple way to integrate web graphing with our already matured LAMP Application. The flash based graphing works well with PHP, Python, Ruby on Rails just to name a few. The best part is that all you need to do is feed it the right XML datafile and the graph is done. This makes it easy to read directly from a database (which we did) utilizing a few string manipulation techniques.

Did I mention that they have a free version?

In my first post (Light it up!), I mentioned that LightCube Solutions has an opportunity to pioneer an open source courseware application. Here are a few more details:
In a nutshell, the idea is to create a web application (at the moment it is powered by PHP and MySQL) that allows High School students to study content on their school’s intranet. Teachers will have access to add/create content and publish tests. When the students take the test, their scores are recorded in their profile. Teachers and other administrators can monitor their progress, scores, course history and so on. We want to keep it open source to allow a wider scope of input and collaboration.

Currently, the project is being organized here: http://www.lightcubesolutions.com/ScribbleAppTrac/
And a demo of the current code is here: http://www.lightcubesolutions.com/ScribbleApp/
The name of the project is likely to change, so stay tuned for more info.
It’s a common practice for businesses small and large to use spreadsheets in their business processes. The dependency of these files grows to the point of painful return. 

Consider the common scenario:

Team A works on a simple spreadsheet for data tracking. This file (on a daily or weekly basis) needs to be sent to Team B as an input to their workflow. Unfortunately the update to the file was not complete. Team B needs to send the file with their changes back to Team A for updates and validation. Here are classic complaints of this common scenario:
  • You are KILLING my inbox –  We are now zipping 7Mb files to email.
  • Can I change the way this spreadsheet looks? Answer: Yes- But it will mess up the formulas and conditional formatting.
  • It takes forever to run the macros on this data.
  • Some of this data (from 10 versions ago) was fat fingered. I wonder what else is wrong.
Picture the WebApp:
Team A updates a webbased version of their spreadsheet tied to a secure database. Team B has access to the database via the same webapp and is able to read and write on their timetable. The database and webapp apply version control, user access, routine backup and enhanced functionality. Classic comments:
  • I didn’t know that this web stuff was so fast and flexible. 
  • This thing corrects me every time I enter something wrong, saves me plenty of time later on.
  • I get the solution to my data request right away. My macros used to take forever.
  • Both my teams can work almost simultaneously. They communicate much better with this WebApp in place. 
Yes its true. You can use conditional formats, data validation and scripting in spreadsheet applications. The problem is that over time managing these custom scripts files becomes a pain when going between different teams and business processes. Web based applications allows custom functionality without the overhead of large files. Yes its debatable, but why not limit the data tennis?
Telecom/Trunk ordering, resource allocation, reporting spreadsheets and the like can all be moved from 7Mb files (and growing) to a WebApp. Any questions?