[Update: January 15, 2007] For information about the live AJAX Login demo which implements the attributes described in this post see the third post in the series - Unique URLs and Live Demo.
In Simplifying the Sign In Experience with AJAX, I brainstormed about how an AJAX Login control could improve a user's web application sign in experience. The second item on the list of desired attributes for such a control was Secure Without SSL. This post dives into the details of that attribute and gives an overview on how I implemented it.
A Secure Authentication Mechanism
So, if Secure Socket Layers (SSL) will not be used to transmit the user's login information, how then can it be transmitted securely? Well, it turns out there are a few ways to do this, and tradeoffs for each.
Paul Johnson has a good discussion about some of the different ways that such a system could be implemented. After reading his thoughts and some others around the web, I decided to do some experimentation with different authentication methodologies and arrived at what I decided was the most effective solution.
Note that I want to give a special thanks to Paul for all of the information on his site and for making his SHA-1 javascript implementation available. For more information about his other cryptographic implementations, visit his cryptography page.
A Secure Registration Process
The sequence of events for the registration process is shown below. Essentially, after the user fills in the data and submits the form, the server first verifies that the user is unique and then generates a unique salt for the user. When the client gets the salt from the server, it uses it to encrypt the password. At this point, I followed Paul's advice and instead of just concatinating the salt and password together before performing the SHA-1 hash, I used Paul's HMAC function for extra protection. This is what makes the transmission secure. Even though the data is sent to the server in clear text (without SSL), the data sent is actually encrypted.
In the last step, the server stores the unique salt that was generated for the user and the encrypted password so that they can later be used for authentication. Note that the one additional advantage to this method over SSL is that the password is never seen as clear text except when the user types it into the browser. Even the server software does not know the real password.
Figure 1 - The registration event sequence
A Secure Sign In Process
The sequence of events for the sign in process is quite similar to the registration. Primarily, the differences are on the server side. As you can see in the figure below, the process kicks off by the user entering their information and pressing submit. The client script will then take their username and send it to the server to ensure that the user exists. This will expedite the notification event to the user should the username they chose not be unique. In addition to this, the server will also retrieve the unique salt for the user that was generated during the registration and generate a one time challenge key. The challenge key is primarily used to prevent replay attacks. It is only valid for a single sign in attempt.
After the server sends the client the salt and challenge key, the client then performs two HMACs. First, the password is hashed with the salt, just as it was during registration, and then the resulting value is hashed together with the one time challenge. The client then sends this value along with the username to the server for authentication. The server then performs a similar hashing of the values and checks it against the values sent from the client to verify the user entered the correct password. And viola, the user is securely authenticated without SSL.
Figure 2 - The sign in event sequence
Disclaimer
Please note that this is not nearly as secure as SSL. However, it does protect sensitive data in transit and does prevent against many common attacks. The one obvious vulnerability that this method has is to a man in the middle attack. But this is only the case if the person snooping your data knows to connect your registration data with your login data. If they do not have the data that was sent over the wire during your registration they will not be able to fool the system unless either they can decrypt SHA-1. Therefore, I consider a good option for web applications that need an alternitive solution to SSL and need only provide basic authentication. It is not in any way an equivalent to SSL and should not be used when extremely sensetive data needs protected.
Keeping It Simple
One of the primary things I want to do with security implentation is keep it simple. The problem is that, by nature, security is quite complex. So, at the bare minimum, I want to obscure any complexity required from consumers of the AJAX login control.
In order to do this, there are two parts to obscuring the complexity. First, on the client there are some encryption algorithms that are needed. The use of these algorithms is nicely partitioned from the rest of the client script. Second, on the server there is some processing that needs to be done to implement the chosen authentication protocol. This code is also independent of the code which implements the user registration and sign in process.
The First Demo
Coming in my next post... very shortly.