Mega responds to security concerns, implements password changes

Mega responds to security concerns, implements password changes

Summary: Mega has stepped up to right the record on how its security has been scrutinised, acknowledging its faults, correcting misinformation, and sharing what it plans to do to make it more secure.

SHARE:
12

Since Mega launched, there have been many concerns over how it handles security, from the encryption used, to the lack of account recovery options. But now that researchers and the media have discussed the issues, Mega has responded. Mega was "not too impressed," but it has taken the time to acknowledge the arguments that were correct and reveal what it plans to do about them.

Mega confirmed that users currently have no means to change their password, quoting Ars Technica, which previously said that "Losing [your password] means you don't just lose the ability to log on to the service — you lose the ability to decrypt your files, period."

To address this, Mega stated that it would implement a password change feature that will "re-encrypt the master key with your new password," as well as implement a password reset mechanism.

The reset mechanism is purely to allow the user to log back into their account, but it will not allow users to read their existing files, as those would have been encrypted using their previous key. That isn't a problem if the files were encrypted using pre-exported keys, or if the files were shared with others with a specific shared key, but other than that, files will not be accessible without the original key.

An additional enhancement that will be rolled out at a later date is the ability to add even more randomness, or entropy, to how RSA keys are generated upon sign up. At the moment, keys are generated using the Math.random() function, and while alone, this function only produces pseudo-random numbers that can be guessed, additional entropy is already provided by asking using the input of the user's mouse movement and keyboard strokes. The future enhancement will allow the user to add additional entropy manually, if they so desire, rather than during the relatively brief period currently available.

Another question raised several times by researchers was how Mega manages de-duplication. Its terms of service essentially state that if more than one user uploads duplicate data, it has the right to simply link to the same data, rather than write it twice, or more, to storage. One of the key benefits of doing so is to ensure that storage space isn't wasted.

Since the data is encrypted, users have questioned how Mega would know that the data is duplicated, leading to accusations that Mega either doesn't encrypt the data, or it holds decryption keys itself for the purpose of comparing data.

What Mega does, however, is compare the encrypted data, regardless of what its unencrypted form is. The real intent of the clause is actually for cases where a single user stores multiple copies of the same file, or when a file, encrypted with a shared key, is copied across multiple accounts.

While Mega conceded on these two points and has plans to address them, there were also a number of incorrect accusations that the site faced, including that it verified its own Javascript code — generating trust from an untrusted source — and that its SSL server used outdated 1024-bit encryption.

Mega has two sites; the front facing mega.co.nz, and static.co.nz. The former uses 2048-bit encryption and is trusted, while the latter used 1024-bit encryption and could be arguably seen as untrusted. However, as static.co.nz serves code to mega.co.nz — the trusted, secure server — it is verified to ensure that it hasn't been modified during a man-in-the-middle attack.

There was also an argument that if an attacker could circumvent SSL encryption, Mega's security would be broken. Mega acknowledged this fact, but also put the capabilities of such an attacker into perspective, stating at "if you can break SSL, you can break a lot of things that are even more interesting than Mega."

Lastly, Mega briefly acknowledged the existence of the MegaCracker tool, designed by security researcher Steve Thomas. In a little under 24 hours, Thomas, also known as Sc00bz, developed a small application to extract users' passwords from the account confirmation email sent by Mega at the time of sign up.

This email contains a confirmation code that has a hashed version of the user's password embedded in it. MegaCracker takes this confirmation code, strips out the hash, and attempts to crack it against a list of passwords supplied by the attacker.

Mega's implementation of account confirmation can be considered marginally better than the poor practice of sending plaintext passwords back to the user at sign-in, as the hash must be cracked to recover the password. It also relies on an attacker obtaining the email, although many older email providers still do not use a secure connection, making it easy for emails to be sniffed on shared wireless connections.

The probability of successfully cracking a user's password hash is significantly lower for passwords that follow good practices, such as not picking dictionary words, and Mega has simply said that MegaCracker serves as "an excellent reminder not to use guessable/dictionary passwords."

