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."
January 23th is the date of the press release. Just... I guess that's minor compared to alleged encryption issues.
--Jim (me)
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.
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?
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
You are an editor of an internationally renowned news aggregation service.
You mean Fark?
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.
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
New global and high visibility service, without IPv6 service. The future is apparently briefly visiting the elsewhere.
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?
The encryption is there for mega to maintain plausable deniabity about copyright infringement. If you want to keep something private don't upload it to mega. The question is not whether the encyrption scheme is sound, but whether it is reasonable in court to expect a company to break encryption (and most likely laws) to ferret out copyright violations.
Or, without actually delving into their Javascript to verify their claims myself it's correct.
I still don't like the idea of them holding the key, even encrypted. It does set it up so if a government wants to figure out what files I have, they have to get Mega to capture my key after my password decrypts it, but that's not so hard.
But that sort of thing is still significantly better than most cloud storage services.
Need a Python, C++, Unix, Linux develop
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!
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."
"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.
Go learn
Go and learn.
Actually, just go.
I'm a good cook. I'm a fantastic eater. - Steven Brust
...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.
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.