PermaLinkIs AJAX The Answer For Crypto In Browser-Based Applications?
08:01:42 AM

There has been much buzz about AJAX (Asynchronous JavaScript And XML) lately, including several interesting and informative articles by Domino bloggers Bob Obringer by Jake Howlett. Hey, Jake -- did you know that your "Why Ajax" article is the number one result in Google for "ajax blog"?!

I'm starting -- really just starting -- to do some thinking about AJAX, but not from the "cool UI-oriented things I can do with it" point of view that seems to be the predominant point of interest for most people. I'm wondering whether AJAX holds the key to a problem that I've been wanting to find a good solution to for several years now: pure browser-based data encryption and decryption. The problem I would really like to solve, because I believe it holds an important key to the widespread acceptance and ultimate success of the web as a platform for many types of applications, is that although SSL may protect your data on the wire it provides no guarantee of the privacy of your information once it reaches the server on the other end of the wire. With current technology, trust in web applications only extends as far as trust in whoever is hosting it. Although most in IT might scoff at the idea that one can keep data on a server and use public key encryption to keep the server admins from getting at it, we in the Notes and Domino world know that it's possible as long as the keys to the PKI kingdom and the keys to the server kingdom are kept strictly separate. Five years ago my colleagues at eVelocity and I coined the terrm "host-proof hosting" for this concept. Unfortunately, the browser environment just didn't seem to be conducive to building a solution that would really work for host-proof hosting.

We looked into the idea of implementing crypto algorithms in Java applets that would run in the browser, but that was bad for all the reasons that applets tend to be bad, plus several others. JavaScript based crypto did occur to us, but it seemed like it would be too slow, plus there were other problems. I knew that we could undoubtedly implement Bruce Schneier's Blowfish crypto algorithm in JavaScript, and since Blowfish relies on turning a pass-phrase into a crypto key instead of using X.509 certificates we could avoid the security issues, platform-specific coding issues related to having JavaScript access the filesystem to get the key, or the security restrictions that prevent a single browser window from retrieving a certificate from a separate http server. We certainly didn't want users, however, to have to re-type their pass-phrase at every page transition in the application, and there really wasn't a good solution for keeping persistent data in a browser to avoid that. Cookies were out of the question because they are transmitted to the server, and the idea is that the server should never have access to a user's key, and storing the key in a Javascript variable in a hidden frame... well, let's just say "eeeew!" to that and not go into all the reasons that it just wouldn't hold up.

Along comes AJAX. I think I see some viable solutions. Just keeping a persistent pass-phrase in a browser to make the use of Blowfish convenient for users would be a win. In the Domino world, it wouldn't be hard to come up with a LotusScript port of a VB implementation of Blowfish, which would provide an easy way to build apps that provide the same level of crypto security in both the Notes client and the browser. More than that, though, I'm thinking that AJAX might also make it practical to use certificate-based crypto algorithms in a browser, too, and that could conceivably open the door to leveraging the Notes PKI -- the largest installed PKI base on the planet -- for browser-based crypto.

AJAX development has two properties that could make it the ideal way to solve the problems with browser-based crypto. First of all, apps developed with AJAX tend to not actually do page transitions, so that could solve the problem of keeping a persistent key. AJAX-based apps send requests to the server in background and use the power of DHTML to write updates to the page. Archtiecturally, this is very appealing for someone who wants to do crypto, because it provides a single persistent code path through which all data must pass -- a perfect place to cache a key and do crypto operations. In some spare time over the next few weeks, I hope to first try melding AJAX with this Javascript implementation of Blowfish.

The second property of AJAX that might be of interset is the fact that it does http data retrieval outside of the browser's built-in mechanisms of the location bar and link retrieval. If this allows AJAX apps to get around the security restrictions on accessing data from more than one http server within a single browser window, then a certificate-based crypto algorithm might be practical in a browser environment. Architectures in which an app server and the certificate server are isolated from each other and operated by completely separate organizations would be possible. Of course, this raises a question: if AJAX does get around this type of security restriction in browsers, is it really a good thing? After all, the restrictions exist for a number of very good reasons.

