Mega_silhouette_crop

Mega Defends its Cryptographic System

By Drew Wilson

Mega was able to open with a bang as an untold number of users rushed to create accounts on opening day – so much so that the traffic ultimately brought down the website for about 48 hours for some users. Now that the website is up and running, some are criticizing the websites security. With these criticisms circulating on some outlets, Mega has opted to post some clarifications.

It seems that the opening few weeks for Mega hasn’t been entirely smooth. Of course, with just about any start-up, that isn’t really much of a surprise especially when the start-up deals with something complex like modern security measures. Still, with so much attention directed to the new site, it might not be a surprise that it would be under such heavy scrutiny in the first place. Let’s dig into some of the latest on this front of the website.

From the beginning, Kim Dotcom marketed Mega as a “privacy” company. It boasted of security measures that could become the new standard for cloud storage companies. In fact, Mega allowed others to go through the source code for public feedback so as to improve security. For many, this could be considered very positive first steps for any start-ups – implementing new security measure ideas and allowing for third party feedback. For some, that is where the accolades ends.

One posting is from Ars Technica where the author commented that the code used to secure the website needs to be overhauled “post-haste”. Forbes, meanwhile, documented a security researcher who said that Mega can’t keep it’s security promises. TechweekEurope, meanwhile, said that Mega was “riddled” with security holes. Slashdot even joined in, pointing to an application called “MegaCracker” that was touted as something that could crack Mega passwords.

Mega, no doubt seeing these criticisms, decided to act to “clarify” some points being made. In a blog posting posted just today, Mega commented directly to some of the criticisms that were made against the company. One of the criticisms is that Mega doesn’t allow users to change their passwords. So if something were to go wrong and a user, say, forgets the password, all their data couldn’t be retrieved. Mega responded saying that this will change in the near future as security protocols will no doubt be developed. Another second response that was made was this:

“Without adding entropy, the “random” primes generated by math.random for use as RSA keys are really only pseudo-random and can be guessed.”

This is correct – and quite a strange statement to make after conceding that mouse and keyboard entropy are indeed used to enhance Math.random(). We will, however, add a feature that allows the user to add as much entropy manually as he sees fit before proceeding to the key generation.

A third criticism was that Mega uses SSL encryption and that if the SSL encryption could be broken, someone could break into Mega. Mega responded saying that if you could break SSL, you could break into things much more interesting than Mega itself. For us, this was a somewhat puzzling criticism. After we took a brief look at Wikipedia, we learned that HTTPS also uses SSL encryption. So, when you go to many banks and see HTTPS in the URL, there’s a pretty good possibility that SSL encryption was also being used. In fact, the Electronic Frontier Foundation (EFF) had a campaign called HTTPS everywhere that encouraged the use of SSL encryption. In their FAQ, they mention that HTTPS uses SSL encryption. When this campaign was in full swing, we weren’t aware of very many criticisms of the security implications, yet now that Mega uses SSL, red flags are being raised that maybe Mega isn’t very secure at all. One question might be, “How is SSL positive for something like HTTPS Everywhere, yet negative for Mega?”

A fourth exchange had the following:

John Hopkins cryptographer professor Matthew Green says that Mega’s claims of a Javascript verification system “make no sense.” … “If the Javascript is verifying itself, it’s like trying to pick yourself up by our bootstraps, which doesn’t work,” says Green. “You need something trusted on the user’s machine to check the Javascript, and they don’t have that.”

Please do not rely on hearsay, even if you are a cryptographer professor. Instead, go to the actual site and look at the actual code. Fact #1: The JavaScript is not verifying itself. Fact #2: A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.

One thing to point out in all of this is that Mega marketed itself as a privacy company from the beginning. As a result of this, some people’s expectations may have been raised and when they saw that their expectations weren’t met, criticism ensued. A good argument could be made that what we are seeing here may be, in part, self inflicted. If Mega marketed itself as a cloud storage company with some extra security features, it’s entirely possible that the criticisms wouldn’t have been so harsh. Secondly, security can be a very frustrating aspect for any website. How does one make a website highly secure while making it as user friendly as possible? Obviously, there needs to be some balancing that needs to take place because it’s entirely possible to make the worlds securest website that is very user unfriendly. Also, security is also always evolving and a standard pearl of wisdom that seems to have held true all this time is that nothing is ever 100% secure. It’s possible to make something secure that it’s extremely unlikely that someone would be able to break in, but making something forever impervious is not very realistic.

At this point, trying to make Mega secure is going to be a major undertaking. How Mega handles security from this point going forward will very likely play a role in the future of the company itself.

Drew Wilson on Twitter: @icecube85

3 thoughts on “Mega Defends its Cryptographic System

  1. JB

    I’m not sure how you reach your final conclusion given the rebuttals by Mega, and even your own assertions about some of the complaints being wrong (i.e. the SSL issue).

    To conclude with “At this point, trying to make Mega secure is going to be a major undertaking”, especially when the rest of the article seems to imply that the security complaints thus far are nothing more than a storm in a teacup, is very odd.

    Reply
    1. Drew Wilson Post author

      I guess I could have been clearer on that last point. Securing any website is a challenge for any website. On a major website, ideally, there would be a whole team of people working on keeping a site secure because with increased popularity, there is an increased chance that someone is going to want to break into it. Since Mega is a start-up, it’s less likely they’ll have the capacity to cope with the demands of what a larger site normally faces (hence the downtime due to the initial surge in traffic being an indication). So, in the sites first few weeks, there’s probably going to be some growing pains involved on many fronts, not just server capacity to handle people viewing the front page.

      Given that any large site faces a tall order in keeping secure, it’ll be likely that this will be an especially difficult task for Mega. That has nothing to do with all the concerns raised elsewhere. Looking towards the future, if Mega gets hacked into every other month, fewer people will be willing to trust Mega. If Mega does things right in how it handles security, I think more and more people will be willing to trust the site with their data. Since Mega promised many things in terms of privacy and security, it’s going to be a tall order to fulfill. Can Mega fulfill its promises? We’ll have to wait and see since the site only just launched.

      Reply
  2. Pingback: Report - CETA Weeks Away from Completion

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>