5 ms·

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIK

by meshko 13y ago

Obligatory quote from http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY? SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document. SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young. The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.

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 ago
    You 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 ago
      The 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)
- deleted 13y ago
  [deleted]
Everlag 13y ago
Perhaps the key to crypto in the browser would be to implement it in extensions rather than on webpages? Extensions run in a higher level of security clearance, are sandboxed from the rest of the page, and are much more intolerant of code injection.
- zellyn 13y ago
  http://techblog.netflix.com/2013/07/nfwebcrypto-web-cryptography-api-native.html http://techblog.netflix.com/2013/07/nfwebcrypto-web-cryptogr...
- jonknee 13y ago
  Built into the browser would be even better (like SSL).
- oscargrouch 13y ago
  downloading and executing code on the fly as in the web browser its a broken design problem.. browsers are being patched for a long time now.. to fit into sophisticated models.. it came all over here, by using duct tape.. but now it can be patched anymore to get into the next level.. it cant reach the next level because its broken by design. how long until people face the reality?
malandrew 13y ago
What if the sites used SJCL by default, but urged the user to install an official browser plugin that detects the presence of SJCL on a page and falls back to the browser's own copy of SJCL, always trusting it over any copy sent over the wire. It's not perfect but at least gives users a stepping stone to secure communications. The biggest problem with getting users to adopt crypto is giving them stepping stones to something better, and giving them subtle explanations of risks with lesser involved approaches. I understand the fear of giving the user a false sense of security. We should try to mitigate doing so, while still giving a path to adopt best crypto practices over time. Wholesale adoption of crypto by society is only going to happen when people promoting crypto realize that crypto, like everything else competing for the attention of users has a conversion funnel.
- jorgeleo 13y ago
  Steve Jobs is turning in his thumb... you just suggested the p word
- sneak 13y ago
  Then instead of backdooring the sjcl, the malware would just steal the plaintext out of the DOM or hook into keystroke handlers. The problem is JavaScript.
pdubs 13y ago
It's useful if you store things in local storage.
deleted 13y ago
[deleted]
feral 13y ago
Matasano are experts here; I'm not; but here's my argument: There's parts of their post that I don't like: "If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." I wonder about the implicit threat model. Its too black-and-white for me. In it, you either trust the server or you don't. But security and privacy, for me, for large numbers of users, is all tradeoffs and games, shades of grey. Consider: maybe our computers are uploading the private files of everyone who runs Windows to Microsoft. I don't know for sure, but I'd gamble that they aren't. I don't think MS would they take the risk of some security researcher catching the anomalous traffic on the network. The threat of the resulting PR storm would help keep MS honest, at that scale. So I'd expect MS would try pretty hard to fight a government leaning on them to do that. Lets say that, in future, all data on the worlds most popular social network is encrypted client side. My ID is just a public key, and my browser encrypts all my traffic, using a JS package the social network securely delivers me. (Over SSL. With great care.) That'd be a similar scenario to MS. I'd be trusting them when I enter my password into the JS they sent me, that is running in my browser. But, again, I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone, probably some security researcher would call them on it. And so, they'd be incentivised not to. That's a fundamentally different situation to the current one, where if Facebook gives all our data away, its pretty hard for someone outside their organisation to find out. Probably they could gamble on keeping it secret. So that's why I think the 'Javascript Considered Harmful' post is too strong, in its "you either trust the server or you don't" attitude. I also think that we aren't going to get anyone using crypto, unless its delivered seamlessly in the browser. There has been good crypto available for years (e.g. GPG on the deskop plugged into thunderbird). But I think we've learned that if its even slightly harder to use, then end users are going to ignore it. And the way to deliver seamless ease-of-use to a wide audience is on the web. And we badly need easy-to-use privacy these days. So I think it'd be a shame if posts like that discouraged research into JS crypto. (I can think of other arguments: e.g. where you want to trust a server now (e.g. to encrypt and backup a document) but decide not to trust it later (decide to abandon the document because in the years since you uploaded it, you think the server/company is compromised - or you ask to be e-mailed the ciphertext) or regulatory differences: I don't think its the same thing legally to demand or steal a copy of someones server side data, and any server side keys, as it is to demand that the javascript be changed to snoop future passwords as users enter them into their browser application?) Again, I'm no expert in this area; corrections welcome.