Follow-ups on this topic....

    Proof of Concept: Browser-Based Field Encryption With Blowfish Via Ajax
    The Obstacles To Public Key Encryption In The browser
    An Improvement To The Classic Ajax Coding Pattern
    A Further Improvement To The Ajax Coding Pattern
    Why Ajax And Crypto Intrigue Me

This page has been accessed 3753 times. .
Comments :v

1. Alan Bell05/10/2005 05:59:20 PM
Homepage: Http://

this AJAX stuff is pretty clever. It will suffer from some of the same limitations as Quickplace in that it won't work with translation engines or screen readers, but really this is a limitation of the current crop of translation engines which work like proxies translating stuff between tags on the fly. An AJAX based translation tool would be very very cool, just needs Google or someone to put up a web service, or indeed it should be possible to use the existing google translation web page I think.

I think the crypto idea is great, however the huge advantage SSL has is the little padlock icon in the browser status bar or wherever. To get a trusted(by users) system you would probably have to run the PKI based encrypted traffic over SSL.

2. Richard Schwartz05/10/2005 07:18:11 PM

Agreed. SSL is necessary to protect data on the wire. A second level of encryption is meant to protect it when it resides on the server. When we were working on the "host-proof hosting" concept at eVelocity, another phrase that we threw around was "wrapper-in-a-wrapper" because the presumption was that we would be implementing field encryption in addition to SSL.


3. Alex Russell05/18/2005 03:51:38 AM

You can't get there from here, I'm afraid.

Basically, so long as you're dumping those DOM nodes back into the page that they were "decrypted" out of, you're still going to be SOL. Assuming that the problem being solved is that of trying to protect from a (potentially malicious) middle-man HTTP server, you aren't going to solve the problem this way since that server could just send a small script that watches the contents of the DOM tree (mutation events anyone?) and posts the changed content right back to the malicious server. Oops.

Other than that, I don't really see any useful problem that can be solved by the proposed scheme. Perhaps if you laid out a threat model first...


Alex Russell

4. Richard Schwartz05/18/2005 07:04:38 AM

@Alex: it's true that the server can download a malicious script to steal plaintext and ship it back to the server surreptitiously, but Javascript is inherently open source so an attempt to do so can't truly be surreptitious. It can theoretically be observed. It would, in fact, be much eaiser to detect untrusted script coming in over the wire, I should add, than it would be to detect plaintext data going out over the wire. A broswer-plugin could theoretcically be designed to record exactly what scripts are downloaded, and to issue an alert if any code that has not been explicitly authorized comes down the wire. If that plugin is provided by someone other than the host, then trust in the host is increased.


5. Alex Russell05/18/2005 12:43:27 PM

I'm not going to belabor the point here save to point out that now that you've introduced the use of a plugin, your initial proposal to do it in the browser without modification seems moot. I think this is a good example of a well-understood phenomenon in the security community: when you start with a technology and go looking for a problem, you're likely to build the wrong thing the wrong way. When you start with the problem and then go looking for technologies, you're much more likely to build an appropriate thing in a cost-effective way.

Since you've outlined at least one threat model to me in private mail, I feel like mentioning that your proposed scenario sounds like a good fit for a hardware token + PKI. (full disclosure: I did research one summer for a smartcard vendor).

Anyway, I think the really important part of this whole discussion can be boiled down to: "start with the problem, work backwards to the technology".


6. Richard Schwartz05/19/2005 08:06:00 AM

Alex -- you've definitely got me there. It's unfortunate that a plugin would be required to monitor the behavior of the system, and that does detract from the goal of a true browser-only solution. I can only argue (somewhat weakly, I confess) that in an MxN B2B application, the solution I am envisioning could probably be judged "secure enough" by most parties based on a regimen of spot-checking. Rather than having all users with the plug-in, a few would suffice to establish high confidence that the host is not routinely snooping on supposedly private data.

