Dropbox Encryption Faces FTC Complaint

On April 20th AgileBits offered the following advice to its users:

The bottom line is that there is no need to panic about Dropbox security

They were talking about the following three issues:

  • Dropbox does not encrypt the file names
  • Dropbox does not protect its automatic login token
  • Contrary to what was stated in the Dropbox security FAQ, Dropbox employees are capable of removing Dropbox’s own encryption on your data. Dropbox have now clarified and corrected the original statement. They take steps to limit what individual employees can decrypt, but the capability to undo Dropbox encryption remains with Dropbox.

Apparently the “don’t panic” message did not work for some.

Christopher Soghoian is listed as a party in a complaint filed with the FTC on May 11th. He accuses Dropbox of a Deceptive Trade Practice. The heart of this complaint is a specific phrase in their terms of service and help pages, which they removed April 12th:

…all files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.

The help page called “How secure is Dropbox?” no longer says that. Instead, it says this:

Dropbox employees are prohibited from viewing the content of files you store in your Dropbox account, and are only permitted to view file metadata (e.g., file names and locations). Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so). But that’s the rare exception, not the rule. We have strict policy and technical access controls that prohibit employee access except in these rare circumstances. In addition, we employ a number of physical and electronic security measures to protect user information from unauthorized access.

Is their clarification reasonable, or have they been deceptive?

I covered the 1914 Federal Trade Commission Act of 1914 and this exact issue on May 11th in my presentation on Cloud Compliance at the Interop conference in Las Vegas.

I referenced the 2004 settlement between Tower Records and the FTC Bureau of Consumer Protection:

The settlement bars Tower from misrepresenting the extent to which it maintains and protects the privacy, confidentiality, or security of personal information collected from or about consumers.

Tower’s trouble with the law came after they had to admit they made a mistake and did not take steps to protect customers in a manner the FTC considered “easy” and “appropriate”.

…the security flaw was easy to prevent and fix, but that Tower failed to implement appropriate checks and controls…

Unlike the Tower Records case, however, Dropbox is stating they have made an intentional decision. They are not changing how the site works…only how they describe the terms of service.

I spoke about the danger with terms of service in April on Episode 11 of Cloud Cover TV, where I explained the concept of cloud encryption in terms of a six-sided box or a bucket. A provider who maintains access (from above) can easily get into a space that prevents other users or peers from getting in (from the sides).

Here’s another example from my presentation at Interop, even more directly related — the Google Site Reliability Engineer (SRE) breach. Bill Coughran was quoted on Gawker after the incident defending his company in much the same way as Dropbox:

We carefully control the number of employees who have access to our systems, and we regularly upgrade our security controls—for example, we are significantly increasing the amount of time we spend auditing our logs to ensure those controls are effective. That said, a limited number of people will always need to access these systems if we are to operate them properly–which is why we take any breach so seriously.

In other words, that’s how they run the service. Their employees may have access to your data at a time that they determine necessary. They could say they will notify you before they access your data, or they will send you an alert every time they access it, but I see no such offer. It’s not a mistake — it’s designed with weak security because that’s just how they do things.

Just to make the point even finer, consider the 2006 FTC settlement terms with CardSystems, which I covered in my presentation at the RSA conference in San Francisco last February.

  • “Simple, low-cost, and readily available” controls not used
  • “Failed to employ sufficient measures to detect unauthorized access to personal information or to conduct security investigations”

Given that my presentations for the past three years have warned users of the exact issue that is now in a complaint to the FTC, you might wonder if I support the complaint.

Oddly enough, as much as I would like to support it, it looks to me like the basis and history of FTC settlements does not fit with this complaint.

I do agree that Dropbox used imprecise language to describe their service. This sentence

…all files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.

would have been much more powerful in meaning if it had been written like this:

…all files stored on Dropbox servers are encrypted (AES-256) and are inaccessible to anyone, including us, without your account password.

However, we can not assume that imprecise is the same as deceptive. This might seem semantic and petty, but when I take a step out of the cloud and think of this in terms of the auto industry, Dropbox doesn’t look so unusual.

A dealer will tell you that your car is locked and inaccessible without your key. Is that deceptive? In other words, here’s the question: Is it a deceptive practice for a dealer to say that you need a key and yet at the same time know that they also have a special key that can open your car? What if they know that a tow-truck driver can use a simple technique to open the door without a key. Are they deceptive if they do not say “your car is inaccessible without your key…unless you call us, or a towtruck”?

Key management is different than the strength of encryption, as Dropbox has since clarified.

Dropbox mentions AES-256 in the same way that a car salesman might say they offer bullet-proof glass on an armoured car. When they warn that it is so strong that you can’t get in without a key, it does not mean you are the only person with the key.

