3 ms·
It's not really true that (due to the data being encrypted client side) your data is safe even if someone were to gain control of the server. It's something oft
by johtso 15y ago
It's not really true that (due to the data being encrypted client side) your data is safe even if someone were to gain control of the server. It's something often claimed by these "Host Proof" style services.
As long as you are downloading the client side code from the server, someone just needs to make a small change to the javascript and they get access to your data.
Only if you can trust the code, and then make certain that the code does not change, is your data truly safe from the host.
Cortesi (http://corte.si http://corte.si) has done some interesting writing on the subject. http://corte.si/posts/security/hostproof.html http://corte.si/posts/security/hostproof.html
He implemented a similar service (http://cryp.sr http://cryp.sr + http://corte.si/posts/security/crypsr.html http://corte.si/posts/security/crypsr.html
), and also worked on creating a browser addon that would verify a webpage against a known hash (https://github.com/cortesi/apphash https://github.com/cortesi/apphash).
Here are a couple of HN submissions on cryp.sr which have some discussions on the "Host Proof" concept:
https://news.ycombinator.com/item?id=1438552 https://news.ycombinator.com/item?id=1438552
https://news.ycombinator.com/item?id=1226277 https://news.ycombinator.com/item?id=1226277
- deleted 15y ago[deleted]
- mistercow 15y agoThey actually mention this in the "drawbacks" section of the project page: >Won't protect against Man-in-the-middle attacks (eg. javascript substitution) I think it is pretty much the case that anything that works as man-in-the-middle will also work if an endpoint is compromised.
- gvb 15y agoIf you did not trust the supplied server, you can host the javascript (including the support libraries) on a server you control (and, theoretically, can trust) by making your own web site. I would expect it to be pretty simple to store the data on your server or on a third party server, e.g. S3.
- pfraze 15y agoWould browser-hosted JS solve the problem?
- Jach 15y agoIt's a pedantic note, but I agree they should clarify on their project page that in the event of server compromise only your past data is secure and only if no one accesses past data post-compromise. As usual, encrypt offline with your own unshared private key if you really want it to stay private. I agree with the comment at the top though that the primary utility is the legal predicament it presents.
- muyuu 15y agoComputers with dotjs or greasemonkey could also sneakily get your stuff, being all the compromising code invisible in network traffic and even inspecting the page source. Something to consider if using an untrusted computer (and not just keyloggers and the like).
- yason 15y agoIt not about user security. You can encrypt your data with gpg and send it via pastebin, zerobin, or mailinator to your accomplice and secure. ZeroBin is about lifting the liability off the service provider. Think the tired old "does linking constitute a copyright violation?" question. If someone posts a list of magnet links or torrent URLs to ZeroBin, they can claim plausible deniability: they cannot know the content of the pastes they host. This reduces to deep questions about internet freedom. For example, if ZeroBin couldn't for some legal reason host "infringing" links, they couldn't host any links, and Tor, I2P, Freenet, and other onion/mix networks would be similarly illegal. Or can it be illegal to participate in an anonymous networks or not? Some parties would like to see the answer to be "yes". But we all know that there's copying bits and there's copying bits: at some point it doesn't matter, at some points bits can't be legal or illegal but just bits. Technology like ZeroBin can help drive the liability question down to the very, very basics where it can be eventually solved.