6 ms·

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation

Could anyone explain what's the use case for encrypting text on a web page using JavaScript? I don't understand how this library is useful except for situation when used in Chrome extensions like the one used by LastPass. If this lib is used on a page to decrypt/encrypt user data before sending to the server, theoretically it's possible for the host to steal private key simply by injecting a JS code that copies user's private key.

netnichols 15y ago
The first thought I had was to be able to store personal data on a server and have secure access from any web browser. Basically a simplified version of 1PasswordAnywhere (http://help.agilebits.com/1Password3/1passwordanywhere.html http://help.agilebits.com/1Password3/1passwordanywhere.html). Update: I should probably note that I haven't looked at the implementation, and there's no way I'd do as I mention above without having complete control of sources.
clintjhill 15y ago
Maybe not encrypting text on a page, but possibly to encrypt JSON data to local storage for persistence. Never do this with absolutely private data, but then again.
tptacek 15y ago
It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to implement crypto in, and you should never do it.
- DenisM 15y ago
  XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.
  - tptacek 15y ago
    The difference between normal software and browser javascript is that browser javascript is effectively re-installed every time you visit a web page. People install new software packages less than once a week. This is a nerdy argument I'm not particularly interested in hashing out again, so you're welcome to the last word.
  - thaumaturgy 15y ago
    Your argument here looks like, "other things have vulnerabilities, and JavaScript has vulnerabilities, so it is equivalent to other mechanisms." If that is your argument, then the conclusion is wrong, because JavaScript implementations are vulnerable to everything that everything else is vulnerable to, and then some. There is nothing that a JavaScript implementation actually protects you from.
    - DenisM 15y ago
      That's not my argument at all. My argument is that the probability of a well-designed site having XSS (p1) is much less than that of a user's machine being infested (p2). When you start using both, as you say, we end up with compound probability of a breach p1+p2, which is strictly worse than p2, but if p1<<p2 we are not losing much to begin with, and it maybe justified if we're gaining as much or more elsewhere. In other words, global optimization may require local pessimization. E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file. However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service.
      - thaumaturgy 15y ago
        > ...and it maybe justified if we're gaining as much or more elsewhere. Except that, in terms of real security, we aren't. That's the whole point. You're right in describing it in the way you did, but then you get to this point where there's this implicit assumption that JavaScript-based crypto gains you something. Which, maybe, leads into your next point... > E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file. OK, but this is a different problem. The correct solution here is a true client-side app or a browser add-on (and even then ... ehhhh). Otherwise -- and this is a point that I don't feel like I can emphasize enough -- you are giving your users a completely false sense of security. You're selling a service by saying that "we'll store your secrets for you and you don't even have to ever give us your key, so it's more secure than keeping them in a notepad file", but that's demonstrably false. > However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service. Also a different problem. You can't sell security this way. All you're doing is taking advantage of people's ignorance. If everybody understood the security risks of JavaScript-implemented crypto, and you sold the same service -- "we use JS so you never have to share your keys" -- then the users would decide not to use the service! To reiterate: 1. Server-side encryption is a real protection from accidental or malicious data leaks (db dumps); 2. SSL is a real protection from MITM and eavesdropping (mostly, with caveats); 3. If the server software gets compromised, you're pooched no matter what. So, again: JavaScript solves none of these problems. The only thing that JavaScript does, is add more problems.
- xfax 15y ago
  How is this any different from a XSS bug resulting in an attacker stealing the plaintext password from a form? Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?
  - thaumaturgy 15y ago
    If the client and the server can trust each other, then JavaScript encryption literally adds no benefit. Think of it this way: your browser contains some areas whose sole responsibility is to verify the authenticity of a remote server (SSL), and those areas are completely inaccessible from the DOM. So, basically, as long as you can trust your web browser, then you can trust the connection. But those protections don't exist for JavaScript. An attacker could compromise your server, rewrite your JS, and you'd never notice. (No JS signing capabilities in the browser; no TOFU/POP style architecture.) An attacker could use an SQL injection on your CMS to leave a comment that uses XSS to modify your JS encryption while it's running, and you'd never notice. You could be on an unsecured network and someone could MITM rewrite your JavaScript in-flight, or, in the cases of bad JS crypto implementations (which almost every single one is), simply use a replay attack at their leisure. There are all kinds of really neat ways to attack JavaScript. It's true that there are also almost as many ways to attack any other authentication/encryption system, but the point with attacks against JavaScript is that JavaScript adds no extra security at all -- it is at least as vulnerable to any of these as anything else is -- and it adds a false sense of security, and it is vulnerable to things that SSL is not, and in some of the scenarios, you will get absolutely no indication that you've been compromised. It's just security theatre.
DenisM 15y ago
Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to be not trustworthy, and have been harvesting the keys all along. 2. The hackers took control of the server and injected code to harvest the encryption keys for long enough to catch you in the net. If you look at the relative probabilities of these two events compared to a straight-up data leak, we're looking at orders of magnitude reduction in risk. Most people who did the right thing in the past are in the habit of doing the right things, so you can lean on the host's reputation - we've been doing that for thousands of years. Code injection on the site is much less likely than the data leak, and it is a lot less fruitful for the attacker as he would have to sit there undetected and wait for enough users to punch in their keys.
- antihero 15y ago
  Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.
  - thaumaturgy 15y ago
    No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more, and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.
    - antihero 15y ago
      Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?

netnichols 15y ago

The first thought I had was to be able to store personal data on a server and have secure access from any web browser. Basically a simplified version of 1PasswordAnywhere (http://help.agilebits.com/1Password3/1passwordanywhere.html http://help.agilebits.com/1Password3/1passwordanywhere.html). Update: I should probably note that I haven't looked at the implementation, and there's no way I'd do as I mention above without having complete control of sources.

clintjhill 15y ago

Maybe not encrypting text on a page, but possibly to encrypt JSON data to local storage for persistence. Never do this with absolutely private data, but then again.

tptacek 15y ago

It's worse than that. Among many other things, it's possible for any attacker with an XSS bug in any component of the DOM of that page (cached or fetched fresh) to steal keys. Modern browsers provide no way to verify the whole JS runtime to ensure that no function that your crypto depends on has been backdoored, but every JS implementation allows functions to be overridden. It's the worst possible environment to implement crypto in, and you should never do it.

DenisM 15y ago
XSS is in your own control (as a site owner/developer), and it is less likely to happen than the user machine being infested with malware to begin with. And the malware infestation threat has never stopped anyone from advocating native (non-browser) crypto, right?.
- tptacek 15y ago
  The difference between normal software and browser javascript is that browser javascript is effectively re-installed every time you visit a web page. People install new software packages less than once a week. This is a nerdy argument I'm not particularly interested in hashing out again, so you're welcome to the last word.
- thaumaturgy 15y ago
  Your argument here looks like, "other things have vulnerabilities, and JavaScript has vulnerabilities, so it is equivalent to other mechanisms." If that is your argument, then the conclusion is wrong, because JavaScript implementations are vulnerable to everything that everything else is vulnerable to, and then some. There is nothing that a JavaScript implementation actually protects you from.
  - DenisM 15y ago
    That's not my argument at all. My argument is that the probability of a well-designed site having XSS (p1) is much less than that of a user's machine being infested (p2). When you start using both, as you say, we end up with compound probability of a breach p1+p2, which is strictly worse than p2, but if p1<<p2 we are not losing much to begin with, and it maybe justified if we're gaining as much or more elsewhere. In other words, global optimization may require local pessimization. E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file. However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service.
    - thaumaturgy 15y ago
      > ...and it maybe justified if we're gaining as much or more elsewhere. Except that, in terms of real security, we aren't. That's the whole point. You're right in describing it in the way you did, but then you get to this point where there's this implicit assumption that JavaScript-based crypto gains you something. Which, maybe, leads into your next point... > E.g. if we gave the user ability to store secret data without the key ever leaving his possession, he might be more likely to use the service and stop storing his secrets in a notepad file. OK, but this is a different problem. The correct solution here is a true client-side app or a browser add-on (and even then ... ehhhh). Otherwise -- and this is a point that I don't feel like I can emphasize enough -- you are giving your users a completely false sense of security. You're selling a service by saying that "we'll store your secrets for you and you don't even have to ever give us your key, so it's more secure than keeping them in a notepad file", but that's demonstrably false. > However if we don't guarantee that the key will not leave the user's possession, the user may decide not to use the service. Also a different problem. You can't sell security this way. All you're doing is taking advantage of people's ignorance. If everybody understood the security risks of JavaScript-implemented crypto, and you sold the same service -- "we use JS so you never have to share your keys" -- then the users would decide not to use the service! To reiterate: 1. Server-side encryption is a real protection from accidental or malicious data leaks (db dumps); 2. SSL is a real protection from MITM and eavesdropping (mostly, with caveats); 3. If the server software gets compromised, you're pooched no matter what. So, again: JavaScript solves none of these problems. The only thing that JavaScript does, is add more problems.
xfax 15y ago
How is this any different from a XSS bug resulting in an attacker stealing the plaintext password from a form? Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?
- thaumaturgy 15y ago
  If the client and the server can trust each other, then JavaScript encryption literally adds no benefit. Think of it this way: your browser contains some areas whose sole responsibility is to verify the authenticity of a remote server (SSL), and those areas are completely inaccessible from the DOM. So, basically, as long as you can trust your web browser, then you can trust the connection. But those protections don't exist for JavaScript. An attacker could compromise your server, rewrite your JS, and you'd never notice. (No JS signing capabilities in the browser; no TOFU/POP style architecture.) An attacker could use an SQL injection on your CMS to leave a comment that uses XSS to modify your JS encryption while it's running, and you'd never notice. You could be on an unsecured network and someone could MITM rewrite your JavaScript in-flight, or, in the cases of bad JS crypto implementations (which almost every single one is), simply use a replay attack at their leisure. There are all kinds of really neat ways to attack JavaScript. It's true that there are also almost as many ways to attack any other authentication/encryption system, but the point with attacks against JavaScript is that JavaScript adds no extra security at all -- it is at least as vulnerable to any of these as anything else is -- and it adds a false sense of security, and it is vulnerable to things that SSL is not, and in some of the scenarios, you will get absolutely no indication that you've been compromised. It's just security theatre.

DenisM 15y ago

Suppose you want to store confidential data with the server. You trust the server owners to be the good guys, but you also know that data breaches happen (e.g. equipment theft, FBI seizures, backup tape leaks), so if/when the breach happens the thieves will have made off with encrypted copy of your data. The only way your data is jeopardized is one of the two cases: 1. The people maintaining the service turned out to be not trustworthy, and have been harvesting the keys all along. 2. The hackers took control of the server and injected code to harvest the encryption keys for long enough to catch you in the net. If you look at the relative probabilities of these two events compared to a straight-up data leak, we're looking at orders of magnitude reduction in risk. Most people who did the right thing in the past are in the habit of doing the right things, so you can lean on the host's reputation - we've been doing that for thousands of years. Code injection on the site is much less likely than the data leak, and it is a lot less fruitful for the attacker as he would have to sit there undetected and wait for enough users to punch in their keys.

antihero 15y ago
Exactly. You can never be completely secure, but this mitigates against a large amount of potential problems.
- thaumaturgy 15y ago
  No, it doesn't. JS implementations suffer from all the same flaws that everything else does, plus a few more, and it offers no protection from any flaws that anything else is vulnerable to. "You can never be completely secure" is not a good justification for security theatre.
  - antihero 15y ago
    Well not really, because if you can verify the scripts that are loaded (and side-loading JavaScript would have to be a targeted attack that compromised either the server, or the Google API, or a malicious extension), then it guarantees end-to-end encryption for the user as opposed to having to send plaintext over the wire. How exactly would you implement a browser based crypto solution?