91–99 of 99 posts
Earlier quoted context omitted.
The only time you should ever use crypto in the browser is if you're building an end-to-end encrypted app in the browser.
Imagine a diary Web app, for me that would be a perfect use case. It's platform independent and you have automated backups in the Cloud - encrypted though.
Earlier quoted context omitted.
I've written about this, here: http://stackoverflow.com/a/24677597/19212 , in response to the question "Can local storage ever be considered secure?", and in particular using encryption from the SJCL. Here is the gist, copied for convenience: > There are libraries that do implement the desired functionality, e.g. Stanford Javascript Crypto Library. There are inherent weaknesses, though (as referred to in the link fro…
Thanks a lot for your answer, I also read the one on SO. I'm actually thinking to use WebCrypto API for a current (kind of side-)project. I guess if you wrote a blog post about that, that could be really interesting. Until now I only heard "strong no" towards crypto in JS. Even if it's not perfect, if it can be designed towards "better than nothing". Also given that the Web is likely becoming the major platform for e…
Earlier quoted context omitted.
When will we have end-to-end encryption in the browser, is it even possible? Can this be achieved with extensions? What makes this unsafer than, lets say SSH? I mean, it is a software I download from somewhere, just like a browser, so if I trust SSH to encrypt stuff I want, why can't I trust the browser to do the same?
What do you mean by end-to-end encryption? If one end is the browser, and the other end is the server, then we already have end-to-end encryption: https (as long as you don't use a TLS terminating CDN).
For example a social network, where I create messages and encrypt them and only my friends can read them, not the server.
Earlier quoted context omitted.
You typically download SSH once, while you download js potentially on every page load. It is also much harder to monkey-patch a native binary than to inject js into a browser tab. Browsers by default trust any of hundreds of CA's, while SSH trusts none by default.
With service worker, you can have a similar setup to a traditional application (install once, and have the first installed version verify all other versions are signed by a correct key). It's abstracted away from you, but with some work I feel a browser UI could be made to help with this process if people wanted it.
Earlier quoted context omitted.
With service worker, you can have a similar setup to a traditional application (install once, and have the first installed version verify all other versions are signed by a correct key). It's abstracted away from you, but with some work I feel a browser UI could be made to help with this process if people wanted it.
Again, the problem lies in the initial setup. How do you authenticate the very first load, in-browser? You can verify the loaded script, but how can you verify the first page ? (Spoiler: You can't, unlike installing a binary through a modern install system)
It does take some knowhow, and it's not a good ux, but it's possible.
That's where my point of browsers making this easier comes into play. It's possible, and could actually have a pretty good UX, but they would need to build it into the platform.
Earlier quoted context omitted.
You typically download SSH once, while you download js potentially on every page load. It is also much harder to monkey-patch a native binary than to inject js into a browser tab. Browsers by default trust any of hundreds of CA's, while SSH trusts none by default.
With service worker, you can have a similar setup to a traditional application (install once, and have the first installed version verify all other versions are signed by a correct key). It's abstracted away from you, but with some work I feel a browser UI could be made to help with this process if people wanted it.
Earlier quoted context omitted.
Again, the problem lies in the initial setup. How do you authenticate the very first load, in-browser? You can verify the loaded script, but how can you verify the first page ? (Spoiler: You can't, unlike installing a binary through a modern install system)
You are relying on HTTPS for the initial "install", but with subresource integrity you could check that the hash of the initial script matches a known hash that you verify out-of-band (and then of course the browser verifies that the SRI hash matches what is executed) It does take some knowhow, and it's not a good ux, but it's possible. That's where my point of browsers making this easier comes into play. It's possib…
You're handwaving that away as "oh, it's a simple matter of building it into the platform," where "it" is amongst other things a public key infrastructure and a secure software distribution system built with it. Easy peasy, right? (Spoiler: no) Contrast to a binary that's distributed through the platform's install/update system - all this is already built, and there's pretty good assurance that you're not getting a malicious result (signed packages).
Earlier quoted context omitted.
You are relying on HTTPS for the initial "install", but with subresource integrity you could check that the hash of the initial script matches a known hash that you verify out-of-band (and then of course the browser verifies that the SRI hash matches what is executed) It does take some knowhow, and it's not a good ux, but it's possible. That's where my point of browsers making this easier comes into play. It's possib…
I have specifically mentioned SRI - but matching the initial script out-of-band borders on the impossible (or at best "highly improbable"): you need two things, one is easy and one is hard. The easy part is verifying the hash of the initial page - a browser extension could do this (running JS again, oops); and the hard part is a trusted way of obtaining the hash OOB. "Takes some knowhow" doesn't even begin to describ…
It's actually why I like services like keybase so much, they are actually trying to tackle that problem (with their own set of issues, but at least trying).
I was more trying to point out that we can get to where we are now in the browser.
Solving the problem of key distribution and management is way outside the scope of what I was talking about, and it's far from solved by platform install tools.
Earlier quoted context omitted.
> 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…
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…