5 ms·

except for a couple of days ago when MegaPWN[1] came to light [1] http://nzkoz.github.io/MegaPWN/ http://nzkoz.github.io/MegaPWN/

simias 13y ago
I think by now everybody's already convinced that any javascript-based crypto is a joke.
- kamjam 13y ago
  It's only a joke if you don't trust the js script. Just like any encryption or software is a joke if it is untrustworthy. Unless you have the source code, it is verified and you compiled yourself, then there is always a point of weakness there. You could say the same about SSL certs and HTTPS on any website, you are blindly trusting VeriSign (or cert authority).
  - pyre 13y ago
    It's not just a matter of trust. If you verified the JS, you could trust it. The issue is that it's very easy to inject things into an HTML page on the fly. It would be like trying to say that you could trust GnuPG, but you download it from the internet and install it every single time that you use it. That's a huge attack surface.
  - rcxdude 13y ago
    But with SSL your root certificates change rarely and you can control them, as well as freeze certificates for specific websites. With Javascript code you don't have that kind of control and if you did it would require a massive change in the approach of creating a webapp in order to be managable. It's not an insurmountable problem though, I would like to see an attempt at solving it (a browser extension would be required, but arguably you could have much greater transparency in updates than even most package managed apps if you used readable JS).
    - kamjam 13y ago
      Fair point, and a browser extension that would detect changes in he script would be easy enough to build. The point is, for the vast majority of users, freezing certs and such is not common (I didn't know you could do that for example) and they would rely on the site to specify the cert to use.
      - lemonade 13y ago
        This is called certificate pinning (a.k.a. Trust On First Use or TOFU). If you use Firefox, just install Certificate Patrol. If you are interested in the rationale, and how you can use technologies like DANE to make it even better, read the paper by Gabor Toth and Tjebbe Vlieg (http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/report.pdf http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/report....).
- Everlag 13y ago
  Oh come one. The issue was with the developer using the environment that browsers present incorrectly and it wasn't an inherent flaw of the language. A stupid/malicious designer will always exploit features of a language to reduce/eliminate the security of the entire system. Don't be hating on js for the sake of hating on js!
  - simias 13y ago
    It's not js that's the issue, it's the fact that the server can change the code at any time without the user being notified. So mega can backdoor its own encryption code at any time to retrieve your keys. It's broken by design, it's not a flaw of js per se.
    - mahyarm 13y ago
      Your mobile & desktop OSes etc all have a silent automatic update mechanism. Installed programs can start services silently and download executable code in the background and use it as they want. And governments take advantage of these facts regularly. That's why they created the browser extension. It might even come signed. At least you can read the source in plain text, unlike a compiled binary.
      - gurkendoktor 13y ago
        Which mobile & desktop OSes do that? The only software that automatically installs updates on my Apple gadgetry seems to be Google Chrome.
        mahyarm 13y ago
        Google play services is one example. Any app can download executable code in the background without you realizing what is happening. Apple has some mechanisms of their own coded in if necessary.
        gurkendoktor 13y ago
- lemonade 13y ago
  With a small caveat for HTML5 apps where you can install a verified version of specific code you trust in your browser or your phone. And Node.js applications which run on the server side in a controllable version. But above is just a nuance. I agree on the basic idea when it comes to Javascript you run in the browser, it is a lost battle - unless I get a SHA256 of every version of every javascript library and compare to that, and disallow other unreadable (random emscripten junk) scripts on random pages you visit while browsing. That is why I have NoScript installed, and only allow handpicked sites to run javascript in the browser. If only we would have had the declarative approach (I still am a little grumpy that the browser makers abandoned W3C and the far better designed declarative technology XHTML2 + XForms to pursue what is now HTML5).
kalleboo 13y ago
They replied to that. Basically: "this was already in our FAQ, use the chrome plugin" https://mega.co.nz/#blog_21 https://mega.co.nz/#blog_21
slynux 13y ago
This is a matter of phishing. Once somebody gets physical access, no matters what, security can be compromised. Mega offers security at server side while all other competitors facilitate spying through programs such as PRISM. Mega as a platform is very secure model. It is just that browser based physical access is prone to attacks. It a very know fact. Nothing to do with Mega's encryption or achitecture.

simias 13y ago

I think by now everybody's already convinced that any javascript-based crypto is a joke.

kamjam 13y ago
It's only a joke if you don't trust the js script. Just like any encryption or software is a joke if it is untrustworthy. Unless you have the source code, it is verified and you compiled yourself, then there is always a point of weakness there. You could say the same about SSL certs and HTTPS on any website, you are blindly trusting VeriSign (or cert authority).
- pyre 13y ago
  It's not just a matter of trust. If you verified the JS, you could trust it. The issue is that it's very easy to inject things into an HTML page on the fly. It would be like trying to say that you could trust GnuPG, but you download it from the internet and install it every single time that you use it. That's a huge attack surface.
- rcxdude 13y ago
  But with SSL your root certificates change rarely and you can control them, as well as freeze certificates for specific websites. With Javascript code you don't have that kind of control and if you did it would require a massive change in the approach of creating a webapp in order to be managable. It's not an insurmountable problem though, I would like to see an attempt at solving it (a browser extension would be required, but arguably you could have much greater transparency in updates than even most package managed apps if you used readable JS).
  - kamjam 13y ago
    Fair point, and a browser extension that would detect changes in he script would be easy enough to build. The point is, for the vast majority of users, freezing certs and such is not common (I didn't know you could do that for example) and they would rely on the site to specify the cert to use.
    - lemonade 13y ago
      This is called certificate pinning (a.k.a. Trust On First Use or TOFU). If you use Firefox, just install Certificate Patrol. If you are interested in the rationale, and how you can use technologies like DANE to make it even better, read the paper by Gabor Toth and Tjebbe Vlieg (http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/report.pdf http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/report....).
Everlag 13y ago
Oh come one. The issue was with the developer using the environment that browsers present incorrectly and it wasn't an inherent flaw of the language. A stupid/malicious designer will always exploit features of a language to reduce/eliminate the security of the entire system. Don't be hating on js for the sake of hating on js!
- simias 13y ago
  It's not js that's the issue, it's the fact that the server can change the code at any time without the user being notified. So mega can backdoor its own encryption code at any time to retrieve your keys. It's broken by design, it's not a flaw of js per se.
  - mahyarm 13y ago
    Your mobile & desktop OSes etc all have a silent automatic update mechanism. Installed programs can start services silently and download executable code in the background and use it as they want. And governments take advantage of these facts regularly. That's why they created the browser extension. It might even come signed. At least you can read the source in plain text, unlike a compiled binary.
    - gurkendoktor 13y ago
      Which mobile & desktop OSes do that? The only software that automatically installs updates on my Apple gadgetry seems to be Google Chrome.
      - mahyarm 13y ago
        Google play services is one example. Any app can download executable code in the background without you realizing what is happening. Apple has some mechanisms of their own coded in if necessary.
        gurkendoktor 13y ago
lemonade 13y ago
With a small caveat for HTML5 apps where you can install a verified version of specific code you trust in your browser or your phone. And Node.js applications which run on the server side in a controllable version. But above is just a nuance. I agree on the basic idea when it comes to Javascript you run in the browser, it is a lost battle - unless I get a SHA256 of every version of every javascript library and compare to that, and disallow other unreadable (random emscripten junk) scripts on random pages you visit while browsing. That is why I have NoScript installed, and only allow handpicked sites to run javascript in the browser. If only we would have had the declarative approach (I still am a little grumpy that the browser makers abandoned W3C and the far better designed declarative technology XHTML2 + XForms to pursue what is now HTML5).

kalleboo 13y ago

They replied to that. Basically: "this was already in our FAQ, use the chrome plugin" https://mega.co.nz/#blog_21 https://mega.co.nz/#blog_21

slynux 13y ago

This is a matter of phishing. Once somebody gets physical access, no matters what, security can be compromised. Mega offers security at server side while all other competitors facilitate spying through programs such as PRISM. Mega as a platform is very secure model. It is just that browser based physical access is prone to attacks. It a very know fact. Nothing to do with Mega's encryption or achitecture.