4 ms·

Browser crypto is really problematic. For one, the client is downloading the crypto JS implementation (almost) every time they are using the app. Server comprom

by Quiark 10y ago

Browser crypto is really problematic. For one, the client is downloading the crypto JS implementation (almost) every time they are using the app. Server compromised? crypto.js is rendered useless. HTTPS certificate compromised? crypto.js is useless. And also: XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. The browser is wonderful for UI but mashing together code and markup and then trying to permissively parse and execute it never goes well for security.

baby 10y ago
> For one, the client is downloading the crypto JS implementation (almost) every time they are using the app Not in the case of browsers' extensions or Electron/NW.js apps. > XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. It's not like buffer overread and other vulns don't exist in the non-browser world. Also, a huge amount of XSS vulns can be avoided by having a good CSP config. Now I'm not supporting javascript crypto. Just responding to some of your points. Inb4 some crypto SJW quotes me on that.
- tptacek 10y ago
  I think it's important to decouple Javascript the language, Javascript the runtime, and the browser security model from each other. Javascript --- the language and the runtime --- aren't ideal environments in which to do crypto, but they're not untenable. It's the browser --- not the browser shell, running as a standalone application as in Electron, but the actual Chrome browser that fetches things from URLs --- that makes crypto untenable.
  - newscasta 10y ago
    Tangentially related (and this conversation might have moved on already) but I'd be curious to hear your view on 1password's sync service. I know you like and use 1password standalone. Do you have a recommendation for how to sync across devices? Thanks!
  - homakov 10y ago
    That is well put, probably worth slightly revising your old article to highlight that.
gregmac 10y ago
Do you even trust the site to actually do what it says? After all, a web application is just [someone else's] code running on your system. Even if it's secure against XSS, HTTPS is intact, etc, you are ultimately putting presumably sensitive data into code someone else wrote and then allowing it to run on your machine with explicit network access. The crypto implementation may be flawed, or the developer may even send your private key up or other data that you don't expect it to be sending (whether it is out of lack of understanding, accident or malice). It would be nearly impossible for you to spot if it's just sent as part of the big blob of encrypted data you expect it to be sending. The blob being bigger than you expect might be a clue, but the only way to know for sure is to audit the code, and if the code if obfuscated/minimized that could be quite the task in itself. This is really not a problem of browser crypto at all; this is a problem of trust of the code you're executing and using.
beagle3 10y ago
This is true. The value that in-browser JavaScript crypto does provide, however, is that it requires a MITM attack (which is definitely possible, especially for state level actors, but by anyone with enough control of a trusted CA); It is useful against dragnet recording of all communications - as long as the key/password itself is safe.
technion 10y ago
As much as the facts you've listed are generally accepted, there's grey areas between the "Browser crypto is good" and "browser crypto is bad" that are worth considering. I'm working on a form submission that I know is going to be used by a lot of enterprise clients, in many cases with passive MiTM SSL devices. Browser based crypto can prevent the contents of that form leaking to a passive firewall admin, and the very real issues you've raised don't apply to the threat I'm interested in resolving. Now if I had a marketing team go off and call it "military grade end to end encryption" we'd have a problem, but I won't be letting that happen.

by Quiark 10y ago

baby 10y ago

> For one, the client is downloading the crypto JS implementation (almost) every time they are using the app Not in the case of browsers' extensions or Electron/NW.js apps. > XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. It's not like buffer overread and other vulns don't exist in the non-browser world. Also, a huge amount of XSS vulns can be avoided by having a good CSP config. Now I'm not supporting javascript crypto. Just responding to some of your points. Inb4 some crypto SJW quotes me on that.

tptacek 10y ago
I think it's important to decouple Javascript the language, Javascript the runtime, and the browser security model from each other. Javascript --- the language and the runtime --- aren't ideal environments in which to do crypto, but they're not untenable. It's the browser --- not the browser shell, running as a standalone application as in Electron, but the actual Chrome browser that fetches things from URLs --- that makes crypto untenable.
- newscasta 10y ago
  Tangentially related (and this conversation might have moved on already) but I'd be curious to hear your view on 1password's sync service. I know you like and use 1password standalone. Do you have a recommendation for how to sync across devices? Thanks!
- homakov 10y ago
  That is well put, probably worth slightly revising your old article to highlight that.

gregmac 10y ago

Do you even trust the site to actually do what it says? After all, a web application is just [someone else's] code running on your system. Even if it's secure against XSS, HTTPS is intact, etc, you are ultimately putting presumably sensitive data into code someone else wrote and then allowing it to run on your machine with explicit network access. The crypto implementation may be flawed, or the developer may even send your private key up or other data that you don't expect it to be sending (whether it is out of lack of understanding, accident or malice). It would be nearly impossible for you to spot if it's just sent as part of the big blob of encrypted data you expect it to be sending. The blob being bigger than you expect might be a clue, but the only way to know for sure is to audit the code, and if the code if obfuscated/minimized that could be quite the task in itself. This is really not a problem of browser crypto at all; this is a problem of trust of the code you're executing and using.

beagle3 10y ago

This is true. The value that in-browser JavaScript crypto does provide, however, is that it requires a MITM attack (which is definitely possible, especially for state level actors, but by anyone with enough control of a trusted CA); It is useful against dragnet recording of all communications - as long as the key/password itself is safe.

technion 10y ago

As much as the facts you've listed are generally accepted, there's grey areas between the "Browser crypto is good" and "browser crypto is bad" that are worth considering. I'm working on a form submission that I know is going to be used by a lot of enterprise clients, in many cases with passive MiTM SSL devices. Browser based crypto can prevent the contents of that form leaking to a passive firewall admin, and the very real issues you've raised don't apply to the threat I'm interested in resolving. Now if I had a marketing team go off and call it "military grade end to end encryption" we'd have a problem, but I won't be letting that happen.