Secure Ajax Based User Authentication

Ajax allows us to build Web 2.0 applications with ease. However, it also raises a number of questions. One such very pertinent question is regarding user authentication. User authentication simply means checking the authenticity of the user, How should we ensure that authentication mechanisms are not bypassed, when we use Ajax – in other words, when we deal with asynchronous way of communication, instead of a standard user ID-password based mechanism?

Let us first quickly take a look at the HTTP authentication mechanisms, with or without Ajax. We can classify user authentication mechanisms in Web applications as shown in the diagram below.

Let us discuss these in brief.

• Built-in authentication mechanisms are provided by the Web browser as a default. In other words, we do not need to code anything in order to utilize these mechanisms. All that we need to do is to make some settings on the Web server to indicate that we want the user authentication to be mandated. This is classified into two further categories: basic and digest. Both look the same to the user. Whenever the user attempts to access a protected Web page, the server prompts the user to enter the user ID and password required to access this protected resource. However, internally there is a difference, which we shall look at.*  Basic authentication: In this case, the user ID and password are sent from the browser to the server as they are (i.e. in plain text or clear text). Hence, an attacker snooping on the communication between the user and the application will have access to the user’s credentials.

  *  Digest authentication: Here, the user ID would be sent in clear text from the browser to the server. However, the password is not sent as is. Instead, it is digested first, using a message digest algorithm, such as MD5 or SHA-1. The server holds the user’s password in plain text. When the user ID and digested password is received by the server from the browser, it would also compute a digest of the password that it has, and would compare it with what has come from the browser. If the two tally, the server would consider the user as legal. This is surely better than basic authentication.

• Custom authentication: Here, we do not rely on the built-in HTTP authentication mechanisms. Instead, we write our own authentication logic. This can be done in multiple ways. The user ID and password can be sent in clear text (not recommended at all), digested (better), or encrypted using SSL before they are sent (the best approach). The idea is quite simple. Whenever the user attempts to access a protected resource (URL), the server sends an HTML form, created by the designer/programmer to accept the user ID and password. JavaScript code loaded in the browser digests or encrypts it and sends it to the server. The server verifies it.

While working with Ajax, there are not any significant changes in terms of the above principles or challenges. We still need users to authenticate before they can access protected resources. We still need to worry about the aspects of which is the best way of doing so. In general, the HTTP basic authentication is not much used these days due to the obvious drawbacks. However, a word of caution is necessary here.

Sometimes, people are mistaken to believe that the HTTP basic authentication mechanism also digests or encrypts passwords. This happens because if we look at the Authorization:Basic header that gets added to the HTTP request when this form of authentication is used, the password is not shown in plain text. However, beware that just because the password is not shown in its original form does not mean that it is digested/encrypted. What happens in this case is that the browser first applies Base-64 encoding to the password and then sends the converted password to the server. Base-64 encoding has nothing to do with security. It is just a way of overcoming the problems of sending unrecognizable characters beyond the basic ASCII character set over HTTP properly. Base-64 decoding, which is a straightforward process, can reveal the encoded password in plain text easily.

Thus, Ajax authentication mechanisms must be chosen between digest and custom. Digest authentication is acceptable for simple applications that do not demand too high security. We can see this form of authentication in use on many older sites. However, all modern Ajax applications must be built using custom authentication. An added feature should be SSL. This would ensure that the user’s user ID and password can be accepted in a very friendly (Web 2.0 like) manner, digested/encrypted as per our choice, and also sent over a secure HTTPS connection. Moreover, a token (say a unique random number) representing these credentials can be placed in a response cookie or session variable from the server to the browser. Next time the browser wishes to send another request to the same server, this unique token can be sent back to the server. Since everything passes over SSL, there is no question of any one breaking in, at least with today’s technologies.

About the author : Atul Kahate is Head – Technology Practice, Oracle Financial Services Consulting (formerly i-flex solutions limited). He has authored 19 books on Information Technology, 2 on cricket, and over 1500 articles on both of these in various newspapers/journals. His site can be visited at www.atulkahate.com and he can be reached via email at [email protected]

Related –
* Atul Kahate’s session – “Challenges In Ajax” at IndicThreads Conference On Java Technology 08