It seems like the security vulnerabilities are somewhat beside the point. It's basically a beta, it's got bugs. But what they're trying to do is capable of being secure. You can store data on a server without the server operator having any ability to know what it is. It's not a new thing: You've always been able to upload a truecrypt volume to any untrusted server. They're just trying to make it easier to use for the man in the street.
So their implementation has flaws. Security experts are pointing them out. I expect they'll be fixed soon enough.
They haven't found any concrete flaws though. Just speculation and outright wrong information.
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.
>They haven't found any concrete flaws though. Just speculation and outright wrong information.
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.
It's not, they did, and I don't think they were. Quote from article:
> 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.”
Meh. He's not complaining about Mega, he's complaining about SSL. He's always complaining about it, and he's mostly right. There are legitimate problems with it. In particular, too many questionable entities are registered as certificate authorities in common browsers, so you periodically see these imbeciles issuing wildcard certificates for * .google.com or * .gov which totally compromises the ability of browser-based SSL to prevent man in the middle attacks against anyone who can socially engineer or coerce their way into one of those certificates from any one of the inept certificate authorities.
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.
So their implementation has flaws. Security experts are pointing them out. I expect they'll be fixed soon enough.