One thing to bear in mind is that although we may portray in the threat scenario that the host is untrusted, the primary threat in the B2B environment would not be systemic abuse by the hosting company, per se. The users would have to have at least some measure of trust in the company itself. But rogue employees of the hosting company or bad guys who compromise the hosting company's systems are another story. In practical terms, they're the real source of threat. Practically speaking, there should and would be other safeguards in place besides a browser plugin as I have described.

Nevertheless, I accept that what I am describing here is no panacea. It could not, definitely not, suffice in the most stringently secure environments. It would not be sufficent protection against a specifically targeted attack. The weakness could be be mitigated somewhat by a prominient on-screen admonition to users who lack the plugin, but in a truly ideal secure solution we would not want to end-users bearing that responsibility.

7. Chris Hammond-Thrasher05/21/2005 01:34:17 AM

I have been thinking about and writing about the same topic recently. I think that Ajax has some real potential in the area of client side crypto services - especially when we seek functionality beyond the original crypto twins, confidentiality and integrity. What if you you want to sign something on the client side, for example?

I really want to see the JS implementation of Blowfish! How will you get a decent source of randomness?

8. Lyal Collins07/19/2005 06:18:16 PM

We developed a commercial product 3 years ago with almost these same high level crypto funtions, but instead aimed at client authentication and as an adjunct to electronically signed pages. Key2Browser is however readily adaptable to the needs to only en/decrypt content in the browser window. This allows a user to retain the same password (if they choose), but never encode the same data more than once with the same key).

The other clever thing is you've avoided public key overheads - a major saving in complexity and overheads with identical security risk profile.

The risk profile associated with a scripting language is avoided by letting people download a plugin to their browser. This ensures that MITM attacks don't disclose the script code, which degenerates the security profile to a simple dictionary attack.


9. Parvez Anandam12/10/2006 10:18:35 PM

Passlet ( is one the first web sites to implement Host-Proof Hosting (Ajaxian article: It is an online password manager that performs all AES encryption and decryption operations completely within the browser and uses AJAX for exchanging the encrypted data with the server.

As noted above, there needs to be a mechanism for the user to independently verify that the JavaScript code she is about to run has not been tampered with. While a plug-in (or, even better, native browser support) is the most fool-proof solution, I propose a more light-weight alternative: the Page Source Verifier Bookmarklet ( This pure JavaScript bookmarklet fetches all the code on a page and outputs SHA-1 hashes. A bookmarklet is more in keeping with the anywhere, anytime, access of AJAX than a plug-in.

Parvez Anandam

10. Richard Schwartz12/10/2006 11:06:01 PM

Very nice work! I'm glad to see that this idea is finally taking root.

11. Tara Kelly01/03/2007 11:30:13 AM
Homepage: http://

Hi. PassPack] launched just shortly after Parvez's Passlet. We too have implemented the Host-Proof Hosting. Actually, quite a few sites have recently popped up that use the pattern. It's really very exciting.

PassPack has been online since Dec.2006 and we just rolled out the Beta 3 release. Please do have a look - suggestions on how to increase security are always welcome!

Of particular interest are ideas on how to mitigate phishing attempts, as this the primary point where the Host-Proof Hosting pattern offers no security in and of itself (nothing does actually).

Tara Kelly

12. Frank Nimphius02/28/2007 04:54:16 AM

Anybody thought of how browser standardization throughh W3C or OpenAjax Alliance could help implementing an API on the XmlHttpRequest object that allows applications to access public keys installed on a browser? I am not always sure hat problems cause by a runtime environment can be handled in software.

Blocked Response!06/26/2008 06:04:21 AM

This response from IP Address was blocked by the owner of this blog.

Blocked Response!07/01/2008 03:53:22 AM

This response from IP Address was blocked by the owner of this blog.

15. John Vanderhoff08/28/2009 06:47:07 PM
Homepage: http://www.v-and-m.ccom

When I watched the two minute video, I immediately thought of you.


16. vesoftware11/05/2013 11:04:44 PM

Agen Bola Promo 100% SBOBET IBCBET Casino Poker Tangkas Online
ITUPOKER.COM AGEN POKER ONLINE INDONESIA TERPERCAYA : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.