eSpace

An essential feature of all respectable web frameworks is a reliable user authentication mechanism. Nevertheless, one might be tempted to write his own from scratch, and the reasons are many. It could be that you don’t like the way your favorite framework does the task, or you might feel a need to tweak it a little bit. Maybe you’re too paranoid to let a third party handle it for you! You might not be using a framework in the first place, or you might even be writing your own!

In this post, I’m going to discuss a simple mechanism that has served us well in several projects. It’s straightforward and flexible enough to be used in almost any project, but just like any solution to a software problem, there’s no such thing as a silver bullet; you have to choose the right tool. So, before we go any further, let’s first state precisely what we’re looking for in our sought solution.

• It has to be at least as secure as regular password-based authentication.
• It has to be lightweight, minimizing database I/O as much as possible, so that it can be done for each and every request without adding too much overhead.
• It should require minimum communication between server nodes.
• It shouldn’t bind a user to a specific machine, allowing requests originating from the same user to be transparently handled by different machines.

It all starts off with a simple and familiar step: the user sends his login and password, which are then compared to the stored ones. From that point, things take a slightly different path. Remember that authentication is part of each and every request. Done the usual way, this means an expensive db query at the beginning of each request. Our goal here is to convert this into a lightweight, on-the-fly step. So, how can this be achieved?

Consider this: what if after verifying that the login credentials provided by the user are actually correct, the user is given a little box that can never be opened (well, let’s say very hard to open) except by the one who made it, and which contains a secret message which no one knows, except for the one who wrote it. For each of the following requests, instead of providing the login & password again, the user hands back the box. By looking at the enclosed message, we can instantly determine whether it’s a authentic or fake, depending on whether the contents match the secret we know or not.

Of course, in programmers’ jargon, that box translates to a secret message encrypted at the server using a symmetric key, which will be referred to in the rest of this post as the authentication token, or just as token. Depending on the size of the secret message and the encryption algorithm used, decrypting the message should be much faster than querying the user’s password from the database (from my own experience, the ratio can be something like 1:20 using Triple DES and a secret almost 100 bytes long, but your mileage may vary).

This can be implemented in a myriad of ways, and it’s not tied to any technology in particular. Actually, the concept is used over & over in numerous places so I’m not claiming it’s new. I’m just showing how you can fit it inside your application.

For that purpose, and since the web community is currently rediscovering HTTP with the rise of RESTful web services, I’ve chosen to stick as faithfully as possible to the HTTP protocol throughout my demonstration, giving examples on how the same can be achieved in different scenarios.

Using HTML forms to send login credentials is known to everyone, but HTTP actually has built-in support for several authentication schemes (yes, I’m talking about that annoying modal dialogue that asks for password in some sites that require authentication). HTTP authentication works as follows: whenever a client accesses a URI that resides within a set of restricted pages (called realm in HTTP lingo), the client is challenged by the server. At that moment, the client is supposed to provide a challenge response. Depending on the authentication scheme, the challenge response can be one of several things. In the BASIC scheme, which is what we’re concerned with, the client should provide a base64 encoded string that when decoded should look like this: <username>:<password>

To simplify things, and since we’re assuming that each request has to be authenticated, the client is always assumed to embed a challenge response in each request. If the client fails to do so, the server should reply with 401 Unauthorized. On the other hand, if the client supplies a valid username/password combination, the server composes and sends the authentication token in a response header (a custom header that should preferably include your application name, for example, to avoid name collision). The encrypted token should contain the secret as mentioned before, but should also contain something unique to the user, such as the user ID in the database, or the username. Otherwise, tokens generated for different users will be identical, and that’s certainly not wanted!

On the other side of the wire, when the token is received by the client in the response, it should be extracted & used in the challenge response of each subsequent request, where the client will still use the BASIC scheme, but with the username omitted, so that the decoded challenge response should look like this: <empty string>:<token>

This is so that the server knows whether the client is using a password or a token.

 

Figure 1: State diagram describing how the client chooses the appropriate authentication method. 

 

Figure 2: Flow chart showing what happens at the server when authenticating a request.

A disadvantage of this method is that there’s no obligation on the client to ever use the token; it can choose to send the password every time, and the server can only play along. However, if you have some control on how the client behaves, this won’t be an issue, but I’m saving that for another post.

Depending on the capabilities of the client (for instance, the subset of the HTTP protocol it supports, or if it’s not using HTTP altogether), you have the freedom to implement this in many different ways. For instance, you can pass back the token in a cookie, JSON object, XML response or whatever format you wish. Note, however, than an encrypted token will most probably have non-ASCII characters, so you might find it necessary to base64 encode it after encryption.

One very useful extension of this whole thing is to make the authentication token assume the role of the user session. If the session is small enough to be piggy backed on each request, then you needn’t keep anything at all about the user session on the server! This makes the server completely stateless, allowing user requests to be served from anywhere. If this is doable in your application, then it’s even better than session caching, because unlike a cache, it doesn’t require any maintenance. In my opinion, this is the most interesting aspect of this approach (and I believe this is the approach endorsed by Rails 2.0, by the way).

One overlooked issue, however, is: what if someone stole a user’s token by sniffing the victim’s packets? After all, it’s still an authentic token, isn’t it? Well, this is not different than password-based authentication. Both are equally vulnerable to that kind of attack. Your best call is to use HTTPS. Alternatively, but not as equally safe, is to add the user’s IP address to the token contents, so that the token is considered valid only if it’s coming from an IP that matches the one inside it. Finally, the key & secret used by the server to create the token should be regularly changed, and in that case, old tokens will cause the client to receive a status code indicating session expiration, and the cycle repeats again starting with password login.