The debate really centres around the clarity of terms used in a service description and a level of transparency, rather than a failure of service or an intent to deceive.

True intent to deceive will be very hard to prove (and seems highly unlikely), so I suspect the complaint will not make a lot of headway in that direction unless they can demonstrate real harm suffered by customers.

The deception argument could even backfire a little and raise the question of liability of a customer. If they expect clarity, what burden do they have to ensure they have the right clarification/answers before they agree to a service? They could ask, for example, “can Dropbox employees access unencrypted customer files”.

From that perspective, the FTC complaint really boils down to one sentence:

Dropbox does not employ industry best practices regarding the use of encryption technology. Specifically, Dropbox’s employees have the ability to access its customers’ unencrypted files.

This is where I find myself drifting most from the complaint.

First, why should a company be forced by law to do their best? What about sufficient or appropriate? I have to say that from an experienced auditor perspective it does not help to throw around “best practice” requirements unless you can back them up as necessary.

Best tends to be relative and hard to define and most often a phrase pushed by vendors rather than regulators. Unfortunately, the complaint to the FTC provides no references to key management for service providers. There are references for many of the other paragraphs so I am left wondering why I should believe they are violating best practices.

Don’t get me wrong. I really, really wish it were an industry best practice to practice a specific key management model that gives consumers absolute privacy for free with an easy-to-use interface. Really. But an FTC complaint will not make it one and there are pretty-good business cases where it’s not actually the best practice.

Note that the CardSystems settlement calls for “simple, low-cost, and readily available” and that the Tower settlement that says the “security flaw was easy to prevent and fix”.

Those are at a much lower bar than a best practice. This complaint would have a far better chance if it was not aiming for a violation of a best practice.

Second, as someone who has publicly and openly pushed simple, low-cost and readily available encryption since 2005 (“Manage Identities and Keys for the Retail Risk Model”, Retail Security Forum), I have to confess that most companies still just don’t get it. They see encryption and key management as complex, expensive and hard to find. This is actually a potential contradiction within the complaint to the FTC. They admit even experts are not certain what Dropbox meant by their terms of service, so a best practice is not as obvious as they assume.

Heartland is a good counter-example. They are spending tens of millions on their encryption fix after a high-profile breach. I’ve spoken with them several times about other “simple, low-cost and readily available” options (especially after one of blog posts caught the attention of their Chief Information Officer), but they obviously are not buying it (pun not intended). Dropbox has a lot of company when it looks at the costs of encryption as an expensive trade-off.

Third, this is exactly why I have been warning my listeners and readers for at least the past three years that if you sign up with a cloud provider you need to manage your own encryption and key management. Do not expect Dropbox to give you privacy within their standard business model. Do not trust a service provider based only on their help page or service agreements. Assume a cloud provider will access your data when it suits their interests. Again, note the Google VP’s explanation to the street after the high-profile privacy breach.

…a limited number of people will always need to access these systems if we are to operate them properly…

It sucks to say that I do not arrive at the same conclusion as the FTC complaint. I would prefer to support it but to be honest I see Dropbox doing what others in the industry continue to do in their service model. It is a low-security model of convenience. Consumers who want higher security have numerous options both on Dropbox or other providers.

It is not unfair. It is not deceptive.

While I personally might want all services to be more transparent and trustworthy, and in that sense I applaud and support the complaint, the complaint’s claims of deceptive practices and demands for best practices are weak.

Ultimately, I do not place Dropbox in the same league of risk as prior FTC settlements (e.g. Tower or CardSystems). Were there simple, low-cost, and readily available controls that Dropbox should have used instead? Did they fail to inform their users or deceive them, as demonstrated by harm? It seems the complaint has a good general idea but fails to show a violation or how the answers to these questions would be yes.

Dropbox has shown a reasonable effort to clarify and explain themselves, including a direct response to the complaint’s author. Their effort seems open and makes me more interested than ever in using their services (still for low-risk data).

Full disclosure: I have clients and colleagues who use Dropbox and I have warned them in the past not to trust provider encryption alone, due to key management concerns as explained above.

When we signed up for Dropbox, we did not create and send the service a crypto key. Likewise, we did not have to move a key between systems that use a Dropbox account. Therefore, encryption clearly was controlled by them, and we were under the impression that Dropbox could read any of our files. No further analysis was necessary and we did not panic.

I also warned them not to trust the service installed by Dropbox on the client.

Despite my warnings they use Dropbox because they primarily see it as “convenient” and “free” — imperfect, yet an improvement over what they had used before.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.