Comments on: Halfnote: Secure Document Sharing

By: Tribulus

Tribulus — Wed, 01 Oct 2008 12:06:41 +0000

I like it
i like it
thanks

By: Hallvar Helleseth

Hallvar Helleseth — Sat, 21 Oct 2006 10:25:52 +0000

Nice to see that you’re trying to rectify the issues. I would love to see a final solution to this with SSO. That would rock the world (wide web)!

By: Halfnote

Halfnote — Fri, 20 Oct 2006 18:20:51 +0000

[...] Halfnote is a lightweight web-based notepad that I thought was pretty neat. It’s dead simple, basically consisting of only one text area, and features client-side encryption, auto-save, and synchronization between computers. (via) [...]

By: Aaron

Aaron — Wed, 18 Oct 2006 21:32:15 +0000

So I moved halfnote over to SSL. That should handle MITM. It’s true that you’re still not protected against a malicious operator (err… me) or a hacker who has gotten access to the web server and has enough time to wait for the passwords to trickle in. But this is a whole lot better than the alternative, I think.

By: milo

milo — Wed, 18 Oct 2006 15:58:02 +0000

Well, it’s worth a try and maybe the security leak ( protect against man-in-the-middle ) will be developed soon.

By: Michael Mahemoff

Michael Mahemoff — Wed, 18 Oct 2006 00:21:49 +0000

This idea was floated by Richard Schwartz as “Host-Proof Hosting” and led to a debate with Alex Russell about the risk of script injection that you mention. I think the conclusion is that it’s vastly more secure than keeping open data on the server and vastly less secure than keeping it on a local machine! http://ajaxpatterns.org/Host-Proof_Hosting

By: Brad Neuberg

Brad Neuberg — Tue, 17 Oct 2006 23:57:13 +0000

Aaron, btw, you can support older browsers (including Safari) by using Dojo.Storage’s FlashStorageProvider, which comes on automatically. Here is an example editor I threw together to show this, called Moxie, similar to your halfnote editor:

http://codinginparadise.org/e

All that code is BSD, btw, so feel free to use it or incorporate it.

Once we have the WHATWG and IE StorageProviders, using storage on any of these platforms will be as simple as the API Dojo.Storage exports, which is basicly a very simple hashtable with puts and gets (though the inside has alot of support for doing high performance work with large strings, XML, JavaScript objects, and more — you’re shielded from this stuff).

By: Brad Neuberg

Brad Neuberg — Tue, 17 Oct 2006 23:54:15 +0000

Hi Aaron, very cool app! I’d love to see a WHATWG storage provider in Dojo.Storage and an IE StorageProvider; right now we only have a FlashStorageProvider, but the full architecture is there for other kinds of storage mechanisms, including determining at runtime the best one to use. Interested in writing the Firefox 2 (WHAT working group) and IE storage providers? It should be straightforward and I can step you through the process. Feel free to call me at 1-510-938-3263 as well.

Best,
Brad Neuberg
bkn3@columbia.edu
http://codinginparadise.org

By: Aaron

Aaron — Tue, 17 Oct 2006 21:42:16 +0000

Hallvar,

You’re right that client-side encryption by itself doesn’t protect against man-in-the-middle, or a malicious developer. In these regards, it is no better or worse than a normal web app.

What I think is interesting is that client-side encryption eliminates the possibility of the developer accidentally leaking the data.

By: Hallvar Helleseth

Hallvar Helleseth — Tue, 17 Oct 2006 18:30:20 +0000

This seems very suspectible to man-in-the-middle attacks. Wouldn’t all I have to do to get the encryption key be to insert javascript code during the request? Javascript code to fetch the key from storage and transmit using e.g. XmlHttpRequest..

Or if you cannot manipulate a communications stream, insert Javascript (if vulnerable) using XSS attacks and lure the victim to use your crafted URL, ending with exposure of the key.

With a requirement of HTTPS and no XSS vulnerabilities this could be more secure against outsiders. But you would still loose what I think is your main point: Your data is stored encrypted on the server, and the server operators will have no way in decrypting it. Unfortunatly this is not true either. As pointed out, all the operators would need to do to get the key is serve the page with Javascript crafted to fetch and transmit the encryption key.

So in reality this only provides to following security (You must assume that the site is not XSS vulnerable):
- People with read-only access to the stream cannot see your data.

You are still moving in the right direction, hopefully one day a secure solution exists or is even possible.