The author is a Forbes contributor. The opinions expressed are those of the writer.

Loading ...

Loading ...

This story appears in the {{article.article.magazine.pretty_date}} issue of {{article.article.magazine.pubName}}. Subscribe

A screenshot from Mega's new homepage.

Updated with Mega's response to several of the site's security issues below, as well as one newly-discovered security problem.

Kim Dotcom, like every smart founder of a startup in a crisis, is pivoting. Since his Mega empire of filesharing websites and financial assets were seized in an indictment over massive alleged copyright violations last year, he's been working on a relaunch designed to transform the company's reputation from a business focused on piracy to one focused on privacy--specifically, airtight encryption like no other storage site has ever offered.

But the security community knows that the boldest claims about new encryption technology demand the most scrutiny. And some crypto researchers are already punching holes in the secure lining of Mega's cloud.

"It's a nice website, but when it comes to cryptography they seem to have no experience," says Nadim Kobeissi, a 22-year old cryptographer and creator of the secure chat software Cryptocat, who began poring over the public portions Mega's code as soon as it debuted over the weekend. "Quite frankly it felt like I had coded this in 2011 while drunk."

The most glaring issue for Kobeissi is that Mega claims to offer end-to-end encryption of users' files without requiring them to download any software. All of the encryption takes place in the user's browser automatically when he or she visits the site. Mega describes that system as "User-Controlled Encryption."

"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," reads the company's website. "It’s all happening in your web browser!

That's a tempting convenience for users, but it's also a setup that has been widely debunked as insecure. When a website loads all the encryption code in a user's browser from a remote server, it can change that code without the user's knowledge. So Mega, or anyone else who gains control of the Mega server sending the crypto algorithms, can turn off that encryption or steal the user's private key, which would allow decryption of all past and future uploads. Kobeissi says he's traced several of Mega's servers to the United States, which would mean U.S. law enforcement could even force administrators to hijack the servers' encryption commands.

"They can actually change their code to force your browser to send them your Mega encryption keys, or change the code to disable crypto from the get-go," says Kobeissi, who ran his own Cryptocat encrypted chat site with the same no-download model in 2011, but switched to a more secure browser plug-in after widespread criticism. "They can do anything with the crypto operations at any time."

All of that means despite Mega's "you hold the keys" claim, users still have to trust Mega and any entity that has compromised the company not to decrypt their files. Mega acknowledges as much in its Help Center page on security and privacy. "If you don't trust us, you cannot run any code provided by us, so opening our site in your browser and entering your password is off limits," it reads.

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."

To make matters worse, Mega's SSL server seems to use weak 1024-bit encryption, rather than the 2048-bit encryption considered the minimum standard by many cryptographers for a decade. (This 2004 study, for instance, that declared 1024-bit keys would only be secure until 2006.)

Mega co-founder Bram van der Kolk alluded in his Twitter feed Sunday to a system of verifying the authenticity of external Javascript, which might be intended to prevent those kinds of vulnerabilities by checking the code to make sure it hasn't been altered. I've written to van der Kolk to ask for more information, and I'll add an update when I hear back from him.

Update: Van der Kolk writes in an email that while at least one of Mega's URL (eu.static.mega.co.nz) uses only 1024-bit encryption to "reduce CPU load," Mega.co.nz itself uses 2048-bit encryption for its SSL. Mega's Javascript verification system checks the code against the more strongly-protected connection, in theory ensuring that it hasn't been intercepted and changed. He also responded to other criticisms in this article, and I've included his comments below in line with each point.

John Hopkins cryptographer professor Matthew Green says that Mega's claims of a Javascript verification system "make no sense." Without any downloaded software like a Chrome or Safari extension or a Firefox or Internet Explorer plug-in, the only thing that could check the Javascript running in a user's browser is more untrusted Javascript. "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."

The issues around browser-based cryptography are a few of the litany of errors and problems critics have spotted in Mega's security setup. They also include:

Using Javascript's pseudorandom-number generator to create encryption keys, which is known to be predictable. Though the site says it seeds the generator with random data from users' keystrokes and mouse movements, it's not clear when that might happen; Users are never prompted to make those random input movements. Update: Van der Kolk maintains that Mega is using more than Javascript's number generator, and points users toward this page showing the code for collecting random numbers from mouse movements and keyboard strokes.

Leaving cross-site scripting vulnerabilities on the site, (according, at least, to one Reddit user) which could allow an attacker to steal a user's session cookies and gain access to his or her account.

Claiming in its terms of service that it can spot and delete duplicate files on its servers for better efficiency. That raises the question: If it can identify files in your encrypted folders, doesn't that mean the files aren't totally secret? Third parties may also be able to match up files between users and otherwise learn about the contents of their supposedly protected uploads. Update: Van der Kolk clarifies: "Deduplication is done based on the entire encrypted file and only happens if you either upload the same file encrypted with the same key twice (unlikely) or if you copy or import an existing file in your file manager (more likely)."

In fact, the new Mega seems to have so many holes that some observers wonder if the site--and its users--really care about security rather than mere plausible deniability. Its encryption may not protect users' data from outside snoops. But it might allow Mega itself to claim ignorance of any copyrighted files that are uploaded to the site, just as the company has claimed ignorance in defending itself against the massive copyright indictment brought by the United States last year.

"Fundamentally, I'm not sure that the integrity of their cryptographic protocol is really that important," cryptographer Moxie Marlinspike writes to me in an email. "All that matters is MEGA's ability to plausibly claim they don't have any way to identify copyrighted material on their servers, and my intuition is that this probably meets that technical bar."

Whether Mega's security claims are real or simply a clever "see no evil" smokescreen will become clearer as the site responds to criticisms, says John Hopkins professor Green. "The charitable interpretation is that this is a beta and it will get better," he says. "The less charitable interpretation is...'wink wink, everyone knows we’re really doing this just to protect ourselves.' If that's your legal strategy, you probably wouldn't want to admit it."

Update 2: Mega has responded in full, defending its practices against the security criticisms outlined here in a blog post. But another blog post by the security group fail0verflow outlines another oversight in the company's encryption, which involves using a weak hashing scheme in its Javascript verification system. Mega founder Kim Dotcom answered on Twitter: "We look forward to work with the crypto community to make #Mega even better. We get lots of useful input. Thank you."