4 ms·
You may be interested in the defensive js (http://www.defensivejs.com/ http://www.defensivejs.com/) project which seeks to securely isolate JavaScript code from
by gcommer 13y ago
You may be interested in the defensive js (http://www.defensivejs.com/ http://www.defensivejs.com/) project which seeks to securely isolate JavaScript code from maliscous javascript being injected on the page. It also provides a verified crpyto library implementation.
Combine this with HTTPS and I think doing the crypto on the client is certainly feasible (and has been implemented by mega (well, they messed up a few things, but that was an issue in their use of crypto, not the crypto implementation) and 0bin).
EDIT:
Also, the site you are quoting is explicitly complaining about people using JavaScript security but NOT over HTTPs, and they claim that there is no advantage to using JavaScript crypto when you are using TLS anyways. This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ http://xkcd.com/792/
- __alexs 13y ago> It also provides a verified crpyto library implementation. Verified by who?
- anon1385 13y ago>This is wrong, because using both means that the web service we are using (for example) never knows our plaintext password, so they can't attack us under the assumption of password reuse, like in http://xkcd.com/792/ http://xkcd.com/792/ TLS doesn't protect you against a malicious site that is collecting passwords. Even if you were to examine the javascript code to verify that it isn't sending the plaintext[1], they could send a different chunk of code any time you access the site in the future. Either because the site is malicious -- as in the above example -- or because it has been compromised (whether that be by skiddies or three letter agencies with legal papers). The only 'benefit' javascript crypto gives you is that it makes it easier for people to develop apps where the users data is encrypted before it is sent to the server (such that the server can never decrypt it). However doing this in a javascript web app totally negates that since the server can just send a compromised chunk of js any time it feels like. So the additional security to the user is basically zero. If you want to seriously create a service like this don't use javascript inside the browser. Do what Tarsnap does: provide an open source native client that does not automatically update. [1] and let's not pretend that modern javascript is at all readable, in the age of minification and asm.js
- 3JPLW 13y agoYou must always trust something. In the case of a SpiderOak-like service, you must trust one of their client implementations to use it. Whether it is their compiled binary (which isn't even open source[0] "yet") or a javascript client in the browser delivered securely. Even in the case of tarsnap, with open source implementations that don't self-update, you must trust your own code review or somebody else's -- not a trivial task. [0]. https://spideroak.com/faq/questions/35/why_isnt_spideroak_open_source_yet_when_will_it_be/ https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...
- gcommer 13y agoThe point anon1385 is trying to make about JavaScript clients is that they can be changed at any time by the web service provider, where as open source clients can be 'verified' once by the open source community and then can't be easily changed by the service provider (unless they have an auto updater, which Tarsnap does not)
- 3JPLW 13y agoAh, very good point. And the provider can send uniquely compromised versions to individuals to reduce their chance of detection, as well.
- deleted 13y ago[deleted]