How can mega store my login details and still be secure?

Question

I understand how Mega's encryption works. For a quick summary of all those in the future looking for an answer on this... here is how it works:

Upon first signing up for an account you make a username and password. It also generates a symmetric key which is used to encrypt your files and a RSA key pair to share secrets securely when files are sent to other peoples "inboxes". Once the client has both these, the symmetric key is encrypted with your password and uploaded to the server. This way only someone with your password can decrypt your symmetrical key and then decrypt your files. I'll leave it at this for now as thats all that is relevant to my question.

If my symmetric key is encrypted with my password, no matter how secure my key is would it not still be as weak as the hashing function they use to store my password on their server? This ties into my second question, do they even store a hash of my password? I'm thinking along the lines of no, as it would weaken the encryption hugely, but Mega still needs to be able to determine if your login details are correct. How can they do this without compromising their encryption?

This may be the wrong place for asking this, so please move it if appropriate.

Answer 1

I don't know what Mega is doing. They haven't published a design document that describes how their system addresses these threats. That's irresponsible on their part, and it doesn't invite trust. Cryptographers have already criticized Mega for sloppy engineering, and researchers have found a bunch of security problems, vulnerabilities, and design issues. Consequently, I wouldn't use Mega for anything super-sensitive at this point in time.

While I don't know for certain what they are doing, my guess/hope is that they are using a slow hash function or slow KDF to derive a key from your password. In other words, they might derive the key $K$ from your password $P$, via $K=H(P)$, where $H$ is some hash algorithm that is fairly slow -- it might take 1 millisecond to compute, for example. Then, Mega might encrypt your data using this derived key $K$. Or, they might encrypt a session key using $K$ and encrypt your data under the session key, and store the encrypted data and encrypted session key.

Assuming this is what they do, the result is: brute-force attacks on your password remain possible.

For example, if the slow hash takes 1 millisecond to hash your password, then brute-force attacks will need to spend about 1 millisecond per guess at your password. (Probably less, because the attacker may be using a faster computer or a better-optimized implementation of the hash.) Thus, use of a slow hash increases the cost of brute-force attacks but does not eliminate the threat entirely. If your password is long enough and strong enough, brute-force attacks might be impossible. But for many people who choose mediocre passwords or passwords, brute-force attacks will likely still be a serious threat.

For a bit more detail, see this advice: Try to avoid using passwords as encryption keys.

Answer 2

Here are some hints on how it's done on Mega:

The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call).

To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of the web client in file crypto.js.

The user supplied password itself is never sent over the wire. And the master key is only decrypted client side using this password-derived 128 bit AES key.

To log in against the Mega servers, which gives one a valid session that allows one to access the (encrypted) master key, a token is computed. This token is computed using the derived key (see above) by running it through an additional series of $2^{14}$ rounds of AES-128 (see the stringhash function in crypto.js) after "joining" the user's email address with the above mentioned derived key.

D.W. is right, that the procedures in place are unfortunately not properly documented, yet. This is a severe shortcoming that needs to be rectified over time. Having said that, newer cryptographic work by Mega is paired with documentation in the form of a white paper as it is implemented to allow for peer review. These white papers are currently not openly published, yet, but interested parties have received these easily as needed or as requested, as they're still somewhat in flux.

If anybody is interested in further information, please feel free to email [email protected] for this to get first hand answers. However, that should still hold nobody back from discussing here or elsewhere, though it seems not easy to get explicit answers from the Mega developers here without letting them know of a question raised here.

Update:

There's an independent study that has been conducted by a researcher team in Spain: English PDF. They have dug into the available JavaScript code and reasoned on it. Except for minor flaws, the information is pretty much correct.

Answer 3

Here's a possible scenario:

1) Your password is put through a slow KDF such as Scrypt. The output of Scrypt can be configured to take a long time to calculate, and as such, can mitigate the risk of brute-forcing passwords. See here.

2) The output length of Scrypt is also configurable. So assume that half of the output becomes the encryption key for your symmetric key, and the other half is stored to identify you when you log-in.