Everybody loves the Web 2.0 style of no page loads and seamless transitions (almost everybody). But there are some security limitations placed on the xmlhttp callback objects that make life a little difficult sometimes. For instance, if your page originated on the server http://blog.paranoidferret.com/, you are only allowed to use the xmlhttp request object to request data from http://blog.paranoidferret.com/. If you try and request data from https://blog.paranoidferret.com/, the request will throw an exception and you'll get nowhere.

So, for instance, if you want to have your users authenticate over ssl, you either have to do a page reload, or your page has to be on ssl to begin with. Neither of those options is particularly attractive - doing a page reload destroys that nice illusion of seamlessness, and having the page on ssl all the time is a lot of overhead server-side.

A third option is to come up with a scheme to secure the data that needs to be secured without having to use ssl. And that is what we are going to take a look at today. Here, we are going to go over a (relatively) secure method of exchanging passwords over an unsecured http connection with only a little bit of extra work on the client and server side. First, I'm going to discuss how it will work in general (and what its main flaw is), and then I'll go over its implementation in code.

There are two main stages to this system: registration and authentication. The registration part is pretty simple. On the client side, the user will enter a password, and we will take the hash of that password. That hash will be transmitted to the server, where it will be stored (probably in a database).

Authentication is a little more complicated, but its not too bad. When the user goes to authenticate, the server creates a random number, stores it (probably in the session), and sends it to the user. The user will enter their password and it will be hashed. This hash will then be concatenated with the random number and hashed again. This double hash will then be transmitted to the server. On the server side, the server pulls out the password hash from the database and the random number from the session, concatenates them, hashes that value, and then compares that value with the value transmitted from the client. If the two values match, then we can authenticate the user.

The flaw here is with registration. If someone catches the registration transmission, they can get that original password hash. With that hash, they can probably manage to authenticate against the server, thereby impersonating the original user. They can't, however, ever get the user's actual password - because that value is never transmitted over the wire. The server doesn't even know it, it only knows that hash. And the beauty of a hash is that it is impossible to get the original value back out (if you want more info on how cryptographic hashing works, take a look at the Wikipedia article).

In many cases, this flaw is acceptable, because this risk of user impersonation is not a problem (i.e., perhaps there isn't any 'private' content on the site). In fact, if there is private content, then you should probably be using ssl anyway, so that that content is secured from eavesdroppers. But in the case where the only thing that really needs to be secured is the password itself, this method is perfectly acceptable (because, again, there is no way to get the original password).

So now that we know the method behind all of this, lets take a look at how we can actually implement it. Here, the client side work will all be done by javascript, and the server side will be in php. First things first - we need a hashing function. Now lucky for us, php already has a number of hashing functions, including the one we will be using - SHA1. Javascript, on the other hand, does not. Fortunately, a number of people have written SHA1 hashing functions for javascript, and we will be using one of them.

The following javascript SHA1 implementation is courtesy of Chris Veness and is licensed under the LGPL.


Now that we have the SHA1 hash in both php and javascript, we can go ahead and write the actual implementation. First off, the xmlhtttp callback function:


This function is just a simple wrapper around the xmlhttp object. It takes as arguments the url to callback to, and the javascript function to call with the callback result. It returns true or false depending on whether it is able to start the callback. A return of true does guarantee completion - it just means the callback has been started. We will be using this function to do the callbacks for both registration and login.

Now onto the code for registration client-side:


First off, there will probably be some sort of constant url to the php file on the server we will be calling back to. Here, that is a global variable called loginURL. The two functions following that variable are extremely simple. The first one, RegisterClicked(), would probably be hooked to some button or link on the page. Calling it just grabs the new user name and password from some text boxes on the page and creates a url. As you can see, it calls the SHA1 hash function on the password before it is even put in the url. This url is then posted back to the server, with the function RegisterResponse set to be called with the result. The RegisterReponse function, as it stand right now, does nothing, but in reality it should be checking the result to make sure there were no errors in registration.

Now lets take a look at the client-side code for logging in:


Here, the login process is broken into two major parts: getting the challenge value, and then the actual authentication. The function LoginClicked (which is probably called by some link or button on the page) immediately goes and requests a challenge value from the server. When the server responds, the ChallengeResponse function will be called, and the argument challenge will hold that challenge. Now, we can build the url - as we needed the challenge value to build the correct hash of the password. We callback using this new url, and the response goes to the LoginResponse function. And here , if the response is "Yay", apparently the server has successfully logged the user in.

I'm betting, at this point, you want to know what this all looks like on the server side. Well, lets take a look:


Now, there are a number of details missing here, mostly because theres no need to get into the details of php and databases. But the basics are here, and should make sense. So, based on the arguments on the callback url, we either enter the Register, the Challenge, or the Login block. For Register, we take the new name and password, create a "user" (something, perhaps, defined elsewhere in php code), and save that user to the database. For Challenge, we create a decently long random string, save it in the session, and shoot it off to the client. And then for Login, we get the user out of the database based off of the given name, and then see if the password is valid. We call strtolower on both hashes because both are hexadecimal strings, and it is possible that one string has the letters capitalized (like A3F1543ED287) while the other is lowercase (a3f1543ed287). Since they are equivalent hashes either way, we just lower the case on both so we can do a string comparison. And if they match, the password is valid, so we can authenticate the user!

And that about covers it. You won't be able to lift the code directly off this page and use it without modification - because you will need to write the database functionality for php and you will probably want to flesh out the communication between server and client so that errors are communicated more appropriately. But I hope you find the technique useful and easy to use. If you have any questions, feel free to leave them in the comments.