Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Re:It begins, the horrible Asteroid B-movie. (Score 1) 409

It starts, with a killer asteroid hurling towards the earth.

Our hero is summoned, and immediately springs into action.

He sets out with his trusty weapon to save the world from the danger of the week.

After a long and awesome journey, he finally reach his destination.

Finally there, he slowly takes aim, breathes, and fire at The Killer Meteor. The meteor, alerted to his presence, fights back. What follows is a long action sequence only slowing down now and then so our hero can do manly poses.

After a long battle, and lots of shooting and fishing was done, there was only a small fragment left, just enough to spend the CGI budget, and show everyone how dangerous The Killer Meteor could have been.

No one was killed, and the world was again saved thanks to our hero.

The End.

Comment Yes.. (Score 1) 404

Look..

Could anyone break the Crackberry monopoly? Well yes, iPhone could, and quite spectacularly too.

Could anyone break the Symbian phone system, with all its apps? Yep, iPhone again.

Could anyone break the iPhone monopoly? Yes, Android did that.

You can't judge the future just by what is now, folks. People have tried that before:

"This 'telephone' has too many shortcomings to be seriously considered as a means of communication."

-- William Orton, president of Western Union, in 1876, when Alexander Graham Bell tried to sell the company his invention.

"There is no reason anyone would want a computer in their home."

  -- Ken Olsen, founder of Digital Equipment, in 1977.

Comment Re:Keep using the old method? (Score 1) 165

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?

Comment Just as expected (Score 4, Informative) 165

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.

Comment Re:Isn't Some of this Stuff Sort of Nitpicking? (Score 4, Informative) 151

You haven't read their own FAQ I take it?

They're actually upfront about threats to the user's security.

Is my stored data absolutely secure?

All security is relative. The following attack vectors exist - they are not specific to MEGA, but we want you to know about the risks:
Individual accounts are jeopardized by:
- Spyware on your computer. A simple keylogger is enough, but session credentials and keys could also be extracted from memory or the filesystem.
- Shoulder surfing. Do not type your password while someone could watch your keystrokes.
- Password brute-forcing. Use strong passwords.
- Phishing. Always confirm the security status of your connection (https://) and the correct domain name (mega.co.nz) before entering your password.

Large-scale attacks could be mounted through:
- A "man in the middle" attack. Requires issuing a valid duplicate SSL certificate in combination with DNS forging and/or attacks on our BGP routes (a DigiNotar-style scenario).
- Gaining access to the webservers hosting https://mega.co.nz/index.html and replacing that file with a forged version (this would not affect access through the installed app base). Note that manipulating content on our distributed static content CDN does not pose a security risk, as all active content loaded from index.html is subject to verification with a cryptographic hash (think of it as some kind of "secure boot" for websites). This type of attack requires sending malicious code to the client and is therefore detectable.
- Gaining access to our core server infrastructure and creating forged key requests on existing shares. This type of attack only affects data in shared folders and is detectable on the client side as well.

What if I don't trust you? Is it still safe for me to use MEGA?

If you don't trust us, you cannot run any code provided by us, so opening our site in your browser and entering your password is off limits. If you still want to use MEGA, you have to do so through a client app that was written by someone you trust.

Doesn't that look pretty reasonable? What more do you want them to do? They created a pretty impressive webclient-driven easy-to-use file locker system, and they clearly spell out the problems with that approach.

Many of the article's points are pretty moot, btw. It does not use JS random function, they have extra verification for the 1024 bit SSL encrypted data, and the deduplication only works for shared files ("copy to my locker" functionality is mentioned - same data, same key, same place on the storage servers).

The part about mega.co.nz being able to send malicious code stealing your password is explicitly mentioned in their FAQ, and in a better way too. They even cover other attack vectors the article didn't.

They made a decent system, and they're upfront and honest about it's limitations. The article is at best FUD.

Comment Re:Isn't Some of this Stuff Sort of Nitpicking? (Score 2) 151

Dedupe update:

"Deduplication is done based on the entire encrypted file and only happens if you either upload the same file encrypted with the same key twice (unlikely) or if you copy or import an existing file in your file manager (more likely)."

I was saying something about wild assumptions... Yep..

Comment Re:Isn't Some of this Stuff Sort of Nitpicking? (Score 2) 151

ALL of it is nitpicking, or just plain out wrong.

Lemme see, SSL part. Well, main site use 2048 bits, and the JS on that page loads and verifies all other resources. And file upload / downloads are already encrypted before SSL even touches them. So that point is completely moot.

And the "Mega server could send bad code" is already covered in Mega's own FAQ - well,duh. I doubt it comes as a shock to anyone.

As for the deduplication, I don't know. But there are ways to do that (like using file content hash as encryption key, for example - no idea if they actually do this - or just try to dedup the actual encrypted content. There is a (well, small) chance that two encrypted files have same data in a block). We just don't know, and making wild assumptions from it is .. just wrong.

Also, Mega does in fact NOT use JS random function. It use time sampling from user generated events, with RC4 as mixing function.

The whole article is just stupid. It makes wild assumptions, doesn't understand how (parts of) the site works, repeat things the site already informs users about, and are just plain wrong on some parts.

Is this yet another troll article by some attention hungry ad pushers?

Slashdot Top Deals

"The most important thing in a man is not what he knows, but what he is." -- Narciso Yepes

Working...