Slashdot Mirror


Kim Dotcom's Mega Fileshare Service Riddled With Security Holes

twoheadedboy writes "Kim Dotcom launched his new project Mega on Sunday, claiming it was to be 'the privacy company.' But it might not be so private after all, as security professionals have ripped it to shreds. There are numerous problems with how encryption is handled, an XSS flaw and users can't change their passwords, they say. But there are suspicions Mega is handing out encryption keys to users and touting strong security to cover its own back. After all, if Kim Dotcom and Co don't know what goes on the site, they might not be liable for copyright prosecutions, as they were for Megaupload, Mega's preprocessor." On this front, reader mask.of.sanity points out a tool in development called MegaCracker that could reveal passwords as users sign up for the site.

3 of 151 comments (clear)

  1. Re:Meh by GameboyRMH · · Score: 4, Informative
    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  2. Re:Security hole 1, Kim Dotcom by sunderland56 · · Score: 5, Informative

    You can encypher your data before uploading on *any* site. At that point they are all equally secure. Kim's claim was that Mega was more secure by design.

    However, the claim is completely broken. Mega is using a public/private key pair - generated by the web site - and so their servers actually *do* know both your keys, and *can* decrypt your data. So, basically, it is no more secure than dropbox.

  3. Re:Isn't Some of this Stuff Sort of Nitpicking? by Terrasque · · Score: 4, Informative

    You haven't read their own FAQ I take it?

    They're actually upfront about threats to the user's security.

    Is my stored data absolutely secure?

    All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks:
    Individual accounts are jeopardized by:
    - Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
    - Shoulder surfing. Do not type your password while someone could watch your keystrokes.
    - Password brute-forcing. Use strong passwords.
    - Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password.

    Large-scale attacks could be mounted through:
    - A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
    - Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
    - Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in shared folders and is detectable on the client side as well.

    What if I don't trust you? Is it still safe for me to use MEGA?

    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. If you still want to use MEGA, you have to do so through a client app that was written by someone you trust.

    Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.

    Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).

    The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.

    They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.

    --
    It's The Golden Rule: "He who has the gold makes the rules."