Cracking tool milks weakness to reveal some Mega passwords (Updated)

Yet another security researcher is poking holes in the security of Mega, this time by pointing out that the confirmation messages e-mailed to new users can in many cases be cracked to reveal their password and take over their Mega accounts.

Steve "Sc00bz" Thomas, the researcher who uncovered the weakness, has released a program called MegaCracker that can extract passwords from the link contained in confirmation e-mails. Mega e-mails a link to all new users and requires that they click on it before they can use the cloud-based storage system, which boasts a long roster of encryption and security protections. Security professionals have long considered it taboo to send passwords in either plaintext or as cryptographic hashes in e-mails because of the ease attackers have in intercepting unencrypted messages sent over Internet.

Despite that admonishment, the link included in Mega confirmation e-mails contains not only a hash of the password, but it also includes other sensitive data, such as the encrypted master key used to decrypt the files stored in the account. MegaCracker works by isolating the AES-hashed password embedded in the link and attempting to guess the plaintext that was used to generate it.

"Since e-mail is unencrypted, anyone listening to the traffic can read the message," Thomas told Ars. "It makes no sense to send a confirmation link with a hash of your password."

In addition to the ease of intercepting e-mails as they traverse the Internet, the confirmation link could be recovered by government-backed investigators or others with a legal subpoena. Mega officials didn't immediately respond to a request for comment. On its website, the service said MegaCracker is "An excellent reminder not to use guessable/dictionary passwords, specifically not if your password also serves as the master encryption key to all files that you store on MEGA."

This long string is, in fact, six shorter strings, that include the encrypted master key (70491be7c3858d0698b282b993d5ed69), the AES-hashed user password (ba7fd1c38b5a5073ef73679eb9c7bd48), as well as hashes hexes of the e-mail address (63797275732e6661726976617240617273746563686e6963612e636f6d), user's name (43797275732046617269766172), and two other elements Thomas still hasn't identified.

MegaCracker simply isolates the password hash and provides a platform for cracking it. The program requires crackers to supply their own list of word guesses. With the ability to guess 120 to 600 passwords per second it's a bit on the slow side, although it works faster with a precomputed file. With a bit of tweaking, oclHashcat-plus and other standalone password crackers could probably be used crack the hashes much more quickly.

Thomas said the inclusion of a password hash and encrypted master key is highly unusual in confirmation e-mails. Similar e-mails sent by Netflix, Amazon, Twitter, and other services send links containing a random value that only the receiver and the server know.

An attacker could use MegaCracker to reveal weaker passwords, and then use that passcode to decrypt the encrypted master key. From there, the attacker can take complete control of someone's Mega account and all the encrypted data stored in it.

Thomas is just one of the security researchers who has taken Mega's new service to task. Articles posted in the past 24 hours by Forbes and IDG News advised readers to be wary of the encryption provided by the service. Much of the criticism rests on the reliance of in-the-browser encryption from the SSL (secure sockets layer) protocol, which has been repeatedly bypassed over the years, most recently in late 2012. In its response, Mega officials didn't dispute that claim, writing only: "But if you can break SSL, you can break a lot of things that are even more interesting than MEGA."

Expect to see a steady stream of critiques and fixes in Mega's security hygiene in the coming weeks, as researchers delve in further and Mega engineers respond. As Ars has long counseled, readers would do well to remain highly skeptical of storing anything confidential online unless the encryption has been certified by outside auditors, or at least has been used for a few years with no reports of compromise or serious security flaws.

Update

After this article was published Mega CTO Mathias Ortmann emailed a statement that indicates anyone who chose a weak password when registering their account has been temporarily stuck with the bad passcode. The statement, which is included in its entirety below, also seems to defend the decision to embed sensitive information in the plain-text emails Mega sends users:

Weak passwords that are at risk of being cracked through dictionary attacks or brute-forcing are a huge security risk. It makes no difference whether one attempts to mitigate that fact through security by obscurity or not. UNIX originally had world-readable user password hashes - a design decision that, assuming sufficiently strong passwords, did not jeopardize account security at all. Unfortunately, real users all too often used weak passwords, and the design was changed and obscurity (moving the password hashes to shadow file) added.

