Slashdot Mirror


Mega Defends Its Security Practices

Dangerous_Minds writes "Recently, Slashdot posted about how cloud storage company Mega was 'riddled' with security holes. Freezenet points out that Mega has issued a response to some of these criticisms including one which criticized its use of SSL. Mega responded saying that if you could break SSL, you could break things much more interesting than Mega."

12 of 165 comments (clear)

  1. That is an ignorant response. by jellomizer · · Score: 4, Insightful

    Assuming your security is good, because bigger people use it and they didn't run in a problem yet, doesn't mean your security is good. Also SSL is fine, however it isn't the end all be all in security. You just don't make it HTTPS and assume you are all good. Who actually reads data packets anyways nowadays?
    I mean any basic network now uses switch over hubs now, So traffic is routed more cleanly to the host system with less spots for you packet sniff. Simple rookie mistakes like having your password stored in your session, where if someone has access to your PC can read you memory/cache/paging file/browser history can find it, or the DB UID for your user account is just as bad, or just a back door for your "Administrator" to gain more access.

    Most developers don't really think in terms of security. That is the problem. SSL helps a little but but it isn't the end all bee all.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:That is an ignorant response. by aaaaaaargh! · · Score: 5, Informative

      Mega's response is quite reasonable and not ignorant at all. They adequately address all the incorrect claims and FUD that has been spread about their security, and do so in a timely manner.

      Your response, however, makes less sense. You say: "SSL is fine, however it isn't the end all be all [sic!] in security" Who claimed so? Certainly not Mega. They are a file storage service, not Fort Knox! (The rest of your post has nothing to do with Mega's security, so we can skip that.)

    2. Re:That is an ignorant response. by DJ+Jones · · Score: 4, Interesting

      If an individual could break SSL, yes, they would be going after your bank accounts not your hentai porn collection. But you have to keep in mind who the enemy is here and mega's enemy is the government. The government who basically runs the ISPs and could middle-man SSL very easily these days. In this case, the enemy is more interested in your data than your bank accounts and so the flaws in SSL are relevant and an alternate solution is probably not a bad idea.

      At least until you buy drugs

    3. Re:That is an ignorant response. by Havokmon · · Score: 4, Insightful
      The biggest part of security is risk.

      Mega needs to balance risk with usability and cost. Once you get beyond a certain point, every additional security layer will either cost more than it will benefit, or increase complexity so much as it make it unfeasible to use for their average user.

      Maybe I've read too many KimDotCom tweets, but the referenced articles seem like government astroturfing just trying to keep customers from using the Mega site. If you want your data THAT secure, just freaking host it yourself with your own locks in place behind double biometric VPNs or whatever and shut the hell up. Jeeesus.
      They're selling a product, not a theoretical 100% secure system that will never exist.

      --
      "I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
  2. Keep using the old method? by cseg · · Score: 5, Informative

    Encrypt it locally, upload it to the site for storage-only. Maybe use their whatever-it's-an-option encryption as added layer and call it a day. Isn't that how people do with other services like DropBox, anyways?

  3. The biggest security hole by bfandreas · · Score: 5, Informative

    The biggest security hole is the company itsself.
    They have complied in the past and they will so again.
    http://www.wired.com/threatlevel/2012/11/megaupload-investigation-roots/

    Kim Schmitz himself(aka Kim Dotcom, aka Kim Jim Tim Vestor, aka kimble...I kid you not) caved in under pressure from the Feds and ratted out on the German hacker/cracker/warez/phreaker scene. In a double twist of irony he cooperated with Günter Freiherr von Gravenreuth who in turn was a bit of a jackal.
    The self-styled His Royal Highness King Kimble the First, Ruler of the Kimpire was convicted of embezzlement. Which hardly is a hacktivist crime. More of a sleazebag move.
    I wouldn't argue that the Kiwi raid on him wasn't all kinds of wrong. But that doesn't make him trustworthy either. For a cause célèbre I would honestly look elsewhere.
    This guy has shady written all over himself and I'd be careful about trusting him. Especially when entrusting him with evidence for things that carry a hefty penalty(justified or no).

    --
    20 minutes into the future
    1. Re:The biggest security hole by aaaaaaargh! · · Score: 5, Insightful

      Trust is a relative measure. I would trust Mega with storing personal copies of my favorite TV show, so I can e.g. access them on my tablet elsewhere. I wouldn't trust Mega with all my banking details, trade secrets, or highly sensitive government secrets, and would dare to say Mega has not been invented for that purpose...

    2. Re:The biggest security hole by tlhIngan · · Score: 4, Interesting

      Trust is a relative measure. I would trust Mega with storing personal copies of my favorite TV show, so I can e.g. access them on my tablet elsewhere. I wouldn't trust Mega with all my banking details, trade secrets, or highly sensitive government secrets, and would dare to say Mega has not been invented for that purpose...

      Hell, I'm sure a lot of Mega's security design wasn't really to keep users data safe, but to protect Mega. Let's say Mega is raided and their servers are all confiscated. If Mega doesn't have access to the user's keys, they can claim they don't know what users are storing because to Mega, it's just encrypted garbage that Mega has no way of decrypting.

      So even if ordered to say remove all known pirated content, Mega can say they complied if given a list of files to take down, but they can't go and scan their repositories since they can't tell - even the filenames are encrypted.

  4. Re:January 23th by wcrowe · · Score: 5, Funny

    I don't thee that there'th anything wrong with it. It lookth jutht fine to me.

    --
    Proverbs 21:19
  5. Its not about confidentiality. by jzilla · · Score: 5, Insightful

    The encryption is there for mega to maintain plausable deniabity about copyright infringement. If you want to keep something private don't upload it to mega. The question is not whether the encyrption scheme is sound, but whether it is reasonable in court to expect a company to break encryption (and most likely laws) to ferret out copyright violations.

  6. Just as expected by Terrasque · · Score: 4, Informative

    This is similar to what I've said earlier (eerily similar, in fact..).

    The issues the original article raise are either false or silly, and just glancing at the JS code could tell you that.

    However, there are some other potential issues with the code I noticed, and at least one of them have proven to be a problem.

    I look forward to knowledgeable people looking through the site and report what they find, and hopefully Mega fixing the problems found. Right now I trust them slightly more than for example Dropbox, for no other reason that they need a bit of effort to get your data (and probably in a way you can notice / avoid if you're vigilant), instead of it happening by accident. Also, their whole legal and business defense rides on them not being (trivially) able to do that, so it's in their own best interest to keep things working properly.

    --
    It's The Golden Rule: "He who has the gold makes the rules."
  7. Re:The problem is Mega seems to be doing de-dupe by jkflying · · Score: 4, Informative

    Dedupe is only implemented on a same-file-same-key basis. So if *you* upload the same file twice it will be deduped, but it won't share the data backend with anybody else.

    --
    Help I am stuck in a signature factory!