Forgot your password?
typodupeerror
Cloud Security IT

Mega Defends Its Security Practices 165

Posted by Unknown Lamer
from the excuses-excuses dept.
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."
This discussion has been archived. No new comments can be posted.

Mega Defends Its Security Practices

Comments Filter:
  • by Balthisar (649688) on Wednesday January 23, 2013 @10:40AM (#42668995) Homepage

    January 23th is the date of the press release. Just... I guess that's minor compared to alleged encryption issues.

  • by jellomizer (103300) on Wednesday January 23, 2013 @10:42AM (#42669017)

    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.

    • by aaaaaaargh! (1150173) on Wednesday January 23, 2013 @11:06AM (#42669327)

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

      • Re: (Score:2, Informative)

        by Anonymous Coward

        "sic" is short for sic erat scriptum which is Latin for "thus was it written".

        You don't change what someone wrote and then say [sic]. You write what they originally wrote and say [sic]. You didn't even just change "bee" to "be" either, you paraphrased his entire sentence and then put it in quotes FFS. When being pedantic, try to get these things right.

      • Also, I learned here on slashdot that security is relative. "End all be all in security" doesn't exist. Even Fort Knox can be broken into. If SSL is "fine," then what is GP complaining about? That Kim Dotedu didn't invent some protocol that gives 100% security, which we all realize is impossible?
        • Offtopic, but your post reminds me that I really hope Kim Dotcom registers one of those new name TLDs for his last name. Maybe he could host a mirror of /., at "slashdot.dotcom". Then we'd never be able to tell people what the URL of this site is!

      • by bfandreas (603438)
        But in this case you have no reason whatsoever to trust the end-point.
        In fact if as per the chain of trust Verisign or some other CA confirms that the end point is Kim Schmitz it's only one reason more to stay THE HELL AWAY!
        Is it just me or is the thought of Kim Jim Tim Vestor sitting on a pile of credit card numbers disturbing?
        And that's before visualizing Kim Dotcom wearing giant diapers.
        And kimble having a hotline to the Feds just to save his own pudgy skin.
        • by Anonymous Coward

          Can't you come up with some more stupid nicknames for Kim Dotcom while you're at it? Did you really run out after only four?

      • by makomk (752139)

        Not that timely. This has already been proven wrong:

        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.

        The MAC they're using to verify the "extremely integrity-sensitive static content" is not in fact a cryptographically-secure hash. Anyone with the associated key (which has to be included in plain text in the page source in order for the verification code to be able to check the MAC is correct) can easily create arbitrary files with arbitrary malicious content that have the same MAC and pass the integrity checks.

    • by DJ Jones (997846) on Wednesday January 23, 2013 @11:08AM (#42669367) Homepage
      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
      • Its not clear whether the US govt could MITM ssl (at least to me)-- DoD certs arent installed by default and Im not aware of any other gov't controlled root CAs that are generally installed by default.

        If Im mistaken, would be interested to know specific root CAs they control.

        • by Anonymous Coward

          It's been done. The appliances are available commercial off-the-shelf ready to install in the network for government users. They're signed, they're valid, and nobody will answer the fucking question about what damned CA did it.

          And criminals, not being very bright...don't notice or report it.

          It's sold by at least one company

          http://www.wired.com/threatlevel/2010/03/packet-forensics/ [wired.com]

          And really, who's goign to stop it? If the government gets a national security letter for the private CA key or compels produc

      • The flaws aren't really relevant. Anyone using this to store data that needs to be secure just isn't thinking clearly. From my understanding the encryption has little to nothing to do with protecting user data, and everything to do with the company "having no way of knowing" what is contained on their server when it comes to DMCA requests/etc. I don't believe it ever really was advertised as anything other than a way for Kim to cover his own ass.
    • by Havokmon (89874) <rick AT havokmon DOT com> on Wednesday January 23, 2013 @11:10AM (#42669385) Homepage Journal
      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.

    • by LordLimecat (1103839) on Wednesday January 23, 2013 @12:00PM (#42669967)

      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

      Well, except for ARP poisoning, mirror ports, and in-line sniffers, sure.

      Who actually reads data packets anyways nowadays?

      You might be suprised. What do you suppose DPI is? You might be interested to know that even low-end firewalls like SonicWalls have a module for MITM-ing SSL on a network where you control cert installation. And rogue WiFi APs arent exactly rare.

      And as for "who", I might start with "China, a lot of middle-eastern countries, and probably a couple of US 3 letter orgs under certain circumstances". This stuff isnt hypothetical.

      I generally agree with your point-- that you cant just slap SSL on it and call it secure-- but you would be suprised how common packet inspection is.

    • The problem is their SSL keys are 1024 bit, which is trivial to break if you have $168 million. RSA theorized you would need $168 billion to do it in 1 day back in 2002; however today computers are faster, we have massively parallel GPU crap, and cracking RSA is embarrassingly parallel. If we take that out to 1000 days (3 years) it's $168 million circa 2002; however with the current advancements, you could probably do it in a week for less. Nothing that's going to win any contests--the guy who cracked 76
      • Never take security advice from a guy who can't read. The static content web servers use 1024 bit keys, the encryption servers 2048. So you can spend a small fortune decrypting the content on static content web servers. Wheee!

        • From my reading of the Mega response, the crypto applied to the static content was to ensure the integrity of the files as transmitted, not the privacy.

          They are free to add an arbitrary amount of additional integrity checking of the static files, both of the cryptographic and non cryptographic nature. I wouldn't be surprised if they already do because it is trivial and a normal thing to do.

      • by kill-1 (36256)

        The problem is their SSL keys are 1024 bit, which is trivial to break if you have $168 million.

        Then guess how many bits the RSA key of the google.com certificate has.

        • If I had that much money, hacking Google and banks would not be interesting. Hell the prize is $200,000.
    • by gweihir (88907)

      Indeed. There are no "magic" technologies with regard to security (well, there are none with regard to software engineering quality in general, but even less so with security). You always have to really understand what you are doing.

      That said, MEGA crypto strikes me as generally reasonable. What I do not like is that they can break the encryption, for example by delivering you back-doored JavaScript code. What I also do not like is that they reserve the right to log any and all accesses with IP, file, etc.

      B

    • This whole discussion is irrelevant. Mega doesn't have encryption to protect your data; they have encryption in order to protect themselves from any accusations of actively assisting copyright infringement.

      As long as the data is encrypted -- even with a half-assed encryption -- before it hits their servers, they can plausibly deny having any idea what's being uploaded. Additionally, they can logically avoid taking any many actions to prevent copyright infringement that other services offer, thus saving th
  • by cseg (253752) on Wednesday January 23, 2013 @10:43AM (#42669021)

    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?

    • by Tom (822)

      If you do it this way, then why would you use Mega over any of the other cloud-storage options on the market? The ones with more experience and infrastructure?

      • by Dekker3D (989692) on Wednesday January 23, 2013 @12:39PM (#42670447)

        50 gigs, for one-... like the AC said. AND this thing seems like a sort of personal payback from Dotcom towards the copyright mafiaa. It's not reckless enough to go down easily, but it does seem heavily motivated by that. Which means providing a good service is aligned with his interests.. where every alternative focuses on squeezing the most money out of people.

        His personal agenda seems to be counteracting the default business mindset enough to make it worthwhile. I'm intrigued :D

    • Maybe use their whatever-it's-an-option encryption as added layer and call it a day.

      I thought I remember reading that encrypting an encrypted file can actually make it less secure than either encryption step alone.

      • by Terrasque (796014)

        I thought I remember reading that encrypting an encrypted file can actually make it less secure than either encryption step alone.

        Well, then I should be able to take your encrypted file, and then I'll encrypt it again and again until it's completely insecure and can be broken by my calculator! Who needs quantum computers or fancy graphics cards?

      • That is certainly true if you use the exact same encryption method twice in a row, and that method consists entirely of swapping all 1's for 0's and 0's for 1's.

      • by flonker (526111)

        Maybe use their whatever-it's-an-option encryption as added layer and call it a day.

        I thought I remember reading that encrypting an encrypted file can actually make it less secure than either encryption step alone.

        Sort-of. If you make a mistake in your crypto, you can make things substantially less secure. A mistake, such as using the same key for both encryption steps. Also, encryption is not necessarily additive. Encrypting something multiple times with different keys may not improve the security, or may improve the security less than the cumulative total number of key bits indicate.

        As an example, let's take the caesar cipher. [wikipedia.org] If you encrypt twice with a key of 13, you end up with no encryption at all. If you

    • I just cut out the middle man - publish all my encrypted data on a website with the title "How I Intend To Overthrow The UK Government" (deleting old stuff to make room) and then when I want to recover anything, including the deleted stuff, I just use the Freedom Of Information Act to get a copy from the government. They're really very good, multiple secure backups and al that, they just need to streamline the UI a bit.
      • by PRMan (959735)
        I tried that, but I keep getting completely black pages back... Something's wrong with my encryption algorithm, I think.
    • by gweihir (88907)

      It is what anybody competent does. Even for file-sharing, it would be the way to go, i.e. upload an encrypted ZIP and deliver the password with the link, but not to Mega.

  • by bfandreas (603438) on Wednesday January 23, 2013 @10:52AM (#42669131)
    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/ [wired.com]

    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).
    • by dimeglio (456244)

      It's not the guy I care about, it's the service. It's not like a do a background check on the management board of every company I deal with.

      • by bfandreas (603438)
        Ummmm. Ok.
        I remember taking a severe beating when I pointed out that the man is a notorious slimeball just a year ago.
        His background is common knowledge.
        AND I WOULD FUCKING CHECK ON THE PEOPLE I STORE MY INCRIMINATING EVIDENCE WITH!
        Geeez.
    • by aaaaaaargh! (1150173) on Wednesday January 23, 2013 @11:09AM (#42669373)

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

      • by tlhIngan (30335) <slashdot@wor f . n et> on Wednesday January 23, 2013 @12:56PM (#42670635)

        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.

      • by bfandreas (603438)
        I wouldn't trust them with my favourite TV show.
        If they get a DMCA takedown notice then them complying is the best case scenario.
        If they have any incriminating evidence, expect them to hand it over.
        Check with your local authorities if you would be in serious trouble if you ripped your DVDs and stored them on a cloud storage server. They might even cuff you at ripped(copy protection circumvention aka OMGZ TEH TERRORISZ WIN *SAFACE*). I wouldn't even store videos of my latest jaywalking crime spree on thei
    • I pretty much agree with you, and the funny thing is when I clicked on the link offering Mega's response it came up with an SSL error, untrusted certificate, awesome.
      • I clicked on the link offering Mega's response it came up with an SSL error, untrusted certificate, awesome.

        Your browser informed you that it doesn't recognize Mega's CA, awsome. (And not a big deal.)

        • I clicked on the link offering Mega's response it came up with an SSL error, untrusted certificate, awesome.

          Your browser informed you that it doesn't recognize Mega's CA, awsome. (And not a big deal.)

          Yes I know, I just found it mildly ironic...

  • by Anonymous Coward

    I can't even read the blog because it force-redirects to a mobile page that just sys "mobile app coming soon".

    Kim - not all mobile hits are people trying to upload files.

    Grrrrrr

  • by gmuslera (3436) on Wednesday January 23, 2013 @10:56AM (#42669177) Homepage Journal
    There are easier approachs [xkcd.com]. And if well that approach could work now even for government agencies, the user side is also open to intrusion (like Red October [securelist.com]) and of course, is in Mega side to do things right too. All of that before even trying to break SSL.
  • levels of trust (Score:4, Insightful)

    by fermion (181285) on Wednesday January 23, 2013 @10:57AM (#42669191) Homepage Journal
    Mega seems to be trying to exploit either the misunderstanding or the ambiguity of trust and security. In Liars and Outliers Bruce Schneier discuss how we depend on a basic level of trust to efficiently live our life, but we still have levels of trust. So while we may well trust Mega to hold pictures of cat, do we trust Mega enough to store our bank accounts or business records? Some will.

    Now they are saying if you don't trust their implementation of SLL, then you can't trust anything on the web. That is stilly It is like saying if you are just as well off banking with a stranger standing on the corner as a well FDIC insured bank.

    I was pretty up on this new venture until all of these clearly misleading statements began to appear.

    • by nschubach (922175)

      I was pretty up on this new venture until all of these clearly misleading statements began to appear.

      Some would say it's intentional and seems to be working. I personally uploaded some non-copyrighted material to test the waters and see how the system works and so far it's been slow and pretty crappy but I can't speak for the security of it (since I'm no expert.) There are some things that worry me (like requiring devs give them the source to any apps written around the page...) but those are other issues.

    • by Tom (822)

      I was pretty up on this new venture until all of these clearly misleading statements began to appear.

      Indeed, for a self-labelled Robin Hood, it's all just so much standard corporate PR damage-control talk.

      However, it is a lot more clueful than the first statements. At least this time they had someone who understood the basics of crypto look over it.

    • by Anonymous Coward

      I would conclude from their statement of SSL that they are using a well-known stock implementation of SSL that would indeed be mass breakage if toppled.

    • by thoromyr (673646)

      by all of these clearly misleading statements I trust you mean the FUD against mega?

      It was embarrasing to read the "security evaluations" where using javascript random number generation is blasted, while tacitly admitting that using it (versus none) improves the security. An *actual* security evaluation would have measured the entropy and reported on that, and *specifically* how much it improved (versus none). An example of the proper way to do this was an evaluation of Apple's file vault 2. Which does not

  • New global and high visibility service, without IPv6 service. The future is apparently briefly visiting the elsewhere.

  • by jzilla (256016) on Wednesday January 23, 2013 @11:11AM (#42669397) Homepage
    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.
  • Or, without actually delving into their Javascript to verify their claims myself it's correct.

    I still don't like the idea of them holding the key, even encrypted. It does set it up so if a government wants to figure out what files I have, they have to get Mega to capture my key after my password decrypts it, but that's not so hard.

    But that sort of thing is still significantly better than most cloud storage services.

    • Of course, I still think Tahoe-LAFS is a better idea. :-)

    • by flonker (526111)

      Mega holding a copy of your encrypted key does not reduce security, and slightly improves security. A password generally has a laughably low number of bits. Anyone who knows or can guess your password can get your key and thus your files. Not very surprising. There is no way around the crypto entropy being limited by the password entropy. However, if your password has 2048 bits of entropy, then the attacker must crack 2048 bits of entropy to recover your key and your files.

      Password entropy is an incred

      • My encrypted HD is more secure than Mega is. This is because I have physical control over the devices my password is typed into and where the decryption happens. It has nothing to do with any other part of the technology, only that. And yes, I periodically examine my computer to make sure nobody has stuck a keylogger in between my keyboard and the computer.

  • by sl4shd0rk (755837) on Wednesday January 23, 2013 @11:20AM (#42669531)

    From the Mega TOS*:
    "8. Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data."

    That seems to point to deduplication -- if things were actually encrypted and the keys unknown to Mega, dedupe would be impossible.

    [*] - http://arstechnica.com/business/2013/01/megabad-a-quick-look-at-the-state-of-megas-encryption/ [arstechnica.com]

    • by jkflying (2190798) on Wednesday January 23, 2013 @11:48AM (#42669811)

      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.

      • by SeaFox (739806)

        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.

        So where does the "or give someone else access" part apply then?

    • by Fr33z0r (621949)

      Our service may automatically delete a piece of data you upload

      That implies block-level dedupe, it'll be looking at chunks, doesn't matter if the files themselves are encrypted or not.

    • How would that ever happen though? If the file is encrypted completely from start to finish using their system to avoid legal problems, and I may be wrong about this, then the meta data on the file is included as well. So it would be encrypted differently if it had so much as a different file creation date or last modified date, right? Because those are 0's and 1's somewhere in the file itself.
      Real dedupe programs for non-encrypted files typically ignore meta data like that when comparing two files. Ba
  • Just as expected (Score:5, Informative)

    by Terrasque (796014) on Wednesday January 23, 2013 @11:24AM (#42669587) Homepage Journal

    This is similar to what I've said earlier [slashdot.org] (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 [reddit.com] with the code I noticed, and at least one [fail0verflow.com] 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.

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

    Correct. Fact #1: Our FAQ states exactly that and warns people that do not trust us to refrain from logging into the site (but they could, in theory, still safely use MEGA through client apps from vendors they trust). Fact #2: Any software maker offering online application updates is able to plan

  • by John Hasler (414242) on Wednesday January 23, 2013 @12:06PM (#42670037) Homepage

    ...sensitive to the "cloud" without encrypting it first?

    I'd like to see an encrypted remote file system (or at least a backup system) that transparently uses several of these free "cloud" sevices. I'm not going to write it, though.

  • If I get a $5000 biometric lock for my door then install it horribly wrong, it's not the lock's fault. I didn't read way into the description of the flaw but it seemed to me like they just coded it like idiots and you don't need some sort of magical SSL decryptor to pull off the hack. I think, given past history as evidence, he's just a fat, stuck up, arrogant piece of shit that rushed out a crappy, half-working service to basically give the finger to the people trying to sue/arrest him and now he's tryin
  • They are using public/private key encryption, which seems fine. Initially, I was curious as to how they would manage private keys. And this article -- kinda -- gives us an answer.

    They are storing both private and public keys on their servers... but the private key is encrypted with my password, which they don't know. Even though they have the private key, it's protected and they can't use it to decrypt my files. That's all good. Standard. The password of my password.

    However, I still can't wrap my head a

    • by juliohm (665784)
      [post edit] The only way I see this making any sense is if they mean that "changing your password will discard your current private/public keys and a new pair is created". That actually means your files locked with the old private key will, in fact, become unrecoverable. But that just seems..... stupid.

FORTRAN is for pipe stress freaks and crystallography weenies.

Working...