The "If you can break SSL, you can break MEGA." made my day. I think MEGA is the least of your worries if SSL is broken; credit card transactions would be compromised big time.
I have no doubt that some of the criticism is rooted in just a general hatred and cynicism about "kim.com" and has no foundation, but some of the things they're doing are legitimately questionable. Like having javascript served from their servers have access to your password. If you want it to be secure against them, you can't really do that. If they get compromised then their server will serve compromised javascript and your data can be read by the attackers the next time you access it.
But it's a trade off -- using javascript has somewhat lower security but is easier for users to use -- and it seems like they even recognize it. The way around it is to use a community-verified open source client (like a browser plug in) to process users' passwords and never leave them or the unencrypted data in the control of code from the Mega server, and it appears they have plans to do that. And that has other benefits as well, like making it easy to use high entropy machine-generated passwords for every piece of data and having the plug in store the passwords encrypted on your local disk with a master secret, so that you only have to remember one strong password for all your data (or, if you're paranoid, one password for each set of data classified by security level).
>The "If you can break SSL, you can break MEGA." made my day.
Yeah, is that actually not a straw man? Someone really said that? I have to hope they were being sarcastic.
> But the problem goes beyond trusting Mega’s servers, says cryptographer Moxie Marlinspike, who recently left a position as head of product security for Twitter. Browser-based cryptography also means that anyone who breaks the SSL encryption that protects the data sent by the server could tamper with the code just as easily.
> “The security of Javascript-based cryptography is reducible to the security of the channel in which the Javascript is transmitted (every time you visit the page), which in this case is an SSL connection,” Marlinspike writes to me in an email. “If you can break SSL, you can break MEGA.”
Source: http://www.forbes.com/sites/andygreenberg/2013/01/21/researc...
And actually it's not a bad point for a service like this, in the sense that browser-based SSL will never protect you against a government who is trying to read your secrets, because the government can always coerce a local certificate authority into giving it a certificate for whatever site it wants to impersonate. The only way to prevent that is to remove all the common certificate authorities, which doesn't actually improve security at all (it really makes it worse under normal usage patterns), but it reduces your inclination to have a false sense of security.
So it's a valid point: If you need really good security, especially against governments, javascript-based password decryption is a fail, not least because it depends on SSL. But those people may still be able to use the service, just not the web interface to it, and I kind of expect they'll be a minority of the users in any event.
If the the security of MEGA reduces to the security of SSL, then all this Javascript crypto amounts to just extracomplicated security theater.
Q: So why bother?
A: It might be useful in a situation like Megaupload where the adversary seizes their servers while simultaneously shutting down their service.
Several XSS flaws were fixed quickly:
http://reflets.info/le-retour-du-mega-merdier-de-kim/
(french)