Host-proof hosting

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 Logaway, 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 downloads software (e.g. Ajax program) from host to begin using system
* 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 and vulnerabilities
A major vulnerability with "host-proof hosting" relates to the software the user must download and run in their WWW browser in order to operate the system. As this is browser-based, it is typically downloaded from a WWW site. This defeats the entire point of "host-proof hosting", as the host could modify this software to (for example) send any password entered by the user to it, or simply remove, or heavily weaken any encryption used. This would go undetected by the user, and allow the host to freely read and write the supposedly "secure" and "host-proofed" data stored by the user.
Script injection is a another serious threat to host-proof hosting.

Main Menu

See Also

Main Menu