Host-proof hosting

</tr> </table>Host-proof hosting aims to solve the "trust problem" faced by web applications: although SSL may protect user data on the wire it provides no guarantee of the privacy of that information once it reaches the server on the other end of the wire. Or, as Richard Schwartz, who co-developed the ideas behind host-proof hosting put it, "with current technology, trust in web applications only extends as far as trust in whoever is hosting it". Therefore Schwartz proposed to host sensitive data in encrypted form, so that clients can only access and manipulate it by providing a passphrase which is never transmitted to the server. The server is limited to persisting and retrieving whatever encrypted data the browser sends it, and never actually accesses the sensitive data in its plain form. All encryption and decryption takes place inside the browser itself.

Ajax and browser-based cryptography

Schwartz publicly unveiled the host-proof hosting concept in the first half of 2005, several years after developing the concept with Michael D. Griffes and additional colleagues at eVelocity Inc. At that time, the browser environment was too limited to support building a practical solution for host-proof hosting, and the eVelocity version was not brought to market.

In fact, host-proof hosting requires browser-based cryptography and, even if Javascript implementations of crypto functions have been around for years, Javascript alone can’t remember data between page loads. This causes an annoying issue since it forces the user to re-enter the passphrase each time. Java applets or Flash could provide some viable alternative to run crypto algorithms in the browser, but with several downsides.

Eventually Ajax made pure browser-based cryptography a reality since an application developed with Ajax techniques tends to not actually do page transitions, hence solving the problem of keeping a persistent key to perform crypto operations. Ajax gave a new boost to the development of web applications adopting the host-proof hosting paradigm. Most of these applications are online password managers such as LastPass, EZ-Login, Passlet, Clipperz, PassPack and VeriSign's PIP.

Workflow

Here's a likely flow of events for a typical web application that follows the host-proof hosting paradigm.

• User enters a pass-phrase to begin using the system. Browser retains the pass-phrase as a global variable.
• User requests a list of some or all data belonging to him.
• For each record, the system stores the associated user ID in plain-text, the record ID in plain form, and the record content only in encrypted form. Thus, system is able to return a list of record IDs for this user.
• User selects one of the record IDs.
• System checks that this user ID is associated with the record ID, and returns the corresponding message content.
• Browser uses stored pass-phrase to decrypt the contents.

Risks

Script injection is the main threat to host-proof hosting. It weakens this application paradigm, but doesn't invalidate it altogether. While script injection is theoretically possible, it does require some skill on the host's part and is also detectable if you know what the code should and should not be doing.

In theory, there is an even stronger claim in favour of this approach. It might be possible to develop a general-purpose plugin precisely for detection of script injection. For a given application, such a plugin would have access to a certified copy of the source code. Then, it could monitor traffic and caution about any unexpected activity. If such a plugin could be developed, the only way for script injection to succeed would be a conspiracy between the host, the code certifier, and the plugin manufacturer.

References

• Definition from Ajax Patterns wiki
• Is AJAX The Answer For Crypto In Browser-Based Applications? Seminal blog post by Richard Schwartz
• Ajax And Crypto: The Obstacles To Public Key Encryption In The Browser by Richard Schwartz
• Proof of Concept: Browser-Based Field Encryption With Blowfish Via Ajax

Resources