AJAX is definitely taking Web applications to the next level in ease of use and desktop-like user interfaces. And it can even be used to create the secure, privacy-oriented Web applications that are so needed in today's Web world.

AJAX is based on Web browsers endowed with powerful JavaScript engines.

In this article I'll explain a framework for AJAX-based Web applications based on client-side data encryption using a Secure Key for maximum data security and privacy. This framework can be used with any Web application, saving a lot of potentially sensitive user data like bank account details and login details for Web sites.

This framework will put the user in full control of sensitive data; the back-end server will just be a mechanism to save the encrypted blob from the user. It's based on client-side JavaScript and XML for all the business logic and data encryption/decryption, searching, and sorting. It will also open up new dimensions for making online payments and banking since it can talk to different Web Services from the client browser instead of going through an intermediate server, thus minimizing the risk of any third party intruding on the data.

Regular unencrypted user data will be present only in the client browser. Anywhere outside the client browser the data will be encrypted, be it on the wire or saved in a back-end database to maximize security and privacy. And I'll explain how to write an easy AJAX-based Web application using DWR (Direct Web Remoting) with this framework.

The Need for a Client-side Encryption Framework
When saving sensitive private information in any Web application, questions always cross my mind. How secure is my private data? Do I really trust all the servers where it's saved? Most of the time I have to trust the server since there's no other way to get stuff done using the current Web application security framework.

All Web applications save private user information in their databases either encrypted or unencrypted with a server-generated key, which creates a major threat since the mechanism to view the data lies with the server and is available to all sorts of manipulation by the back-end server's users and any interloper with access to the server. So for Web applications where user privacy is a primary concern, there's no robust architecture to give users the upper hand in controlling their private data.

Our framework, using client-side encryption to encrypt user data, gives the user full control of the data and the data is encrypted once it leaves the user's browser. The user is given the ultimate privacy and security and can rest assured that no one can do anything with it. But coming up with a real functional Web application using this concept is a little difficult without the power of AJAX and JavaScript. Figure 1 shows the data transfer mechanism in a typical Web application. Figure 2 shows how the client-side encryption concept works differently than typical Web applications.

In Figure 2, the basic data transfer mechanism is shown for Web applications doing client-side encryption where the data is in encrypted form anywhere outside the browser JS engine. In a classical Web application, HTTPS/SSL is implemented only to transfer the data encrypted on the wire, but once it reaches the server, it resides in unencrypted form or is encrypted with a server-generated key.

For client-side data encryption to work and ensure data privacy the private user data in the browser is encrypted with a user-provided key (secure key) that is never transported or saved in the server. The data is saved in encrypted form in the server and the server doesn't have a clue what the unencrypted data is! And when getting the private user data back from the server, the data is downloaded in encrypted form. To view the data or to take any action on the data it has to be decrypted using the Secure Key used to encrypt it. The data lives its unencrypted life only in the browser's user session and all the logic to interact with any Web Service to do application logic or any searching or sorting is done using JavaScript and XML programming on the client side. This puts a lot of processing and application logic in the client-side JavaScript engine, but it's secure enough that it's virtually impossible to break in.

Let me use an analogy and explain the concept in terms of a person storing his valuables in a safety deposit box at a bank. A person (our user) opens a safety deposit box account (the user account) at a bank (your typical Web application) and stores all his valuables (his private data) there, but the box's key (the password) stays with the bank and the user can only get it after verifying his identity to the bank. He can go to the bank anytime and verify his identity and get access to his valuables, but since the key stays with bank, the bank has full access to the stash. Our concept lets the person put a lock on the valuables using a private key (a Secure Key) before storing them in the box so the bank doesn't have access. Only the person with the key has access to the box. In the real world too, this concept adds more robust security to the user scenario.

Simple Use Cases Where the Framework May Be Useful
Our framework is useful in any Web application where the user's privacy and security is a major concern. I'll provide use cases for two simple Web applications where it will find great application.

An Online Account Handler Application
If you think about the different online accounts you open or maintain everyday, you know it would be precious to have a Web application where you can store and manage the login credentials for all your Web accounts without sacrificing privacy. The technology in typical Web applications doesn't scale well. Our approach guards the user's interest and gives him full control of his private data.

Online Shopping and Payment Applications
There's a plethora of Web applications that save user bank and credit card information online so the user can make payments with the click of a mouse and give him a rich experience in terms of ease of use, but they also expose him to phishing attacks. The client-side encryption framework offers both ease of use and enough security for them to put their private information on them without hesitation. On the server side there will be less rumpus about password or credit card theft since it will be impossible for anyone other than the user to make use of the secured private information. Hackers can break into the site but it won't matter.

Banking and online shopping sites could put a stop to phishing and other vulnerabilities with this approach if the Secure Key combined the user-provided key and a unique server key to identify the server.

A Sample Web Application with the Concept at Work
Now let's see how easy it is to put this client-side encryption framework to use in a very basic implementation. I'll take the use case of an online account handler application and write a reference implementation. The application I implement will explain the idea of client-side encryption in detail.