Show HN: aes.io - secure storage/collaboration with client-side JS crypto
aes.io
aes.io
The site doesn't address any of the concerns. Why? Well, because they can't. Client-side JS is fundamentally, unfixably insecure.
http://crypto.stanford.edu/sjcl/
I also suggest reading the paper that comes along with the library, addressing several of the common issues like randomness and entropy generation and integer calculations in JavaScript: http://crypto.stanford.edu/sjcl/acsac.pdf
"And if you have SSL, why do you need Javascript crypto? Just use the SSL."
aes.io uses SSL _and_ JS crypto on top of it to make sure server-side data is always encrypted, with keys unkown to the server side.
disclaimer: I'm working on a client-side JS crypto web-app myself :P
And good luck with you app - client-side JS crypto needs more dev attention. :)
Since the whole point of clientside encryption is to prevent the server from compromising data, the fact that the server retains the ability to do this almost defeats the purpose of encrypting.
One is intentional leakage, or trusting the vendor to be "not evil". Here you are right - as you mentioned in another comment, there is no easy way for users to "police" the vendor of JS crypto. I do not see, however, how this is different from users trusting other vendors of auto-updating software.
You can probably argue that OSS pieces such as Linux and FF have this "policing" enabled through source code availability. But there are many closed-source vendors (Microsoft, Google, anti-virus vendors) that many users trust. If you don't trust the companies mentioned above, then yes, you should not trust aes.io and other JS-crypto based vendors. But if a user has Microsoft/Apple updates enabled, and browsers (other than FF) auto-updating on their systems, etc., then this becomes a question of vendor being "not evil", not weaknesses of JS crypto, and as such somewhat out of scope of scrictly "JS crypto - yes or no" discussion.
The second issue here are unintentional leaks and breaches. Read-only breaches, for example, become more or less non-issue with JS crypto, because stealing properly encrypted data is not that useful. And there are probably orders of magnitude more read-only breaches than read-write, simply because inside companies more people have read-only access to production data than read-write access. Thus JS crypto seems to help substantially reduce the risk of unintentional compromises.
The second issue needs more attention and discussion from the technical point of view, I agree, and I am open to it. The first issue, however, becomes "I trust this vendor but I don't trust that vendor", and this is not a discussion that I believe can be productive here and now.
You ask people to use your service because it is more trustworthy than others because it uses (presumably) AES encryption.
Then, when it's pointed out that your service is no more secure than any other service, in that all these services rely entirely on a promise by their operators not to breach privacy, you say "well that's no worse than any other service".
Now, I think there are a bunch of ways in which services like this are worse than other services. But I don't think I need to make that case, because, more importantly, they're not any better.
So, if I understood it correctly the keys are unknown to the server because they are encrypted locally by javascript code which is provided by the very same server. By doing that, aren't you implicitly trusting the server every time you download the JS crypto library from them and assuming they are actually not peeking?
In that scenario, you might as well upload the files without encryption and provide them with the keys (through SSL of course :) ), and still assume that they encrypt it in the server (without peeking) and delete your key plus temporary copy when done...
1. very easy for MITM-type attacks: this is negated by using SSL
2. JavaScript is too "malleable" for crypto - this argument is not very clear; yes, JS is "malleable" - so what, if we can be reasonably sure it is not "infected", by using server-side tools like signatures and SSL? This is highly debatable...
3. server breaches easily propagate to users: this is a real issue, but it is a real issue with many products that auto-update themselves, such as OSes (with patches/updates), browsers, anti-viruses, etc. Thus although this is a valid concern, it is part of everyday life of most Internet users,and not something JS crypto is specifically bad at.
I've read the Matasano article, don't assume I didn't. Most of the points in it are negated by controlling the page 100% and using SSL.
Why not just have the users send you their plaintext, and rely on SSL/TLS for the rest of your security? It seems like that provides effectively the same security.
You keep saying that you mitigate this problem by controlling your pages 100%. Congratulations, you have gone farther than many of the JS crypto apps I've looked at; many of those bug their pages with Google Analytics, or with Typekit.
But that doesn't mitigate the problem that your users can't police you. They are relying entirely on your promise not to deploy code that will surreptitiously defeat the security of AES (or whatever ciphers you're using). And because JS is malleable, it is untenably hard even for an expert to attempt to validate your code by hand.
If your site is entirely self-contained and transported in full over https with a trustable ssl certificate and your users are using reasonably secure passwords and run browsers with addons that respect the confidentiality of https communication then client-side js encryption might be a nice extra layer of data protection.
It won't protect against the government probing, and it won't protect against a passionate lulz hacker.
The government can always subpoena the host website, and force it to fetch the password from the user, thereby comprimising their data. The government also has access to ssl certificates so it could even do this without notifying the host website. You may assume that lulz hackers have similar capabilities.
If you think about it straight, the only way this can be truly secure is with a browser extension that digitally signs and versions _all_ javascript on a website, and the signing is done by a fully trusted third party (which arguably don't exist).
Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.
Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.
(btw I don't mean that command execution is not a problem, I mean that if you configure your sql server well it should not allow command execution, there's not _that_ many ways to escape the database..)
Thomas is right, though: if you lose the DB, you're forked.
Um, I don't think so. Client side JS is very good at doing SQLi. How on earth does client-side encryption mitigate against SQLi?
I asked about the library/implementation used and it is BouncyCastle compiled/convertered to JS using GWT.
The common discussion/blog references I've also pointed out but for everyone else have a look at these: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... and http://www.matasano.com/articles/javascript-cryptography/ .
But we also go out of our way to discuss JS cryptography as an alternative to HTTPS, because that is how many people use it; for instance, to do challenge-response authentication for "secure login" without needing SSL.
But that's a sideshow on this thread. The article squarely addresses exactly the application you've built, and in detail.
The article lists three reasons for why "JS crypto is bad" at the beginning:
- Secure delivery of Javascript to browsers is a chicken-egg problem. - Browser Javascript is hostile to cryptography. - The "view-source" transparency of Javascript is illusory.
The first issue is addressed by using SSL and controlling the page 100%. The third issue becomes a matter of trust, as many users trust closed-source vendors, so in an environment where closed-source vendors are truested (e.g. a typical accounting firm), the third issue becomes not about JS crypto but about vendor reliability.
That leaves the second issue. The article expands it as:
- The prevalence of content-controlled code. - The malleability of the Javascript runtime. - The lack of systems programming primitives needed to implement crypto. - The crushing weight of the installed base of users.
The first and second sub-issues, again, are more or less addressed by using SSL and controlling the page, I believe. One can argue that because JS is so "malleable", it is very easy to add malicious code to a page. Yes, it is easy if you have access to it (via third-party scripts/XSS), but it is _harder_ to infect a JS crypto page that is properly set up than a regular online-banking page, for example, as most online banking pages have links to third-party advertising (often over plain HTTP!). So in the world where people and companies do online banking, the "malleability" does not seem to add a lot of issues.
The third sub-issue is being addressed in HTML5 and/or, via SSL, round-trips to the server (for random seeding, for example).
The fourth issue is, again, not much different from online banking.
In summary, it seems we are using somewhat different criteria of what "secure JS crypto" means. You seem to be saying that storing data in aes.io is less secure than in a truecrypt volume. I agree 100%. But what I am saying is that for an accounting firm that does online banking on a daily basis, using aes.io as opposed to a cloud collaboration service without client-side encryption would probably be a great idea.
The problem here is that the core value proposition of services like this one are "you can put your documents here even if you don't trust the operators".
But that, as it turns out, simply isn't true. You are exactly as reliant on the operators of aes.io as you are on the operators of Dropbox.
I've submitted to HN but didn't make the front page, check it out if you're interested in this stuff.