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.
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.
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
1. Alan Bell05/10/2005 05:59:20 PM
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...
4. Richard Schwartz05/18/2005 07:04:38 AM
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 (https://www.passlet.com) is one the first web sites to implement Host-Proof Hosting (Ajaxian article: http://ajaxian.com/archives/passlet-ajax-password-manager-with-aes-client-side-encryption). 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.
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
Hi. PassPack https://www.passpack.com] 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).
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 22.214.171.124 was blocked by the owner of this blog.
Blocked Response!07/01/2008 03:53:22 AM
This response from IP Address 126.96.36.199 was blocked by the owner of this blog.
15. John Vanderhoff08/28/2009 06:47:07 PM
TOTALLY OFF TOPIC
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
alfaonline.com : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-