5 ms·

> Adopt Mega's model where they store the private key, but encrypt it with the user's password and only the browser has the decrypted copy. Unless you're going

by pfg 10y ago

> Adopt Mega's model where they store the private key, but encrypt it with the user's password and only the browser has the decrypted copy. Unless you're going to audit every single line of code Mega uses on their site every time you use it, that would leave you completely vulnerable to any backdoor included in the code (because of a court order or a $5 wrench). Secure E2E Web Crypto is a myth.

diafygi 10y ago
Serious request, what do you think about unhosted client side crypto? https://youtube.com/watch?v=WTPimUSIWbI https://youtube.com/watch?v=WTPimUSIWbI
- nickpsecurity 10y ago
  Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool. Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page: https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.
- pfg 10y ago
  I think something like the self-hosted version (file:///) of this is getting close to something I'd consider safe enough. The backdoor problem from my previous post obviously isn't exclusive to web apps - a large chunk of software we use day to day performs updates automatically, and no one's going to reverse-engineer everything after each update. That being said, the average native app implementing E2E crypto is probably still safer as of today for a number of reasons: Binaries are typically signed by the developer, which isn't something you usually see in a web app using Web Crypto. Signing keys are easier to protect from unauthorized access, compared to your entire web stack. With native apps, you tend to have far more control over code changes. You can chose your own update schedule and review new software versions for any critical component. A typical web app could change the code on every request. Web apps also make it a lot easier to pull off a targeted attack. There's also simply a larger attack surface in general. Anything from XSS to phishing is much easier to pull off in a web app (though, as iMessage showed us, it's not quite that simple). Just think about how much effort browser plugins for password managers have to go through to prevent users from accidentally entering their master passphrase in some phishing form. @chrisfosterelli mentioned the app cache approach of circumventing this - I guess we'll end up with some kind of trusted zone for crypto-related code in browsers, maybe with code signing and what not, sooner or later, and that might get us fairly close to the security of native apps. I don't think we're quite there yet. PS: Thanks for writing acme-tiny!
chrisfosterelli 10y ago
"Secure" anything is a myth, it's about what levels of risk you are willing to accept. The bottom line is that yes, this sort of setup would be worse than PGP email, but it would still be better than traditional web mail which the vast majority of people use. On an interesting aside: You don't have to audit the code every single time. On first execution of the code, it can store itself in the browser's application cache indefinitely, and manage upgrades in the same style as traditional software. This is fairly new ground though :)
- pfg 10y ago
  I'd argue it's not significantly better than any existing product that uses transport-level security without E2E crypto. Both systems are likely to be broken if there's a server-side breach, though I'd admit there's a bit more effort involved for an attacker (planting a backdoor and collecting keys as opposed to just dumping the whole data set).
  - chrisfosterelli 10y ago
    Definitely. I think that's why companies that do this (like SpiderOak and Keybase) implement client-side web crypto for convenience use but provide a pretty visible warning about the potential pitfalls compared to the desktop app, so users can make an informed choice. A lot of people are researching solutions like the app-cache approach to try and fix this, fortunately it's getting better!
- pdkl95 10y ago
  > store itself in the browser's application cache That may solve some of the distribution problems, but no browser-based software can ever be truly secure for a different reason: you have to run the crypto in the same process as the network and parsing code. All browsers have a history of security issues and other bugs in these areas. We should be minimizing attack surface, but browser designers instead decided to add more features that inevitably lead to more bugs. The browser is an incredible "weird machine"[1], and relying on them for security requires believing that nobody will figure out how to program that "weird machine". The solution is something in the style of the "agent" programs[2] for ssh/gpg. The crypto - especially the private keys - must be done in an isolated process, so buffer-overflows and parser bugs at worst leak only the current data. If the crypto is handled in the browser itself, there is always risk that a bug will allow the keys to be leaked. [1] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit... [2] ssh-agent(1), gpg-agent(1)
userbinator 10y ago
I've actually looked at the code Mega uses (mainly for downloading without a browser) and the key is not stored on the server but actually part of the URL fragment, which isn't necessary to be sent to Mega, and decryption happens on the client: https://gist.github.com/KenMacD/6431823 https://gist.github.com/KenMacD/6431823 http://julien-marchand.fr/blog/using-the-mega-api-how-to-download-a-public-file-or-a-file-you-know-the-key-without-logging-in/ http://julien-marchand.fr/blog/using-the-mega-api-how-to-dow... I haven't looked at the upload side but that's an interesting datapoint. Not sure how secure AES128-CTR is.
- pfg 10y ago
  That would avoid transmitting the key to the server, but in the scenario I mentioned, it would still be accessible to the backdoor via window.location.hash.
- colejohnson66 10y ago
  I meant the key to decrypt the user's own folder. That has to be stored on the server so you can access your files from anywhere. But yes, share files/folders keep the key in the window hash, but that's not what I was talking about.
darawk 10y ago
That isn't entirely true. You could easily develop a web extension that validated the hash of the scripts being sent down the wire. Then you'd have an equivalent security guarantee to a normal desktop client.
- deadmaildrop 10y ago
  Or you just inject your own payload and pad the payload until it has a hash collision with the original. At 128M hashes per second you can probably find a payload that works within a day. Since the hashes are published, usually, you know your target so it's just a matter of time.
  - colejohnson66 10y ago
    You do know how hard it would be to find a SHA-256 collision? We haven't even found /one/. Sure, if you used MD5, you could expect a collision, but SHA256?
    - deadmaildrop 10y ago
      I've seen them. Just recently I had a short burst of collisions. It happens. Don't underestimate the resolve of someone who wants to grind an axe.
      - darawk 10y ago
        Lol, no. You have not seen a SHA256 collision. One has never been found, by anyone, ever.
        deadmaildrop 10y ago
        Thanks for calling me a liar. I see the quality of people on this thread has suddenly dropped. So, stick with respectful discourse or keep it to yourself. You are clearly not in the industry, just another useless troll.

by pfg 10y ago

diafygi 10y ago

Serious request, what do you think about unhosted client side crypto? https://youtube.com/watch?v=WTPimUSIWbI https://youtube.com/watch?v=WTPimUSIWbI

nickpsecurity 10y ago
Thanks for bringing the unhosted trend to my attention. I haven't heard of it. I'm a bit skeptical about the graphic in the front page given applications often need to perform computations on the data itself. There's probably something in the site that addresses that. I'll read it in a few days and then maybe look at your tool. Btw, you need to correct the WebCryptoAPI link in "Security and Philosophy" part of this page: https://github.com/diafygi/byoFS https://github.com/diafygi/byoFS Clicking it gives me nothing. Copy-and-pasting the link results that resembles spyware. I think it's just missing a colon after http is all.
pfg 10y ago
I think something like the self-hosted version (file:///) of this is getting close to something I'd consider safe enough. The backdoor problem from my previous post obviously isn't exclusive to web apps - a large chunk of software we use day to day performs updates automatically, and no one's going to reverse-engineer everything after each update. That being said, the average native app implementing E2E crypto is probably still safer as of today for a number of reasons: Binaries are typically signed by the developer, which isn't something you usually see in a web app using Web Crypto. Signing keys are easier to protect from unauthorized access, compared to your entire web stack. With native apps, you tend to have far more control over code changes. You can chose your own update schedule and review new software versions for any critical component. A typical web app could change the code on every request. Web apps also make it a lot easier to pull off a targeted attack. There's also simply a larger attack surface in general. Anything from XSS to phishing is much easier to pull off in a web app (though, as iMessage showed us, it's not quite that simple). Just think about how much effort browser plugins for password managers have to go through to prevent users from accidentally entering their master passphrase in some phishing form. @chrisfosterelli mentioned the app cache approach of circumventing this - I guess we'll end up with some kind of trusted zone for crypto-related code in browsers, maybe with code signing and what not, sooner or later, and that might get us fairly close to the security of native apps. I don't think we're quite there yet. PS: Thanks for writing acme-tiny!

chrisfosterelli 10y ago

"Secure" anything is a myth, it's about what levels of risk you are willing to accept. The bottom line is that yes, this sort of setup would be worse than PGP email, but it would still be better than traditional web mail which the vast majority of people use. On an interesting aside: You don't have to audit the code every single time. On first execution of the code, it can store itself in the browser's application cache indefinitely, and manage upgrades in the same style as traditional software. This is fairly new ground though :)

pfg 10y ago
I'd argue it's not significantly better than any existing product that uses transport-level security without E2E crypto. Both systems are likely to be broken if there's a server-side breach, though I'd admit there's a bit more effort involved for an attacker (planting a backdoor and collecting keys as opposed to just dumping the whole data set).
- chrisfosterelli 10y ago
  Definitely. I think that's why companies that do this (like SpiderOak and Keybase) implement client-side web crypto for convenience use but provide a pretty visible warning about the potential pitfalls compared to the desktop app, so users can make an informed choice. A lot of people are researching solutions like the app-cache approach to try and fix this, fortunately it's getting better!
pdkl95 10y ago
> store itself in the browser's application cache That may solve some of the distribution problems, but no browser-based software can ever be truly secure for a different reason: you have to run the crypto in the same process as the network and parsing code. All browsers have a history of security issues and other bugs in these areas. We should be minimizing attack surface, but browser designers instead decided to add more features that inevitably lead to more bugs. The browser is an incredible "weird machine"[1], and relying on them for security requires believing that nobody will figure out how to program that "weird machine". The solution is something in the style of the "agent" programs[2] for ssh/gpg. The crypto - especially the private keys - must be done in an isolated process, so buffer-overflows and parser bugs at worst leak only the current data. If the crypto is handled in the browser itself, there is always risk that a bug will allow the keys to be leaked. [1] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit... [2] ssh-agent(1), gpg-agent(1)

userbinator 10y ago

I've actually looked at the code Mega uses (mainly for downloading without a browser) and the key is not stored on the server but actually part of the URL fragment, which isn't necessary to be sent to Mega, and decryption happens on the client: https://gist.github.com/KenMacD/6431823 https://gist.github.com/KenMacD/6431823 http://julien-marchand.fr/blog/using-the-mega-api-how-to-download-a-public-file-or-a-file-you-know-the-key-without-logging-in/ http://julien-marchand.fr/blog/using-the-mega-api-how-to-dow... I haven't looked at the upload side but that's an interesting datapoint. Not sure how secure AES128-CTR is.

pfg 10y ago
That would avoid transmitting the key to the server, but in the scenario I mentioned, it would still be accessible to the backdoor via window.location.hash.
colejohnson66 10y ago
I meant the key to decrypt the user's own folder. That has to be stored on the server so you can access your files from anywhere. But yes, share files/folders keep the key in the window hash, but that's not what I was talking about.

darawk 10y ago

That isn't entirely true. You could easily develop a web extension that validated the hash of the scripts being sent down the wire. Then you'd have an equivalent security guarantee to a normal desktop client.

deadmaildrop 10y ago
Or you just inject your own payload and pad the payload until it has a hash collision with the original. At 128M hashes per second you can probably find a payload that works within a day. Since the hashes are published, usually, you know your target so it's just a matter of time.
- colejohnson66 10y ago
  You do know how hard it would be to find a SHA-256 collision? We haven't even found /one/. Sure, if you used MD5, you could expect a collision, but SHA256?
  - deadmaildrop 10y ago
    I've seen them. Just recently I had a short burst of collisions. It happens. Don't underestimate the resolve of someone who wants to grind an axe.
    - darawk 10y ago
      Lol, no. You have not seen a SHA256 collision. One has never been found, by anyone, ever.
      - deadmaildrop 10y ago
        Thanks for calling me a liar. I see the quality of people on this thread has suddenly dropped. So, stick with respectful discourse or keep it to yourself. You are clearly not in the industry, just another useless troll.