by nhm on 9/2/13, 10:58 PM with 42 comments
by biot on 9/3/13, 1:16 AM
All files stored on MEGA are encrypted. All data transfers from and
to MEGA are encrypted. And while most cloud storage providers can
and do claim the same, MEGA is different – unlike the industry norm
where the cloud storage provider holds the decryption key, with
MEGA, you control the encryption, you hold the keys, and you decide
who you grant or deny access to your files, without requiring any
risky software installs. It’s all happening in your web browser!
It's true that everything is encrypted. And it's true that many cloud storage providers hold the decryption keys. It's also true that with MEGA, you hold the keys. What they carefully avoid claiming is that MEGA is unable to read the decryption keys.All it takes is one court order in a country where MEGA operates ordering them to obtain the user-held decryption keys via the exact same method this bookmarklet demonstrates. MEGA doesn't even have to be involved. In the US, a National Security Letter to your ISP could lead to a man-in-the-middle attack with the help of an SSL certificate that the government orders a trusted CA to provide for MEGA's domain. At that point, all of MEGA's carefully-crafted claims about security are moot.
by austinz on 9/3/13, 12:07 AM
by doublec on 9/3/13, 12:00 AM
Some way of pinning or signing JavaScript verified by a third party or browser would be useful here. If it could also note what percentage of users was using a particular JS version you'd be more likely to notice if a targeted malicious JS was being sent.
by revelation on 9/3/13, 12:56 AM
The problem here is "the machine doing the cryptography can not be trusted", not "it's JavaScript in a webbrowser", though of course thats also a fundamental problem.
by bug0303 on 9/3/13, 7:48 PM
The bug goes like this: https://mega.co.nz/#!your_file_here!decryption_key In Firefox when you have Javascript disabled via the option or using an add-on like NoScript it will redirect you to: https://mega.co.nz/?_escaped_fragment_=your_file_here!decryp...
So MEGA will recieve the HTTP Request with $_GET['_escaped_fragment_'] containing your decryption key. So if you send a file to a friend who happens to not have Javascript enabled for the website it will reveal the decryption key to MEGA.
To fix the issue all MEGA needs to do is add a double hash like: https://mega.co.nz/##!your_file_here!decryption_key this redirects to https://mega.co.nz/#?_escaped_fragment_=your_file_here!decry... keeping your decryption key safe even if they forget to use Javascript.
by aray on 9/2/13, 11:53 PM
My guess is that it already has, and has been ruled a side-channel/social-engineering attack (requiring either a compromised browser or to run arbitrary javascript on the site).
by SCdF on 9/3/13, 12:59 AM
If you don't trust the server then you can't expect thin client apps served from said server to be trustworthy. It's bizarre to me that people don't get that.
by gnur on 9/3/13, 12:41 PM
by snissn on 9/3/13, 1:18 AM
by liketherest on 9/3/13, 2:04 AM
by NKCSS on 9/3/13, 7:25 AM
[edit] formatting was removed, so this is more readable:
Doesn't work in chrome though.
[edit2] Lol; I just noticed the article actually shows the .js :P I never got past the button and checking what it did :P
by snikch on 9/3/13, 5:28 AM
by oinksoft on 9/2/13, 11:47 PM
by slynux on 9/3/13, 9:29 AM
If you look at Mega API and SDK, design wise it is very clean. You can build your own custom application by importing those libraries which are not prone to this kind of attacks.
by tomrod on 9/3/13, 2:55 AM