Mega Defends Its Security Practices 165
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."
January 23th (Score:4, Funny)
January 23th is the date of the press release. Just... I guess that's minor compared to alleged encryption issues.
Re:January 23th (Score:5, Funny)
I don't thee that there'th anything wrong with it. It lookth jutht fine to me.
Re: (Score:2)
It's encrypted.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Who you whoosh in NZ is your own business. Who I whoosh is mine.
That is an ignorant response. (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.
Re:That is an ignorant response. (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.)
Re: (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.
Re: (Score:3)
What kind of weed do you smoke? I quoted him literally and used [sic] to point out a typo.
Re: (Score:2)
I admit that there was no typo in the first place, though.
Re: (Score:2)
Re: (Score:3)
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!
Re: (Score:1)
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.
Re: (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?
Re: (Score:2)
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.
Re:That is an ignorant response. (Score:5, Interesting)
At least until you buy drugs
Re: (Score:2)
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.
Re: (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/ [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
Re: (Score:3)
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.
Re: (Score:2)
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).
Re: (Score:2)
Re:That is an ignorant response. (Score:5, Insightful)
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.
Re:That is an ignorant response. (Score:4, 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.
Re: (Score:2)
Never take security advice from a guy who can't re (Score:3)
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!
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Keep using the old method? (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?
Re: (Score:3)
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?
Re:Keep using the old method? (Score:4, 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
Re:Keep using the old method? (Score:4, 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.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:1)
JavaScript local file access APIs (Score:4, 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 [caniuse.com]. 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?
Re: (Score:1)
....because it redirected him to that stupid message, instead of letting him read the article?
Re: (Score:2)
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.
Re: (Score:2)
To be clear, the webserver is serving web pages just fine; its your browser / JS engine that is failing to interpret them properly.
Re: (Score:2)
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 [caniuse.com]. 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)
Re: (Score:1)
You are in possession of the iPhone,the failure is on your side, chump.
Re: (Score:2)
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!
The biggest security hole (Score:5, Informative)
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).
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re:The biggest security hole (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...
Re:The biggest security hole (Score:5, Interesting)
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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.)
Re: (Score:2)
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...
I hate mobile "optimized" sites! (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
Re: (Score:2)
Hit the menu key on your phone and click "Request Desktop Site", or is this something else iPhones don't do?
User agent change vs. unimplemented objects (Score:2)
Re: (Score:2)
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 [mega.co.nz] might be temporarily down or it may have moved permanently to a new web address".
Minimal effort (Score:3)
levels of trust (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (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.
Re: (Score:2)
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
IPv6less (Score:2)
New global and high visibility service, without IPv6 service. The future is apparently briefly visiting the elsewhere.
Its not about confidentiality. (Score:5, Insightful)
This rebuttal is clear, concise and correct (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.
Re: (Score:1)
Of course, I still think Tahoe-LAFS is a better idea. :-)
Re: (Score:2)
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
Re: (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.
The problem is Mega seems to be doing de-dupe (Score:3)
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]
Re:The problem is Mega seems to be doing de-dupe (Score:5, 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.
Re: (Score:2)
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?
Re: (Score:2)
That implies block-level dedupe, it'll be looking at chunks, doesn't matter if the files themselves are encrypted or not.
Re: (Score:2)
Real dedupe programs for non-encrypted files typically ignore meta data like that when comparing two files. Ba
Just as expected (Score:5, Informative)
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.
The biggest issue is this one (Score:2)
Why would anyone ever upload anything... (Score:3)
...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.
not really SSL's fault (Score:2)
Sorry, I still don't get it... (Score:1)
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
Re: (Score:1)
Re: (Score:1)
Re:/. to review their grammar practises! (Score:4, Funny)
You are an editor of an internationally renowned news aggregation service.
You mean Fark?
Re: (Score:2)
Go learn
Go and learn.
Re: (Score:3, Funny)
Go learn
Go and learn.
Actually, just go.
Re: (Score:2)
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
Re: (Score:3)
"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.
Re: (Score:1)