In a context where the password not only guards the login process itself, but also serves as the master encryption key to confidential data, obscurity instead of a strong password is simply not good enough.

We will add a password change capability shortly so that anyone who has picked a poor password can rectify that.

Promoted Comments

why would someone with that much experience make a blunder that seems like such a rookie mistake?

Schedule pressure (anniversary of the raid!), and different programmers or teams coding the various functions? There might not have been as much experience applied to the back-end, new user mailer. (That's speculative, and certainly doesn't exonerate them in any way - it's sloppy no matter how you view it.) It's an old story, though: things like that sometimes take a much lower priority than, and come long after, the core functionality is coded; they're often done in haste and get far less, if any, comprehensive testing or review. Almost afterthoughts. Still pretty sad, though.

All that certainly I suppose, but I think you miss the point.

Mega is not designed to primarily be safe for the users and their data. Mega is designed to be safe for the owners and operators of Mega first and foremost. In spite of their claims to security for the users, that was never the point. The point was to build a file-sharing system where the operators had no control or knowledge of the data that was stored to protect the owners from civil and criminal liability. This, they seem to have accomplished.

Believing they built Mega for you and the security of your data is a bit pie-in-the-sky. It was never the primary goal at all.

Here's the thing for me. Mega has never done anything considered a high-security, cryptographically strong private service before. What expertise do they bring to the table that anybody *expected* them to get this right? I fully expected this service to be full of holes on day one. Maybe someday they'll get it right, though, if they are willing to take security analysis from other seriously, and quickly move to correct the problems.

Still, it seems like they seriously need to get someone on staff who is like their "Chief data security officer", who has the expertise and power to make sure nothing ships before it's actually secure.

Edit: I forgot to add: anyone actually concerned about privacy should run FAR away from Mega, as it's clear the people at the top of the company put release dates and hype before security and functionality.

CTO dude said: UNIX originally had world-readable user password hashes - a design decision that, assuming sufficiently strong passwords, did not jeopardize account security at all. Unfortunately, real users all too often used weak passwords, and the design was changed and obscurity (moving the password hashes to shadow file) added.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess. For example, renaming your /admin/ directory on your website to /banana/ and, if someone happens to browse to /banana/, they can easily figure out how to escalate to admin after that. However if you have all other proper controls in place, renaming your /admin/ directory to something arbitrary is still a good step to take as *icing on the cake* of a good design.

(Salted) hashes are a good design (as good as we can manage anyway), and taking access control steps to minimize the possibility of hashes leaking to unauthorized individuals is more than just the icing, it's... I don't actually know anything about baking, how do you make a cake? Milk and flour or something right? Anyway your security cake will be edible but taste awful if you don't take common sense steps like putting access controls on the hashes. There's absolutely no reason to slather private data around when basic steps decrease total risk. Enforce reasonably strong passwords in the sign-up process to combine all the steps- good input, good storage, good access control maximizes good outcome.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess......

Actually, he's historically right.

In the old days, the choice to expose hashes in /etc/passwd was defended using Kerckhoffs's principle. The move to /etc/shadow was criticized as unnecessary, as mere "security through obscurity". This all happened before your were born.

These days, of course, the /etc/shadow technique is considered the primary security control, and hashing passwords the additional "obscurity". The spokesman is guilty of simply being old, not stupid .

The spokesman is wrong, but "security through obscurity" has nothing to do with it. Sending hashes in the clear, even using a hard-to-crack algorithm, is a bad idea. Throwing cliches at this issue shouldn't distract us from it.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess......

Actually, he's historically right.

In the old days, the choice to expose hashes in /etc/passwd was defended using Kerckhoffs's principle. The move to /etc/shadow was criticized as unnecessary, as mere "security through obscurity". This all happened before your were born.

Security decisions implemented before I was born are not particularly noted for being superior to those of today. Everything in sec is learned the hard way. Hashing and access control are complementary, peanut butter and chocolate, they're both a good step on their own but they really complete each other for a solid solution. Which is the first step and which is the second step is just incidental.

edit to integrate our twitter pong: I don't think that trying to justify either the choice of words or the choice of design based on what unix beards were doing 20+ years ago is reasonable for a startup in 2013.

66 Reader Comments

if someone is intercepting all emails to the user, what possible solutions are there besides mailing them an authentication dongle and somehow ensuring that it wasn't confiscated by the people reading the user's email?

Require the user to create a passphrase on creation of the account over an SSH connection. Require same user to enter that same passphrase when logging into the confirmation. Download the key as a *zip file encrypted with a passphrase that's displayed as a captcha.

Sure, ANYTHING you do on your computer can be monitored but the more layers you add the longer the surveillance will have to remain in-tact to get the information. Furthermore, Mega could suggest that new users only perform the first login step from a public wifi. Sure, that's easy to sniff but much harder to correlate with later surveillance. And frankly, if you're under that much attention from someone you're screwed beyond what a service like Mega is going to be able to help with.

Or they could send a code via SMS, or have a dongle code via an APP on your phone like some MMO's do.

Last time I had a tough time convicing the "architect" that GUIDs are unique but not random -- they can be sequential which means you can often guess the next GUID in the sequence.

Well except obviously v4 GUIDs and to some degree v3 and v5 GUIDs

Anyhow being able to test up to 600 passwords per second means only extremely weak passwords will be subject to such dictionary attacks. Now the question is whether the used implementation is just especially slow or whether they use bcrypt or similar. Still not especially clever though..

Yah, fair point. One of our components had its own V1 GUID-gen algorirthm rather than calling the appropriate OS API. You just don't ask why sometimes.

EDIT: actually I reckon it was probably calling UuidCreateSequential rather than UuidCreate. Never really thought too hard about the reason until now. Must go check the code... nah.

If I was to use mega for anything else than testing, I'd generate my password like this:

dd if=/dev/random count=1 bs=20 | base64﻿

and keep the password stored safely (pgp would be my choice).

Anyway today was the first day since the launch the service actually worked for me. It seems much of the million users wanting to try to service at once either got bored or got their little testing done...

Weak passwords that are at risk of being cracked through dictionary attacks or brute-forcing are a huge security risk. It makes no difference whether one attempts to mitigate that fact through security by obscurity or not.

I have to say I kind of agree with this statement. It may be poor practice, but depending on the *hashes* of passwords to stay private does seem more like security by obscurity. That said, a method for actually changing your password should have been a given on day 1.

I'm sure there is a good reason, but I always wondered why the salt itself isn't encrypted with a master key. That way even if you get the password file and there are a couple known passwords in it (from previously compromised accounts), it would take a really long time to simultaneously figure out the salt and the cipher.

Here's the thing for me. Mega has never done anything considered a high-security, cryptographically strong private service before. What expertise do they bring to the table that anybody *expected* them to get this right? I fully expected this service to be full of holes on day one. Maybe someday they'll get it right, though, if they are willing to take security analysis from other seriously, and quickly move to correct the problems.

Still, it seems like they seriously need to get someone on staff who is like their "Chief data security officer", who has the expertise and power to make sure nothing ships before it's actually secure.

Edit: I forgot to add: anyone actually concerned about privacy should run FAR away from Mega, as it's clear the people at the top of the company put release dates and hype before security and functionality.

Mega has been thoroughly tested by the industry's best security researchers, and after implementing their suggestions, we can now offer you the most secure file locker on the planet! Not only that but we are WAY under budget on our design staff, due to copious amounts of _donated_ testing time by said industry experts... so now I can pay my legal staff to defend me from the big bad US government.

CTO dude said: UNIX originally had world-readable user password hashes - a design decision that, assuming sufficiently strong passwords, did not jeopardize account security at all. Unfortunately, real users all too often used weak passwords, and the design was changed and obscurity (moving the password hashes to shadow file) added.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess. For example, renaming your /admin/ directory on your website to /banana/ and, if someone happens to browse to /banana/, they can easily figure out how to escalate to admin after that. However if you have all other proper controls in place, renaming your /admin/ directory to something arbitrary is still a good step to take as *icing on the cake* of a good design.

(Salted) hashes are a good design (as good as we can manage anyway), and taking access control steps to minimize the possibility of hashes leaking to unauthorized individuals is more than just the icing, it's... I don't actually know anything about baking, how do you make a cake? Milk and flour or something right? Anyway your security cake will be edible but taste awful if you don't take common sense steps like putting access controls on the hashes. There's absolutely no reason to slather private data around when basic steps decrease total risk. Enforce reasonably strong passwords in the sign-up process to combine all the steps- good input, good storage, good access control maximizes good outcome.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess......

Actually, he's historically right.

In the old days, the choice to expose hashes in /etc/passwd was defended using Kerckhoffs's principle. The move to /etc/shadow was criticized as unnecessary, as mere "security through obscurity". This all happened before your were born.

These days, of course, the /etc/shadow technique is considered the primary security control, and hashing passwords the additional "obscurity". The spokesman is guilty of simply being old, not stupid .

The spokesman is wrong, but "security through obscurity" has nothing to do with it. Sending hashes in the clear, even using a hard-to-crack algorithm, is a bad idea. Throwing cliches at this issue shouldn't distract us from it.

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess......

Actually, he's historically right.

In the old days, the choice to expose hashes in /etc/passwd was defended using Kerckhoffs's principle. The move to /etc/shadow was criticized as unnecessary, as mere "security through obscurity". This all happened before your were born.

Security decisions implemented before I was born are not particularly noted for being superior to those of today. Everything in sec is learned the hard way. Hashing and access control are complementary, peanut butter and chocolate, they're both a good step on their own but they really complete each other for a solid solution. Which is the first step and which is the second step is just incidental.

edit to integrate our twitter pong: I don't think that trying to justify either the choice of words or the choice of design based on what unix beards were doing 20+ years ago is reasonable for a startup in 2013.

why would someone with that much experience make a blunder that seems like such a rookie mistake?

Schedule pressure (anniversary of the raid!), and different programmers or teams coding the various functions? There might not have been as much experience applied to the back-end, new user mailer. (That's speculative, and certainly doesn't exonerate them in any way - it's sloppy no matter how you view it.) It's an old story, though: things like that sometimes take a much lower priority than, and come long after, the core functionality is coded; they're often done in haste and get far less, if any, comprehensive testing or review. Almost afterthoughts. Still pretty sad, though.

All that certainly I suppose, but I think you miss the point.

Mega is not designed to primarily be safe for the users and their data. Mega is designed to be safe for the owners and operators of Mega first and foremost. In spite of their claims to security for the users, that was never the point. The point was to build a file-sharing system where the operators had no control or knowledge of the data that was stored to protect the owners from civil and criminal liability. This, they seem to have accomplished.

Believing they built Mega for you and the security of your data is a bit pie-in-the-sky. It was never the primary goal at all.

Absolutely agree. Now we start to see how the deck is really stacked. Lawyers are there to protect the business, not the user. The hype around this launch did it's job and distracted most of us from doing the diligence. I'm glad to see Ars reporting on both sides of this. Great work!

If I was to use mega for anything else than testing, I'd generate my password like this:

dd if=/dev/random count=1 bs=20 | base64﻿

and keep the password stored safely (pgp would be my choice).

Anyway today was the first day since the launch the service actually worked for me. It seems much of the million users wanting to try to service at once either got bored or got their little testing done...

You might want to look into the randomness of /dev/random on your machine. Not all implementations are very good - in fact, some are lousy.

There is absolutely no excuse for this. We're in an increasingly asymptotic age of technology. Sending this kind of information is absolutely ridiculous. I created a password in 2009 that I memorized, it's over 30 characters long. I used it to encrypt my password database. It uses multiple words and numbers in patterns I memorized set to a poetic beat - so brute forcing it is really the only feasible option.

I no longer believe it's a secure password, I think that if anyone got an older copy of the things I had encrypted with it, they'd be able to break into it.

My point being - even 'stronger' passwords now-a-days aren't going to matter in four years when we're another 2 iterations of Moore's law more powerful in the amount of processing power that can be thrown at an attack. This wouldn't matter if Mega wasn't giving stuff like this out OR if there was a way to change a user's password - but since they are and there isn't, this is a really bad security theater production.

You might want to look into the randomness of /dev/random on your machine. Not all implementations are very good - in fact, some are lousy.

No I might not, I already know in principal how it works. I use modern linuxes, and I've trusted /dev/random for years to give me good enough random numbers for crypto operations. I trust the kernel documentation on this.

Code is right here, though. Reading it won't do at least me much good, you'd have to expert C developer to make enough sense.

My point being - even 'stronger' passwords now-a-days aren't going to matter in four years when we're another 2 iterations of Moore's law more powerful in the amount of processing power that can be thrown at an attack. This wouldn't matter if Mega wasn't giving stuff like this out OR if there was a way to change a user's password - but since they are and there isn't, this is a really bad security theater production.

Yes, they are going to matter.

If a password has on the order of 128 bits entropy, as is recommended for using 128-bit crypto (like AES-128, which mega claims to use) securely, even a thousand or a hundred thousand times more computing power doesn't really matter much.

If a password has on the order of 128 bits entropy, as is recommended for using 128-bit crypto (like AES-128, which mega claims to use) securely, even a thousand or a hundred thousand times more computing power doesn't really matter much.

True, but the idea of humans actually remembering 128bits of entropy passwords for dozens of different services is completely out of the question - most current passwords are probably more in the 30bits range.

The only real solution going forward is using a single strong master password and something like 1password

"Security by obscurity" refers to taking ONLY simple hiding measures that can be defeated with a lucky guess......

Actually, he's historically right.

In the old days, the choice to expose hashes in /etc/passwd was defended using Kerckhoffs's principle. The move to /etc/shadow was criticized as unnecessary, as mere "security through obscurity". This all happened before your were born.

These days, of course, the /etc/shadow technique is considered the primary security control, and hashing passwords the additional "obscurity". The spokesman is guilty of simply being old, not stupid .

The spokesman is wrong, but "security through obscurity" has nothing to do with it. Sending hashes in the clear, even using a hard-to-crack algorithm, is a bad idea. Throwing cliches at this issue shouldn't distract us from it.

Didn't happen before *I* was born, but point taken, nevertheless. :-)

IIRC, the main reason for /etc/shadow is the population of programs that depend on /etc/passwd being world-readable; you can't protect the hashes without storing them separately. I still think the passwd/shadow solution is ugly as hell but, once I learned the whole story, it made a modicum of sense.

Here's the thing for me. Mega has never done anything considered a high-security, cryptographically strong private service before. What expertise do they bring to the table that anybody *expected* them to get this right? I fully expected this service to be full of holes on day one. Maybe someday they'll get it right, though, if they are willing to take security analysis from other seriously, and quickly move to correct the problems.

Here's the thing for me. Mega has never done anything considered a high-security, cryptographically strong private service before. What expertise do they bring to the table that anybody *expected* them to get this right? I fully expected this service to be full of holes on day one. Maybe someday they'll get it right, though, if they are willing to take security analysis from other seriously, and quickly move to correct the problems.

Here's the thing for me. Mega has never done anything considered a high-security, cryptographically strong private service before. What expertise do they bring to the table that anybody *expected* them to get this right? I fully expected this service to be full of holes on day one. Maybe someday they'll get it right, though, if they are willing to take security analysis from other seriously, and quickly move to correct the problems.