by meshko 13y ago

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 ago
  You 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 ago
    The 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)
deleted 13y ago
[deleted]

Everlag 13y ago

Perhaps the key to crypto in the browser would be to implement it in extensions rather than on webpages? Extensions run in a higher level of security clearance, are sandboxed from the rest of the page, and are much more intolerant of code injection.

zellyn 13y ago
http://techblog.netflix.com/2013/07/nfwebcrypto-web-cryptography-api-native.html http://techblog.netflix.com/2013/07/nfwebcrypto-web-cryptogr...
jonknee 13y ago
Built into the browser would be even better (like SSL).
oscargrouch 13y ago
downloading and executing code on the fly as in the web browser its a broken design problem.. browsers are being patched for a long time now.. to fit into sophisticated models.. it came all over here, by using duct tape.. but now it can be patched anymore to get into the next level.. it cant reach the next level because its broken by design. how long until people face the reality?

malandrew 13y ago

What if the sites used SJCL by default, but urged the user to install an official browser plugin that detects the presence of SJCL on a page and falls back to the browser's own copy of SJCL, always trusting it over any copy sent over the wire. It's not perfect but at least gives users a stepping stone to secure communications. The biggest problem with getting users to adopt crypto is giving them stepping stones to something better, and giving them subtle explanations of risks with lesser involved approaches. I understand the fear of giving the user a false sense of security. We should try to mitigate doing so, while still giving a path to adopt best crypto practices over time. Wholesale adoption of crypto by society is only going to happen when people promoting crypto realize that crypto, like everything else competing for the attention of users has a conversion funnel.

jorgeleo 13y ago
Steve Jobs is turning in his thumb... you just suggested the p word
sneak 13y ago
Then instead of backdooring the sjcl, the malware would just steal the plaintext out of the DOM or hook into keystroke handlers. The problem is JavaScript.

pdubs 13y ago

It's useful if you store things in local storage.

deleted 13y ago

[deleted]

feral 13y ago

Matasano are experts here; I'm not; but here's my argument: There's parts of their post that I don't like: "If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code." "How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL." I wonder about the implicit threat model. Its too black-and-white for me. In it, you either trust the server or you don't. But security and privacy, for me, for large numbers of users, is all tradeoffs and games, shades of grey. Consider: maybe our computers are uploading the private files of everyone who runs Windows to Microsoft. I don't know for sure, but I'd gamble that they aren't. I don't think MS would they take the risk of some security researcher catching the anomalous traffic on the network. The threat of the resulting PR storm would help keep MS honest, at that scale. So I'd expect MS would try pretty hard to fight a government leaning on them to do that. Lets say that, in future, all data on the worlds most popular social network is encrypted client side. My ID is just a public key, and my browser encrypts all my traffic, using a JS package the social network securely delivers me. (Over SSL. With great care.) That'd be a similar scenario to MS. I'd be trusting them when I enter my password into the JS they sent me, that is running in my browser. But, again, I'd figure that if they were injecting JS to steal my password, or subtly poison my RNG, and if they were doing that to everyone, probably some security researcher would call them on it. And so, they'd be incentivised not to. That's a fundamentally different situation to the current one, where if Facebook gives all our data away, its pretty hard for someone outside their organisation to find out. Probably they could gamble on keeping it secret. So that's why I think the 'Javascript Considered Harmful' post is too strong, in its "you either trust the server or you don't" attitude. I also think that we aren't going to get anyone using crypto, unless its delivered seamlessly in the browser. There has been good crypto available for years (e.g. GPG on the deskop plugged into thunderbird). But I think we've learned that if its even slightly harder to use, then end users are going to ignore it. And the way to deliver seamless ease-of-use to a wide audience is on the web. And we badly need easy-to-use privacy these days. So I think it'd be a shame if posts like that discouraged research into JS crypto. (I can think of other arguments: e.g. where you want to trust a server now (e.g. to encrypt and backup a document) but decide not to trust it later (decide to abandon the document because in the years since you uploaded it, you think the server/company is compromised - or you ask to be e-mailed the ciphertext) or regulatory differences: I don't think its the same thing legally to demand or steal a copy of someones server side data, and any server side keys, as it is to demand that the javascript be changed to snoop future passwords as users enter them into their browser application?) Again, I'm no expert in this area; corrections welcome.