×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mega Defends Its Security Practices

Unknown Lamer posted about a year ago | from the excuses-excuses dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

165 comments

January 23th (3, Funny)

Balthisar (649688) | about a year ago | (#42668995)

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

Re:January 23th (5, Funny)

wcrowe (94389) | about a year ago | (#42669147)

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

And? (0)

SmallFurryCreature (593017) | about a year ago | (#42670869)

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.

Re:And? (0)

Anonymous Coward | about a year ago | (#42671085)

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

Re:And? (-1)

Anonymous Coward | about a year ago | (#42671097)

January 23th.

23th.

That's what he's making fun of. You moron.

/. to review their grammar practises! (-1, Offtopic)

Anonymous Coward | about a year ago | (#42669003)

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.

Re:/. to review their grammar practises! (1)

jgeeky (974074) | about a year ago | (#42669111)

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

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669155)

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

Re:/. to review their grammar practises! (3, Funny)

j00r0m4nc3r (959816) | about a year ago | (#42669165)

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

You mean Fark?

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669185)

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.

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669351)

original A/C...

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

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669631)

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

Re:/. to review their grammar practises! (1)

wonkey_monkey (2592601) | about a year ago | (#42669655)

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:/. to review their grammar practises! (2)

Dekker3D (989692) | about a year ago | (#42669779)

"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:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669893)

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

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669205)

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.

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42669445)

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.

Re:/. to review their grammar practises! (0)

Anonymous Coward | about a year ago | (#42670437)

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.

That is an ignorant response. (4, Insightful)

jellomizer (103300) | about a year ago | (#42669017)

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

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

Re:That is an ignorant response. (-1)

Anonymous Coward | about a year ago | (#42669231)

Security's weakest link: Users. But that's no longer Mega, but security in general.

Re:That is an ignorant response. (5, Informative)

aaaaaaargh! (1150173) | about a year ago | (#42669327)

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

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

Re:That is an ignorant response. (2, Informative)

Anonymous Coward | about a year ago | (#42670639)

"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:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42671077)

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.

Re:That is an ignorant response. (1)

interkin3tic (1469267) | about a year ago | (#42670921)

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?

Re:That is an ignorant response. (4, Interesting)

DJ Jones (997846) | about a year ago | (#42669367)

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

Re:That is an ignorant response. (1)

LordLimecat (1103839) | about a year ago | (#42669995)

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:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42670325)

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

Re:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42670483)

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

Re:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42670169)

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.

Re:That is an ignorant response. (4, Insightful)

Havokmon (89874) | about a year ago | (#42669385)

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.

Re:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42669409)

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.

Re:That is an ignorant response. (3, Informative)

LordLimecat (1103839) | about a year ago | (#42669967)

I mean any basic network now uses switch over hubs now, So traffic is routed more cleanly to the host system with less spots for you packet sniff

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

Who actually reads data packets anyways nowadays?

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

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

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

Re:That is an ignorant response. (1)

bluefoxlucid (723572) | about a year ago | (#42670369)

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.

Never take security advice from a guy who can't re (2)

SmallFurryCreature (593017) | about a year ago | (#42670913)

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:That is an ignorant response. (0)

Anonymous Coward | about a year ago | (#42670411)

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.

Re:That is an ignorant response. (1)

jellomizer (103300) | about a year ago | (#42670703)

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.

Keep using the old method? (5, Informative)

cseg (253752) | about a year ago | (#42669021)

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

Re:Keep using the old method? (0)

Anonymous Coward | about a year ago | (#42669127)

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.

Re:Keep using the old method? (2)

PPH (736903) | about a year ago | (#42669689)

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:Keep using the old method? (0)

Anonymous Coward | about a year ago | (#42669733)

the implementation is extremely shakey

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

Re:Keep using the old method? (2)

Tom (822) | about a year ago | (#42669499)

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? (0)

Anonymous Coward | about a year ago | (#42669679)

50 gigabytes instead of 2

Re:Keep using the old method? (3, Insightful)

Dekker3D (989692) | about a year ago | (#42670447)

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

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

Re:Keep using the old method? (0)

Anonymous Coward | about a year ago | (#42669907)

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

Re:Keep using the old method? (1)

MozeeToby (1163751) | about a year ago | (#42670671)

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:Keep using the old method? (1)

Terrasque (796014) | about a year ago | (#42670837)

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:Keep using the old method? (1)

Anonymous Cod (2647669) | about a year ago | (#42671223)

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:Keep using the old method? (1)

History's Coming To (1059484) | about a year ago | (#42670699)

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.

I actually tried, but I can't RTFA (0)

Anonymous Coward | about a year ago | (#42669083)

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?

Re:I actually tried, but I can't RTFA (0)

Anonymous Coward | about a year ago | (#42669227)

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

JavaScript local file access APIs (3, Insightful)

tepples (727027) | about a year ago | (#42669317)

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:JavaScript local file access APIs (1)

Anonymous Coward | about a year ago | (#42669543)

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

Re:JavaScript local file access APIs (1)

Minwee (522556) | about a year ago | (#42669581)

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:JavaScript local file access APIs (1)

LordLimecat (1103839) | about a year ago | (#42670023)

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

Re:JavaScript local file access APIs (1)

nitehawk214 (222219) | about a year ago | (#42670047)

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:I actually tried, but I can't RTFA (1)

Anonymous Coward | about a year ago | (#42669321)

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

Re:I actually tried, but I can't RTFA (1)

tidepool (137349) | about a year ago | (#42669633)

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!

Way to go, MEGA! (0)

Anonymous Coward | about a year ago | (#42669095)

Very reassuring, objective, and clarifying rebuttal.

This issue wasn't the use of SSL (0)

Anonymous Coward | about a year ago | (#42669121)

But the questionable storage and usage of certain cryptographic information.

The biggest security hole (5, Informative)

bfandreas (603438) | about a year ago | (#42669131)

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

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

Re:The biggest security hole (1)

dimeglio (456244) | about a year ago | (#42669209)

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:The biggest security hole (1)

bfandreas (603438) | about a year ago | (#42670883)

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.

Re:The biggest security hole (5, Insightful)

aaaaaaargh! (1150173) | about a year ago | (#42669373)

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

Re:The biggest security hole (4, Interesting)

tlhIngan (30335) | about a year ago | (#42670635)

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

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

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

Re:The biggest security hole (1)

bfandreas (603438) | about a year ago | (#42670845)

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.

Re:The biggest security hole (1)

Spottywot (1910658) | about a year ago | (#42669551)

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.

Re:The biggest security hole (1)

interval1066 (668936) | about a year ago | (#42670053)

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:The biggest security hole (0)

Anonymous Coward | about a year ago | (#42669597)

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!

I hate mobile "optimized" sites! (1)

Anonymous Coward | about a year ago | (#42669161)

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:I hate mobile "optimized" sites! (1)

whoda (569082) | about a year ago | (#42669297)

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

Re:I hate mobile "optimized" sites! (1)

rwise2112 (648849) | about a year ago | (#42669481)

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 (2)

gmuslera (3436) | about a year ago | (#42669177)

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

levels of trust (3, Insightful)

fermion (181285) | about a year ago | (#42669191)

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.

Re:levels of trust (-1)

Anonymous Coward | about a year ago | (#42669353)

No dumbass, they're not saying anything about trusting their implementation of SSL. They're saying if someone (government, crooks) can break your SSL connection to Mega, then the bad guys can break your SSL to other places you go in the internet, which is true.

Re:levels of trust (1)

nschubach (922175) | about a year ago | (#42669399)

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:levels of trust (2)

Tom (822) | about a year ago | (#42669469)

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:levels of trust (1)

Anonymous Coward | about a year ago | (#42670091)

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.

IPv6less (2)

arttulaine (258278) | about a year ago | (#42669273)

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

Nothing wrong with it (-1)

Anonymous Coward | about a year ago | (#42669359)

There is nothing wrong with it, this is a case of political terrorist trying to damage Kim Dotcom further, and the political terrorist are doing it by trying to scare people into thinking the service does not work.

Sorry New World Order, but we are not fooled by your crap any more. If the choice for me is to believe kim Dotcom, or believe some government representative, then I will believe Kim Dotcom.

Its not about confidentiality. (5, Insightful)

jzilla (256016) | about a year ago | (#42669397)

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.

MEGA IS A MOTHERFUCKING LIP_SYNCING . .. MOTHER FU (-1)

Anonymous Coward | about a year ago | (#42669423)

CKER !!

Boney M !!

Milli Vanilli !!

Beyonce !!

And who names their kid Beyonce ??

Another lie perpetrated by the man to keep the brother down !!

This rebuttal is clear, concise and correct (3, Insightful)

Omnifarious (11933) | about a year ago | (#42669471)

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.

The problem is Mega seems to be doing de-dupe (2)

sl4shd0rk (755837) | about a year ago | (#42669531)

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

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

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

Re:The problem is Mega seems to be doing de-dupe (0)

Anonymous Coward | about a year ago | (#42669657)

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.

It's a legitimate concern (0)

Anonymous Coward | about a year ago | (#42670967)

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.

Re:The problem is Mega seems to be doing de-dupe (0)

Anonymous Coward | about a year ago | (#42669787)

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.

Re:The problem is Mega seems to be doing de-dupe (4, Informative)

jkflying (2190798) | about a year ago | (#42669811)

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

Re:The problem is Mega seems to be doing de-dupe (1)

SeaFox (739806) | about a year ago | (#42670649)

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:The problem is Mega seems to be doing de-dupe (1)

Fr33z0r (621949) | about a year ago | (#42670277)

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.

Re:The problem is Mega seems to be doing de-dupe (1)

slashmydots (2189826) | about a year ago | (#42670395)

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.

Just as expected (4, Informative)

Terrasque (796014) | about a year ago | (#42669587)

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.

Re:Just as expected (0)

Anonymous Coward | about a year ago | (#42669681)

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.

Do you want REALLY secure storage? (0)

Anonymous Coward | about a year ago | (#42669591)

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.

The biggest issue is this one (1)

onyxruby (118189) | about a year ago | (#42669651)

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.

Re:The biggest issue is this one (0)

Anonymous Coward | about a year ago | (#42669999)

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.

Why would anyone ever upload anything... (2)

John Hasler (414242) | about a year ago | (#42670037)

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

slashmydots (2189826) | about a year ago | (#42670349)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...