Hacker News Reader

Comment by Quiark | Hacker News Reader

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.

View on HN

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.

> 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.

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.

That is well put, probably worth slightly revising your old article to highlight that.

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!

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.

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.

Reply on news.ycombinator.com