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

165 comments

  1. January 23th by Balthisar · · Score: 3, Funny

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

    --
    --Jim (me)
    1. 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
    2. Re:January 23th by RivenAleem · · Score: 1

      It's encrypted.

    3. Re:January 23th by helix2301 · · Score: 1

      I like how on sundays press release Kim said there security is so tight and that site does not even allow him to see what people are uploading.

  2. 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)
    4. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      Mega's response can't be more ignorant that the flimsy strawman argument you just posted. Perhaps you'd like to quote the section of the response where Mega said SSL is the end-all-be-all of security.

    5. Re:That is an ignorant response. by LordLimecat · · Score: 3, Informative

      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.

    6. Re:That is an ignorant response. by LordLimecat · · Score: 1

      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.

    7. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      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.

      Actually mega could still be sitting fairly safe. Some parts of the government might want to, but the government as a whole won't dare break SSL routinely to go after mega and its users. Not for any benign reasons, but to not waste this weapon in their arsenal against a minor target.

      If people stop seeing SSL as being secure, there will be demand for a new solution that isn't trivially broken by the government. The government won't be able to use SSL MITM attacks on the real bad guys (ex terrorists) if the bad guys stop trusting SSL to protect them.

    8. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      If it came down to it, it seems like it would be a trivial matter for the government to get a court order to force a domestic CA to sign a cert for them to use in such an operation. I'm not saying it's right or that I think they *should* be able to, but I'm pretty sure they'd get their cert signed.

      This is of course assuming that the NSA doesn't already have private keys for every CA already...

    9. Re:That is an ignorant response. by bluefoxlucid · · Score: 1

      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 768 bit RSA didn't use a specially built $200 million array.

    10. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      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

      So, where the fuck should they store it if not in "memory"?? This is a serious question. I keep seeing this getting "poasted" by "experts" and always modded up, but they never say where should the omnipotent passphrase be stored so it can be hashed and used. Of course, hashed passphrase being even more dangerous to be stored (if you know *anything* about how password based encryption works).

      It is typed on a keyboard, right? So it enters the computer via some memory buffer. What prevents someone from keylogging you right there?? What is so bad about sticking it in RAM? And if you can't stick is in RAM, *how the fuck* are you going to use it??

      Maybe the "experts" needs to realize that if your machine is rooted, your security, ANY TYPE, is rooted as well.

    11. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      I would assume that the US government has a copy of all root CAs of all US based companies.
      http://xkcd.com/538/

    12. Re:That is an ignorant response. by Anonymous Coward · · Score: 2, Informative

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

    13. Re:That is an ignorant response. by jellomizer · · Score: 1

      You don't store the password in Memory for long at all.

      For example. (I am keeping the code simple here)

      function sendstuff() { //send login data to server
      results=ajaxcalllogin("myPass");
      document.getElementById("myPass").value="XXXXXXXXXXXXXXXXXXXXXXXXXXX";
      process(results)
      }

      Then after that you use an encrypted/sha2+salt session value, that you can verify against your connection information such as an IP Address so it is harder to reproduce on different systems.

      What I have seen in the past is the server sending back the password of the Javascript keeping the login and password in a variable so it can continue. Which is just bad.

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

      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?

    15. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      I agree that the poster you replied to was misusing it, but I think you were a bit too narrow in describing the use of "sic".

      Strictly speaking, "sic" isn't short for anything. By convention, incomplete sentences in Latin are interpreted as having implied subjects, verbs, etc. In Latin, you can answer sic to a question and it will be understood as "it was thus", "it will be thus", "he did thus", or whatever an appropriate affirmative repetition of the question would be.

      From this convention, "[sic]" can be used by an editor to assert intentionality of an apparent mistake or oddity in text.

    16. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      That is in fact an exact quote, if you read a little more carefully.
      The placement of [sic] in an already correct phrase is slightly unconventional, but not unheard of, and not necessarily incorrect.

    17. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      I haven't changed what the OP has written, though.

    18. Re:That is an ignorant response. by aaaaaaargh! · · Score: 2

      What kind of weed do you smoke? I quoted him literally and used [sic] to point out a typo.

    19. Re:That is an ignorant response. by kill-1 · · Score: 2

      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.

    20. Re:That is an ignorant response. by aaaaaaargh! · · Score: 1

      I admit that there was no typo in the first place, though.

    21. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      Copy pasted quote from the GGP

      Also SSL is fine, however it isn't the end all be all in security.

      Copy pasted quote from the GP

      You say: "SSL is fine, however it isn't the end all be all [sic!] in security"

      The word "Also "is missing"but that can be taken as choosing to start the quotation afterwards. Also "[sic!]" is inside the quotation instead of afterwards. I don't see any paraphrasing here. Where do you see it?

      Since slashdot has no edit features, the GGP cannot have edited his post in between you reading his post and me reading his post.

    22. Re:That is an ignorant response. by bfandreas · · Score: 0

      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.

      --
      20 minutes into the future
    23. Re:That is an ignorant response. by bluefoxlucid · · Score: 1

      If I had that much money, hacking Google and banks would not be interesting. Hell the prize is $200,000.

    24. Re:That is an ignorant response. by TechyImmigrant · · Score: 2

      If you mean the private keys, I can assure you that they don't.
      There are at least two root CA private keys that I was involved in instantiating that the US government does not have.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    25. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      The placement of [sic] in an already correct phrase is slightly unconventional

      But it's not correct. The phrase is "be-all and end-all." The original reversed the 'be' and 'end', omitted the hyphens and left out the 'and'.

    26. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      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.

      I see. So if I want to transmit data securely over an HTTP connection, what current technology would you suggest using instead of SSL? Please provide the data that shows how much more secure than SSL this is.

    27. Re:That is an ignorant response. by Anonymous Coward · · Score: 1

      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?

    28. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      They just compel a US company to facilitate a MITM attack.

    29. Re:That is an ignorant response. by almitydave · · Score: 2

      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!

      --
      my, your, his/her/its, our, your, their
      I'm, you're, he's/she's/it's, we're, you're, they're
    30. Re:That is an ignorant response. by gweihir · · Score: 1

      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.

      Basically, if you trust them, their security is reasonable, if not, it sucks badly. If I use MEGA (thinking about putting some short-term automatized backups on it), I will add my own encryption layer via GnuPG.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    31. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      He quoted the second sentence of the post not the last one.

    32. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      http tunneling over ssh?

    33. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      There may not have been a typo - but he still got it wrong both times.

      The phrase is 'be all and end all'.

    34. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      You did NOT quote him, you wrote some new shit and even fucked up the typo. You're a fucking retard. Fuck off and die.

    35. Re:That is an ignorant response. by uniquename72 · · Score: 1

      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 themselves the hassle of responding to millions of automated takedown notices.

    36. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      Read the second sentence of the GGGGP. This is the sentence that was quoted. You read the last one and assumed the GGGP misquoted that sentence.

    37. Re:That is an ignorant response. by skitchen8 · · Score: 2

      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.

    38. Re:That is an ignorant response. by LordLimecat · · Score: 1

      If a company says "get a court order or get bent", im not clear what recourse the gov't would have. They can ask nicely, and a company can comply, but that probably wouldnt go over too well with the CA if that ever leaked out (read: would utterly sink the CA).

    39. Re:That is an ignorant response. by makomk · · Score: 1

      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.

    40. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      you're an idiot

    41. Re:That is an ignorant response. by AK+Marc · · Score: 1

      How about an IPSEC connection within a VM on the user PC directly to a private VM on the server, and from there, open up an HTTPS session to the secure cloud?

    42. Re:That is an ignorant response. by Anonymous Coward · · Score: 1

      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/

      And really, who's goign to stop it? If the government gets a national security letter for the private CA key or compels production of a signed certificate for a domain -- it's good game comrade without using an HTTPS observatory.

      The problem is you don't understand the differnce between government-controlled, and government-regulated that could be forced to comply with a court order.

      Beyond that -- have you *LOOKED* at a browser CA list? I'm pretty sure that if I had a million bucks to blow I could find one of those organizations to get an infiltrator into...

      So, let's fix your "it's not clear". It's commercialized and available for purchase.

    43. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      That's just the thing, man. You did NOT quote him "literally".
      So therefore you incorrectly used "sic".

    44. Re:That is an ignorant response. by Anonymous Coward · · Score: 0

      He did, you just think he misquote the last sentence of the post when he instead quoted correctly the second sentence of the post.

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

    1. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      That's what they try to do, which is why you have to use Chrome with all it's HTML5-y local storage access. That's why Mega generates a RSA key for you when you make an account - that's what it's used for. The implementation is extremely shakey, but that's what they're trying to do.

    2. Re:Keep using the old method? by Tom · · Score: 2

      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?

      --
      Assorted stuff I do sometimes: Lemuria.org
    3. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      50 gigabytes instead of 2

    4. Re:Keep using the old method? by PPH · · Score: 2

      That's why Mega generates a RSA key for you when you make an account

      I'll encrypt my stuff with my own key, thanks. If Mega wants to encrypt the encryption, that's their problem. But I won't be trusting their (or anyone else's) provided keys for my security.

      --
      Have gnu, will travel.
    5. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      the implementation is extremely shakey

      Stop spreading FUD, and please point out the reason why you think the site is insecure

    6. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      Shush! There's no place for rationale in here! And keep your voice low, please.

    7. Re:Keep using the old method? by Dekker3D · · Score: 3, Insightful

      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

    8. Re:Keep using the old method? by MozeeToby · · Score: 1

      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.

    9. Re:Keep using the old method? by History's+Coming+To · · Score: 1

      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.

      --
      Please consider this account deleted, I just can't be bothered with the spam anymore.
    10. Re:Keep using the old method? by Terrasque · · Score: 1

      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?

      --
      It's The Golden Rule: "He who has the gold makes the rules."
    11. Re:Keep using the old method? by Anonymous+Cod · · Score: 1

      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.

    12. Re:Keep using the old method? by PRMan · · Score: 1

      I tried that, but I keep getting completely black pages back... Something's wrong with my encryption algorithm, I think.

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    13. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      Not precisely. If you're talking about completely independent encryption steps with different keys, then it'll get more secure because you're adding more unknown-ness to the final product that someone has to guess or brute-force.

      The "don't encrypt twice" advise is mainly when people try to "roll their own" (already a bad idea) and use the same keys in multiple steps, possibly accidentally "undoing" some of their previous scrambling work.

    14. Re:Keep using the old method? by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    15. Re:Keep using the old method? by Tom · · Score: 3, Insightful

      where every alternative focuses on squeezing the most money out of people.

      Uh... I don't think Kimble paid for his mansion, cars and other luxuries with good will and motivation. If you think this is motivated by revenge, not money, you need to visit the real world more often.

      --
      Assorted stuff I do sometimes: Lemuria.org
    16. Re:Keep using the old method? by skitchen8 · · Score: 1

      That is a good idea. Mega is encrypting your data so that they can claim no knowledge of what you are uploading to their service. Be it copyrighted music or kiddy porn their encryption prevents them from knowing what you upload. Your encryption is all that is preventing people who are specifically targeting your files.

    17. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      Can't it be both?

    18. Re:Keep using the old method? by Anonymous Coward · · Score: 0

      correct in some cases. That is why there is DES and TRIPLE-DES but no DOUBLE-DES.
      Double-DES would actually weaken (single-)DES

    19. Re:Keep using the old method? by flonker · · Score: 1

      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. If you encrypt twice with a key of 13, you end up with no encryption at all. If you encrypt once with a key of 15 and a second time with a key of 12, you end up with exactly the same security as encryption once with a key of 1.

  4. I actually tried, but I can't RTFA by Anonymous Coward · · Score: 0

    From my iPhone when I click on the issued a response link, all I get is a page saying a dedicated app is coming soon. I view that as another failure on Mega's side.

    Anyone have a summary or another link?

    1. Re:I actually tried, but I can't RTFA by Anonymous Coward · · Score: 0

      I points out link I didn't see makes a good summary =)

    2. Re:I actually tried, but I can't RTFA by Anonymous Coward · · Score: 1

      You are in possession of the iPhone,the failure is on your side, chump.

    3. Re:I actually tried, but I can't RTFA by tidepool · · Score: 1

      Nexus 7 at my side does the same thing.
      Back to that article about designing for mobile vs. just designing in general.

      Some shitty formatted information on a smaller screen is better than a nice ornate pile of ... 'nothing' because you happen to be using a mobile device at the time you go to an address...

      Keep this in mind!

  5. Way to go, MEGA! by Anonymous Coward · · Score: 0

    Very reassuring, objective, and clarifying rebuttal.

  6. Re:/. to review their grammar practises! by jgeeky · · Score: 1

    I'm not trying to be pedantic or a contrarian prick, instead I'm merely pointing out that in the US there is only one form of the word "practice".

    --
    in the immortal words of socrates, "i drank what?"
  7. This issue wasn't the use of SSL by Anonymous Coward · · Score: 0

    But the questionable storage and usage of certain cryptographic information.

  8. 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 dimeglio · · Score: 1

      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.

      --
      Views expressed do not necessarily reflect those of the author.
    2. 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...

    3. Re:The biggest security hole by Spottywot · · Score: 1

      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.

      --
      In a cybernetic fit of rage she pissed off to another age...
    4. Re:The biggest security hole by Anonymous Coward · · Score: 0

      Hilarious. In the US we have a throughly corrupt justice system that lets banks and Wall Street execs who've committed massive fraud, money laundering for drug cartels and terrorists, etc. unprosecuted, and I'm supposed to worry about a guy to ratted out other criminals and committed a pump-n-dump scheme? HAR!

    5. Re:The biggest security hole by interval1066 · · Score: 1

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

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    6. 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.

    7. Re:The biggest security hole by bfandreas · · Score: 1

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

      --
      20 minutes into the future
    8. Re:The biggest security hole by bfandreas · · Score: 1

      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.

      --
      20 minutes into the future
    9. Re:The biggest security hole by Anonymous Coward · · Score: 0

      AND I WOULD FUCKING CHECK ON THE PEOPLE I STORE MY INCRIMINATING EVIDENCE WITH!

      Geeez.

      So people freely gave evidence of themselves committing a crime to a 3rd party?
      And they expected what in return?

      Moral: Don't store evidence of your crime on the internet... anywhere... and you won't be caught that way.

    10. Re:The biggest security hole by bfandreas · · Score: 1

      Ayep. That's what we are talking about. Storing your torrented stuff on their servers is the obvious bad move.
      Interestingly even if you ripped your own DVD/Blurays, encoded them in a sane way and want ot keep that available to you at all times and store it with them you might be in real hot water. Depends on where you live. In that case you still can get stuck with five infringements per instance amounting to a MEEELion years in prison and a couple of BEEEEllion in damages. Unless you take the plea bargain of 5 years in the slammer and a mere 5megabucks in damages.

      You never talk to the cops. And you don't give potentially damaging stuff to people who do. Snitches used to grin a Glasgow smile in the olden days. But since everything nowadays is white-collar "crime" we can only envy our forbears in which turns out were much more enlightened times. Well, maybe not enlightened but definitely straight forward.

      --
      20 minutes into the future
    11. Re:The biggest security hole by Spottywot · · Score: 1

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

      --
      In a cybernetic fit of rage she pissed off to another age...
    12. Re:The biggest security hole by Anonymous Coward · · Score: 0

      I didn't get that alert. Perhaps your security certificates need updating?

      (posting as AC to preserve mod points - sorry)

  9. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    He's not a keyboard jockey,he's a gamer and he's gaming!!

  10. I hate mobile "optimized" sites! by Anonymous Coward · · Score: 1

    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

    1. Re:I hate mobile "optimized" sites! by whoda · · Score: 1

      Hit the menu key on your phone and click "Request Desktop Site", or is this something else iPhones don't do?

    2. Re:I hate mobile "optimized" sites! by rwise2112 · · Score: 1

      Hit the menu key on your phone and click "Request Desktop Site", or is this something else iPhones don't do?

      Funny. It opens fine on my phone in Chrome, but on my desktop Chrome reports "The webpage at https://mega.co.nz/#blog_3 might be temporarily down or it may have moved permanently to a new web address".

      --

      "For every expert, there is an equal and opposite expert"
  11. Re:/. to review their grammar practises! by j00r0m4nc3r · · Score: 3, Funny

    You are an editor of an internationally renowned news aggregation service.

    You mean Fark?

  12. Minimal effort by gmuslera · · Score: 2

    There are easier approachs. And if well that approach could work now even for government agencies, the user side is also open to intrusion (like Red October) and of course, is in Mega side to do things right too. All of that before even trying to break SSL.

  13. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    You would think that if you were going to reprimand someone for not using proper grammar, you yourself would learn the difference between a verb and a noun.

    In the title, the term is "security practices" therefore the noun version is applied. "Mega Defends The Security It Practises" would be the verb form and makes for a terrible article title.

  14. levels of trust by fermion · · Score: 3, Insightful
    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.

    --
    "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    1. Re:levels of trust by nschubach · · Score: 1

      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.

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    2. Re:levels of trust by Tom · · Score: 2

      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.

      --
      Assorted stuff I do sometimes: Lemuria.org
    3. Re:levels of trust by Anonymous Coward · · Score: 1

      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.

    4. Re:levels of trust by thoromyr · · Score: 1

      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 have as much entropy as it "should" (in an ideal world) due to real world constraints. In Apple's case the reduction isn't particularly significant for home market, but you wouldn't want to trust it for storing important state secrets.

      In real world encryption implementations there are always limitations to actual entropy. It isn't easy to accomplish and it is easy to lose. And side channel attacks can remove some you thought you had.

      I sure wouldn't trust anything I considered private to megas servers -- but considering their security posture seems to be at least as good as (if not better than) dropbox* I wonder why all the outrage. If you want to put private files in the cloud don't use Mega, or dropbox, or pretty much any of these providers. Maybe spideroak (though where is the review of their still-private code to demonstrate proper implementation) or similar. Possibly tarsnap -- except that isn't really storing files in the cloud, but rather a remote archival solution.

      I've been surprised at the apparent level of astro-turfing by the MAFIAA here. More likely its just a more general dislike for mega and its owner than I'd anticipate

      * Dropbox who, via a "simple" mistake during a routine site update eliminated password verification so all files were effectively public. But trust them, no one's data was actually exposed...

  15. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    It says "practices", which happens to be the correct form in this case. I opened this page 2 minutes after you posted that, so I'm not sure if you got them mixed up or if you called it and they fixed the error in the interim.

  16. IPv6less by arttulaine · · Score: 2

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

  17. Re:/. to review their grammar practises! by Ginger+Unicorn · · Score: 1

    Go learn

    Go and learn.

    --
    (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
  18. JavaScript local file access APIs by tepples · · Score: 3, Insightful

    From my iPhone when I click on the issued a response link, all I get is a page saying a dedicated app is coming soon. I view that as another failure on Mega's side.

    Mega uses JavaScript local file access APIs to read and encrypt user-selected files before uploading them. Historically, Safari for iOS has been severely lacking in JavaScript local file access APIs. So if Apple doesn't give web application developers the proper tools to read and encrypt user-selected files, how should that be regarded as a "failure on Mega's side" rather than Apple's?

    1. Re:JavaScript local file access APIs by Anonymous Coward · · Score: 1

      ....because it redirected him to that stupid message, instead of letting him read the article?

    2. Re:JavaScript local file access APIs by Minwee · · Score: 1

      Actually, when Mega requires me to use JavaScript local file access APIs just to read a public text-only release explaining that their web site is implemented quite well despite what Lee Hutchinson says, then I have no choice but to regard it as a failure on Mega's side.

      Making a web server which is severely lacking in the ability to serve web pages is usually not what I would call a big success.

    3. Re:JavaScript local file access APIs by LordLimecat · · Score: 1

      To be clear, the webserver is serving web pages just fine; its your browser / JS engine that is failing to interpret them properly.

    4. Re:JavaScript local file access APIs by nitehawk214 · · Score: 1

      From my iPhone when I click on the issued a response link, all I get is a page saying a dedicated app is coming soon. I view that as another failure on Mega's side.

      Mega uses JavaScript local file access APIs to read and encrypt user-selected files before uploading them. Historically, Safari for iOS has been severely lacking in JavaScript local file access APIs. So if Apple doesn't give web application developers the proper tools to read and encrypt user-selected files, how should that be regarded as a "failure on Mega's side" rather than Apple's?

      That caniuse site is really useful. My horse for a mod point! (you can't have my kingdom, I already traded it for the horse)

      --
      I'm a good cook. I'm a fantastic eater. - Steven Brust
    5. Re:JavaScript local file access APIs by Anonymous Coward · · Score: 0

      Just like a website that uses Flash to display a block of text is working just fine, it is your browser failing to interpret the page correctly if you don't install or use Flash. Likewise, if I make a page that requires you to install a binary blob plugin to read, it is working perfectly fine, because you refuse to run extra software on your computer to access simple text.

  19. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    original A/C...

    when a verb modifies a noun, it is still a verb.

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

  21. User agent change vs. unimplemented objects by tepples · · Score: 1

    I was under the impression that the "request desktop site" command only changed the user agent. Even a "request desktop site" command won't make a browser implement a JavaScript object that it doesn't implement, and a lot of older browsers don't implement APIs to read local files chosen by the user.

  22. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    Use them correctly, show people you're not just a keyboard jockey.

    This text fragment consists of two main clauses, separated by a comma. It's not what one might generally consider to be an actual sentence. Consider using a semicolon instead.

  23. This rebuttal is clear, concise and correct by Omnifarious · · Score: 3, Insightful

    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.

    1. Re:This rebuttal is clear, concise and correct by Omnifarious · · Score: 1

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

    2. Re:This rebuttal is clear, concise and correct by flonker · · Score: 1

      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 incredibly difficult problem to solve. xkcd has what has become the canonical example of this. 28 bits of entropy for a "typical" password. 44 bits of entropy for 4 random words strung together. The mega key is 2048 bits, which is roughly equivalent to 186 random words strung together or about 311 completely random typed characters. Anyone attempting to crack your crypto is going to attack the password, not the mega key.

      The security increase comes from two factors. The net effect of padding your password so that its length is unknown, and the real world security from using a known, trusted and tested security algorithm.

      In summary, your encryption isn't any more or less secure than the password you use. If it helps, you can think of the key stored on the servers as a salt, and the password you type in as the actual key.

      (Also, if they were so inclined, why would they capture the decrypted key rather than just capturing the password itself?)

    3. Re:This rebuttal is clear, concise and correct by Omnifarious · · Score: 1

      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.

  24. The problem is Mega seems to be doing de-dupe by sl4shd0rk · · Score: 2

    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/

    --
    Join the Slashcott! Feb 10 thru Feb 17!
    1. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      This point is addressed quite clearly in the article. Stop spreading FUD:

      [On deduplication] "Whatever the underlying method, the fact that block deduplication exists is a blow against the "see no evil" approach taken by Mega."
      Fact #1: Once this feature is activated, chunk MACs will indeed be stored on the server side, but they will of course be encrypted (and we will not use ECB!). Fact #2: MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption. If the same file is uploaded twice, encrypted with the same random 128-bit key, only one copy is stored on the server. Or, if (and this is much more likely!) a file is copied between folders or user accounts through the file manager or the API, all copies point to the same physical file.

    2. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      FFS - the whole point of TFA is a rebuttal of the Ars claims:

      [On deduplication] "Whatever the underlying method, the fact that block deduplication exists is a blow against the "see no evil" approach taken by Mega."

      Fact #1: Once this feature is activated, chunk MACs will indeed be stored on the server side, but they will of course be encrypted (and we will not use ECB!). Fact #2: MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption. If the same file is uploaded twice, encrypted with the same random 128-bit key, only one copy is stored on the server. Or, if (and this is much more likely!) a file is copied between folders or user accounts through the file manager or the API, all copies point to the same physical file.

    3. 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!
    4. Re:The problem is Mega seems to be doing de-dupe by Fr33z0r · · Score: 1

      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.

    5. Re:The problem is Mega seems to be doing de-dupe by slashmydots · · Score: 1

      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. Barracuda does that for example. So that means files hit their servers unencrypted and are analyzed before being encrypted, which puts them in the same hot water as they were in before because they could easily determine what the file is and if it's copyrighted.

    6. Re:The problem is Mega seems to be doing de-dupe by SeaFox · · Score: 1

      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?

    7. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      It applies when you have shared the duplicate file in your account with another user.

    8. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      Read the fine article, it explains it all. De-duplication is done by calculating a hash on the file data block (not the meta data) combined with your password before it is encrypted. This is then compared with a list of existing file hashes for your account. The inclusion of your password in the hash ensures that it is not comparable with any files but your own.

    9. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      Method to dedupe encrypted data:

      https://en.wikipedia.org/wiki/Convergent_encryption

    10. Re:The problem is Mega seems to be doing de-dupe by Anonymous Coward · · Score: 0

      This statement seems to be in direct contradiction with the one in the ToS

      who modded this Informative?

  25. 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."
    1. Re:Just as expected by Anonymous Coward · · Score: 0

      I too would trust them more than e.g. Dropbox. The rebuttal made clear they had nothing to hide and encouraged others to find real flaws.

  26. Do you want REALLY secure storage? by Anonymous Coward · · Score: 0

    Truecrypt or whatever you use to make encrypted file container + Dropbox or whatever doesn't force you to reupload the entire file after 1 byte change.

    or if you are feeling lazy: zip with password.

  27. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    When a noun is part of a noun phrase, it is still a noun.

  28. The biggest issue is this one by onyxruby · · Score: 1

    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 plant Trojan code into specific targets' computers, with much more far-reaching consequences.

    If they can turn off the encryption than they have lost plausible deniability. This is bad for their survival if they want to be able to claim that they don't know what they have on their servers (a brilliant move). This puts everyone's data at stake as they can be sued or re-seized back into oblivion as before.

    This may have been done to allow them to de-dupe data on their servers to save space as a practical logistical issue. This issue needs to be addressed above and beyond any other issues. Until Mega resolves this issue with a clear and unwavering answer that they /cannot/ see their data it is probably best not to upload anything confidential just yet.

    The servers are now a single point of failure and the target of attack, this is a really big deal. Please fix this Kim, I want to see your service succeed.

    1. Re:The biggest issue is this one by Anonymous Coward · · Score: 0

      How could you possibly fix that? All that is saying is, "Yes, we could put javascript on our pages to read what you're doing and send sneaky copies back to us. You have to trust us that we really are encrypting what you're uploading (unless you verify the javascript every single time)." Note the mention of "client apps through vendors they trust"- if the app is properly encrypting the data before it touches Mega's servers, you're safe in theory. You just have to trust the uploading app.

      I think this is why cryptocat wants you to download a browser plugin: if the plugin is good when you download it, and you don't update it, then even if someone pwns the cryptocat server, your client is separate and will still encrypt everything before it touches the cryptocat servers. They used to offer a no-plugin option, but with big red warnings over it saying THIS COULD BE PWNED, USE AT YOUR OWN RISK for this exact reason.

  29. Re:/. to review their grammar practises! by wonkey_monkey · · Score: 1

    How is "security practices" a case of a noun modifying a verb? If the word "security" wasn't there, "practices" is clearly a noun, so why does it suddenly become a verb when you stick "security" in front of it?

    Let's ask Google:

    +"security practises" About 10,200 results
    +"security practices" About 1,070,000 results

    --
    systemd is Roko's Basilisk.
  30. Re:/. to review their grammar practises! by Dekker3D · · Score: 2

    "Security practises": you've got some folks, referred to as "security", practising.
    "Security practices": you've got a practice, and another practice, and together they make practices.

    Makes a lot of sense, though my fingers still reach for the s key instead of c in both cases. Whoops.

  31. Re:/. to review their grammar practises! by nitehawk214 · · Score: 2, Funny

    Go learn

    Go and learn.

    Actually, just go.

    --
    I'm a good cook. I'm a fantastic eater. - Steven Brust
  32. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    Practices is not a verb in this case. It is a noun.

  33. Why would anyone ever upload anything... by John+Hasler · · Score: 2

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

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  34. not really SSL's fault by slashmydots · · Score: 1

    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 trying to save face since he props up his entire ego on what he thinks people think of him and his products.

  35. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    You are an editor of an internationally renowned news aggregation service. You'd think that you might learn some spelling and grammar.
    Go learn how to spell the noun and verb forms of practice/practise. Use them correctly, show people you're not just a keyboard jockey.

    Thanks, man. We all needed yet another good reminder that America has absolutely no monopoly on xenophobic pricks who refuse to step outside of their culture for even a second.

  36. And? by SmallFurryCreature · · Score: 0

    What is the issue here? Or are you not aware that New Zealand, the home of Mega is very early in the timezones? The day practically starts in NZ.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:And? by Anonymous Coward · · Score: 0

      It says 23th... th... th...

    2. Re:And? by Culture20 · · Score: 1

      Twenty thirth? Thirdth? Threeth?

    3. Re:And? by Anonymous Coward · · Score: 0

      ****WOOOOOOOOOOOOOSH****

      Being in NZ am I the first to woosh this guy? =D

    4. Re:And? by Roachie · · Score: 1

      Who you whoosh in NZ is your own business. Who I whoosh is mine.

      --
      This sig is not paradoxical or ironic.
  37. Never take security advice from a guy who can't re by SmallFurryCreature · · Score: 2

    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!

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

  38. It's a legitimate concern by Anonymous Coward · · Score: 0

    The TOS is the legally binding agreement. Anything else is a salesperson saying something to you. They may in fact mean what they say entirely genuinely, but that doesn't touch anything in the TOS. By the TOS, they've given themselves the legal framework and permissions to be doing exactly the kind of de-duplication the OP you replied to imples, and they're asking us to trust them that they are doing it by another method. Given "Kim Dotcom"s track record, I am disinclined to give that trust, but others may. That's up to you.

  39. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 1

    That's good advice, but we're still arguing over British English on a US-centric site. In the US, it's always "practice." In the US, it's always "license." We spell offense, defense, and pretense differently. The only -ce/-se word we agree on, off the top of my head, is advise/advice.

  40. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    The only -ce/-se word with different noun/verb spelling, I should have said.

  41. Re:/. to review their grammar practises! by Anonymous Coward · · Score: 0

    Wow - I didn't know that. US spelling certainly is full of surprises.

  42. Re:Never take security advice from a guy who can't by TechyImmigrant · · Score: 1

    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.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  43. Re:Never take security advice from a guy who can't by Anonymous Coward · · Score: 0

    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.

    The crypto applied to the static content is, by definition, 1024-bit SSL. SSL, by definition, provides both integrity and privacy.

  44. Sorry, I still don't get it... by juliohm · · Score: 1
    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 around the password change issue. They claim that changing my password will "re-encrypt" my private key, leaving my files still locked by the same key.... How exactly does that make my files "unrecoverable" ?

    Unless they are using my "encrypted private key" to lock my files in the first place... which by itself is stupid and defeats the purpose.

    If they have my private key "re-encrypted" with a new password -- and assuming I know my new password -- I should still be able decrypt the private key and unlock the files.

    If I understood this correctly, Lastpass.com uses the exact same approach and is managing fine allowing users to change their passwords.

    Did anyone figure this out? I can't quite grasp what the issue is here.

    --
    Julio Henrique Morimoto juliohm@gmail.com
    1. Re:Sorry, I still don't get it... by juliohm · · Score: 1

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

      --
      Julio Henrique Morimoto juliohm@gmail.com
    2. Re:Sorry, I still don't get it... by Anonymous Coward · · Score: 0

      You missed the distinction between a password _change_ and a password _reset_. The former will re-encrypt the private key with your new password and leave your files accessible. If you forget your password and need it _reset_, that's when your files will be unrecoverable.

  45. Re:Never take security advice from a guy who can't by TechyImmigrant · · Score: 1

    SSL protects the point to point link. But unless the web site requires you to have a client certificate or other security credential, anyone can download over https and see the plaintext.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.