Latest Black Eye For Dropbox Shines Spotlight On Larger Problem

Handing off your unencrypted data to a cloud storage service doesn't suddenly make it the service's problem if the data is compromised or lost. Responsibility runs in both directions

With Dropbox's admission this week that usernames and passwords, stolen from other websites, were used to sign in to a "small number" of Dropbox accounts, it's becoming clear the cloud storage company is becoming the poster child for the anti-cloud crowd who maintain the convenience of cloud storage is offset by its perceived lack of security.

This news follows the company's mid-July admission of fault when users noticed they were getting spam directed to email accounts they only use to access Dropbox.

In fact, in a blog post announcing the breach, Aditya Agarwalm, the company’s VP of Engineering, included the following admission: "A stolen password was also used to access an employee Dropbox account containing a project document with user email addresses. We believe this improper access is what led to the spam. We're sorry about this, and have put additional controls in place to help make sure it doesn't happen again."

And yes, we've all been down this path before. As you may recall, a year ago Dropbox disclosed that all of its users' files were publicly accessible for nearly four hours due to a bug in the company's authentication mechanism. And, adding insult to injury, according to this article in Venture Beat in April, a security hole was discovered in Dropbox's iOS app, which allowed anyone with physical access to a user's phone could copy that user's login credentials -- because it stored user login information in unencrypted text files.

So that's that. Dropbox is to blame. Someone has supplied the obligatory maxima mea culpa and we have yet another instance that proves cloud storage, while easy to use, just can’t be made secure.

Well, lessons learned and time to move on to the next data breach, right? Not exactly.

Among the security cognoscenti, it's a given that you should always vary your password from site to site and the effect of repeating it across multiple sites opens it to compromise.

Even Microsoft agrees.

Writing in a blog post following July’s Yahoo breach that exposed 400,000 user details, Microsoft Account Group Manager Eric Doerr related the fact that people reuse passwords and login details across service from different providers.
According to Doerr, around 20% of the logins found on lists of compromised credentials match those of Microsoft accounts due to consumers using the same login details across more than one service. Note: the lists Doerr alludes to are circulated by organizations and hackers in the wake of attacks on third-party service providers.

"These attacks shine a spotlight on the core issue -- people reuse passwords between different websites," said Doer, "That reuse means that if one set of logins is compromised, other accounts are at risk."

Even Dropbox's Agarwalm acknowledges that the responsibility for data protection goes both ways, "At the same time, we strongly recommend you improve your online safety by setting a unique password for each website you use. Though it's easy to reuse the same password on different websites, this means if any one site is compromised, all your accounts are at risk."

And although it might seem onerous to use unique passwords for multiple sites, there is decided upside.

As Graham Cluley, senior technology consultant at Sophos recently commented, "The Dropbox incident underlines the necessity of having different passwords for every website. As people pile more confidential information onto the web, hackers are being given a greater incentive to penetrate accounts. The frequency and severity of these data breaches is proving time and time again that users must make better efforts to protect themselves. If you are going to entrust sensitive data to Dropbox, my advice is that you should automatically encrypt it before sharing it with the service. That way anyone who raids your account won't be able to make sense of what you have stashed in the cloud anyway. Businesses are waking up to the need to use automatic and invisible encryption alongside their cloud storage -- protecting users who make use of services such as Dropbox."

Now don't get me wrong. I'm not willing to place blame exclusively in either camp for this latest Dropbox debacle. There's shared responsibility at work here: users who appreciate the risk they take when they store unencrypted data in the cloud and cloud services that have not yet implemented (as Dropbox promises) at least two-factor authentication to mitigate risk to their customer base. Without such accountabilities, this certainly won't be the last time we hear about customer data breached in B2C cloud storage services.

I agree 100% with AnonymousMan. Security professionals should stop beating the "do not reuse passwords" drum. In my mind it is perfectly ok to reuse passwords for unimportant websites such as forums, webshops, etc. Do you really expect average users to use unique passwords for the dozens of websites they have accounts on? It is just not feasible. Who cares that compromising my forum account on site X gives an attacker access to my webshop account on site Y? (Webshops in my country do not use or store credit card details.)

Instead, tell users to not to reuse passwords on important systems such as E-mail, E-banking, online file storage, home computer, etc.

I keep hearing this same advice about having a different password for each website.-á That, at least by itself, cannot be the solution. You have to create a new set of credentials every time you sneeze on the Internet these days.-á Most humans just can't and won't create unique credentials each time.-á If it makes you feel better, keep suggesting that, but I would focus on other ways to solve the problem (e.g. I think we need MUCH better password management systems).

Published: 2015-03-31The build_index_from_tree function in index.py in Dulwich before 0.9.9 allows remote attackers to execute arbitrary code via a commit with a directory path starting with .git/, which is not properly handled when checking out a working tree.