Topics: Security, Cloud, New Zealand

Michael Lee

About Michael Lee

A Sydney, Australia-based journalist, Michael Lee covers a gamut of news in the technology space including information security, state Government initiatives, and local startups.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • Mega smokescreen

    Why wouldn't Mega just admit that sending hashed passwords via email is a stupid mistake and say that they'll stop doing that?

    According to Mega, MegaCracker serves as "an excellent reminder not to use guessable/dictionary passwords." That may be true, but in order for your password to be secure, first you need to choose a reasonably good one and then the provider needs to handle the password in a smart way.

    Why won't they use a hash function that's appropriate for passwords instead of the one that they're using? Don't they know that there are certain hash functions which are considered appropriate for passwords and that the one they're using, well, isn't?

    The problem is that because they're using an inappropriate hash function for storing the passwords, the idea that "you're okay as long as your password is complex" doesn't stand up. As it is, all passwords are practically vulnerable, not just simple ones.

    Also, do people realize that they have these hashes stored on the server side too, so that if the server is compromised by a raid/seizure, or is hacked, all of the encrypted data on the server is vulnerable, because the password hashes will easily yield the actual passwords?
    ldecoursey
  • Is Mega real?

    I 'signed up' over 48 hours ago, and still have not received a confirmation email. I have received an influx of spam since then, and Mega is the only place it could be coming from.

    Maybe there is a reason people are trying to put this guy in jail.
    pishaw
    • Worked fine for me

      Maybe you ended up on the wrong site? (phishing)
      Natanael_L
  • Doesn't stand up

    I'm actually excited to see a free cloud storage provider offering built-in client-side encryption, a smooth interface, and excellent sharing features. It's an awesome product from a feature standpoint.

    But I am really perplexed with the idea of the provider holding the encryption keys, and all of the data being obtainable with just the password. How many larger, more sophisticated companies have had major password leaks in the past year? And if it's already known and pointed out that Mega is using precisely the weak sort of password storage that's advised against...

    This just about fully negates the benefit of doing the encryption client side. I would really like to see the encryption keys kept fully on the client side, never revealed to the cloud at all (not even in the "encrypted" form), and required to decipher the data (not just the password).

    I get it that for usability reasons, some will prefer to have all of the secrets fully in the cloud and accessible from anywhere with just the password, but I would like to have an advanced option to turn up some better security. And a standalone app that I can download once and validate the integrity of.
    Win8AnUglyDisaster
    • Master keys

      Well, it does use master keys. Those encryptions keys are also stored in an encrypted form, and Mega can't read them without your password. If they've done it right, they never see your password, and those encryption keys are decrypted client side with your password.

      If you dare to store the encrypted files there, why not encrypted keys?

      Just keep your password safe.
      Natanael_L
      • Password security

        It's impossible to keep your password safe because the registration process exposes way too much information about the password to the provider.

        It seems like they should have used some sort of zero knowledge proof for authentication, or at least a peer-reviewed password hash e.g. bcrypt or PBKDF2.

        As it is, they're emailing you an easily-cracked hash of your own password. You may as well assume they have your password from the get go. It's unreasonable to assume otherwise.
        beau parisi
  • "Hey it’s all encrypted we have no clue what’s in there…"

    Your encrypted files are no more secure than the software that encrypts them, that’s why open, peer-reviewed crypto systems are preferred. Mega seems to be nothing of that.

    If you are the type who understands this level of security then Mega’s “encryption” isn’t for you. It’s just a marketing hype.
    beau parisi
    • There's a lack of *easy* options

      I haven't seen any open protocol for file storage/sync yet with secure encryption where there are decent clients for most platforms.
      Natanael_L
  • Taking a stab at current status roundup on these items

    Okay so there have been a lot of claims and counterclaims in various articles, on the Mega site, on Twitter, etc. I figured it would be a good idea to try to summarize the current status of the various reports, Mega's responses, and current status. Let me know if you see anything incorrect or if there's anything that you can add. Then hopefully we can work from here.


    Issue: The key used to encrypt your Mega files and folders is stored on Mega's servers, rather than on your local computer.

    Mega Response: This is correct - the only key that MEGA requires to be stored on the user side is the login password, in the user's brain. This password unlocks the master key, which in turn unlocks the file/folder/share/private keys.

    Current Status/Next Steps: Working as designed, but not as secure as it would be if the key was stored on the PC instead of on Mega's servers. Only secure if neither Mega nor any 3rd party can guess or crack your password, because only your password is required to access your data.


    Issue: It is telling that there appears to be no password recovery mechanism anywhere in the Mega or log-on screens, nor any method of changing your password in the user control panel.

    Mega Response: Because the master AES-128 key is encrypted using your password, remembering the password is vital. In the near future it will be possible to change your password if you have the old one, and to reset it otherwise, but resetting a lost password will cost you your data.

    Current Status/Next Steps: Works as designed, but waiting for Mega to implement new feature enhancements.


    Issue: 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. Also anybody who can break the SSL could do the same.

    Mega Response: Correct, but any software maker offering online application updates is able to plant Trojan code into specific targets' computers, and anybody who could break SSL would have more interesting targets than Mega.

    Current Status/Next Steps: Working as designed, but not as secure as standalone software which can be downloaded once and/or would need to ask permission to update. The main Javascript is doing some validation of the crypto Javascript, but the core Javascript is still susceptible to being modified in an attack. Right now the Javascript is downloaded fresh every time, not practical to look at the code every time.


    Issue: The Mega client sends a weakly-hashed copy of the login password to the Mega back-end despite that the security model requires that the password be kept secret on the client side. Anybody in possession of the password hash can turn it back into the password without too much difficulty. Mega also sends the hash by email.

    Mega Response: Mega warns against using weak passwords to mitigate exposure to this vulnerability.

    Current Status/Next Steps: Encrypted data potentially at risk on Mega back-end because Mega was given information about the password that it shouldn't know, presumably has stored that information. Potential improvement would be for the client to use a less-sensitive means of authenticating with the back-end that doesn't put the password at so much risk, but Mega has not yet publicly responded on this point. Also could be significantly more secure if the encryption keys were stored on the PC rather than on the back-end, but this is just not how it's designed. Overall, works as designed but potentially could be designed more securely.
    Roger G
  • Missing the point

    It seems we've established (very thoroughly) that Mega should not be trusted to keep our files secure.

    But that's not the point of their crypto; it's just an effort to ensure plausible deniability that happens to be a marketable feature.

    If your objective is to stash sensitive files, there are plenty of established options.

    It's obvious that Mega was not intended to serve such a purpose, so the criticism strikes me as pointless except for its instructional/entertainment value.
    beau parisi
  • Plausible Deniability

    Yes. It seems the purpose of all this encryption is simply to ensure that at least Mega cannot "see" what users upload. We just got caught up in the "encryption" PR and assumed this might be the simple online encryption solution we have all been looking for. It is not. In fact the URL to the content includes the passphrase, meaning that every time you request the file, you are sending all of the information Mega needs to "look" at the unencrypted content. I assume they will not store this to maintain plausible deniability. And maybe there is a method to download the fully encrypted file without sending the passphrase... Im not sure.
    It would have been nice if this was the backbone solution that others could build apon to eaily provide secure cloud storage, but instead it just seems like a large deposit box that others are going to have to write complex client side software to get the encrypted online solutions we want. And that will just be one more level of trust required.
    I hope this solution does work for them and provides them with the plausibility they need to keep the world police from stealing legitimate data from millions of clients again.
    Pea Wormsworth
  • Copy.com

    I almost tried everything including kim dotcoms mega. Copy.com has and edge over others in speed and storage space they provide.

    They provide 20 GB for starters for free and 5 GB each you refer..
    here is a link if you want to sign up
    https://copy.com?r=IroDcA

    It will make me smile and give you 5 Gb as well.
    adroit17