Dropbox security issues

I use Dropbox heavily for storing many files I’d like immediate and synchronous access to across various systems. I enjoy knowing that if I place a file on my Dropbox folder at home, it’ll be available on my laptop later, on my work machine, or on other machines I use remotely. It’s very convenient.

Dropbox is essentially offering a “public cloud” to its users to hold their files. This also means that our files are stored on servers that we do not entirely control. Because of this, I make a habit of encrypting all the data in my Dropbox folder (call me old school, but there it is…)

This does make things a bit difficult, as the files are not immediately available to me insofar as I have to decrypt them first (using eCryptFS). While that’s essentially a simple process, it is an extra step. It does however give me a measure of relief knowing that if there should be any problems with the public cloud and my files were to fall into the hands of a third party, at least they’d then have to decrypt them first.

It turns out that Derek Newton has found some security issues with Dropbox. Every Dropbox installation under windows places a config.db file under %APPDATA%\Dropbox (in Linux the file would be under ~/.dropbox/ and is called dropbox.db and host.db).

All an attacker would have to do is first gain access to a system running dropbox and copy the config.db file (or the dropbox.db and host.db file under Linux) and place them on his own system, in his own vanilla Dropbox (fresh) installation. As Derek puts it:

. . . the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface.  Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design.  Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).

I understand that Dropbox is trying to keep their system as easy to use as possible and allow systems to easily sync files, but this requires a second look and perhaps a bit of re-engineering.

Check out Derek’s full post here. He agrees that the only remedy at this time is to encrypt the files in your Dropbox folders. I also recommend you read the discussion occurring after his post, as there’s a vibrant discussion on the topic and Derek responds to some of the more cogent remarks. In this matter, I agree with Derek entirely that Dropbox (while very convenient) is vulnerable to some trivial attack vectors.

Dropbox may decide that for convenience, this design merits keeping without correction. If they should decide that, I’m OK with that since I encrypt my data anyway. This does stand as a warning though to those that don’t, that your files could be at risk and you should either avoid putting any sensitive data in Dropbox folders, or employ encryption.

This will of course make mobile Dropbox clients useless, since I’m aware of few encryption programs available for Android (or iThings) that are also available to the desktop. I know eCryptFS isn’t available for mobile devices, which means that viewing files on my cell phone has been and remains impractical.

Cloud storage is nice and can be convenient, but it is critical to protect your data. If you’re interested in eCryptFS (which I prefer over other encryption applications such as Truecrypt), check out my older blog post here for a full explanation of it and how to implement it on Debian-based systems (such as Ubuntu, Linux Mint, etc.)

In addition to all this, other bloggers are talking about Dropbox’s use of deduplication to backup its data. What this means is, if two different users with their own Dropbox accounts store the exact same file to their respective folders, Dropbox will only backup one copy of that file and simply attribute the bits to both users.

While this saves Dropbox a ton of storage requirements for backups as well as bandwidth and money, it does so at your expense. It also means that they’re not really encrypting your data. As Christopher Soghoian mentions in his post,

The service tells users that it “uses the same secure methods as banks and the military to send and store your data” and that “[a]ll files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.” However, the company does in fact have access to the unencrypted data (if it didn’t, it wouldn’t be able to detect duplicate data across different accounts).

This bandwidth and disk storage design tweak creates an easily observable side channel through which a single bit of data (whether any particular file is already stored by one or more users) can be observed.

If you value your privacy or are worried about what might happen if Dropbox were compelled by a court order to disclose which of its users have stored a particular file, you should encrypt your data yourself with a tool like truecrypt or switch to one of several cloud based backup services that encrypt data with a key only known to the user.

[Of course I recommend eCryptFS over Truecrypt, as I’ve stated before. I have not tried SpiderOak.com (referred above in the quote) — it may be a viable alternative to Dropbox, but I’d still encrypt my data.]

An interesting tidbit I’ve intuited here, is that Dropbox must be using deduplication on the fly in its client. For depulication to happen on the fly ahead of any file upload to the Dropbox network the client must indeed send key bits (also known as a hash) back to the Dropbox network for deduplication analysis.

Tests show (according to Christopher Soghoian’s post) that indeed dropping an identical file at a later time generates a slim fraction of network traffic back to Dropbox (from your computer) than a file that the Dropbox network has never seen before. This means that Dropbox is looking at all its data in aggregate across all users for duplicated bits, so that only the unique bits are backed up. If all users’ data were truly encrypted, this could not happen as encryption scrambles bits and would deny Dropbox the efficiency of bit level comparisons.

This means that users’ data are ultimately not really kept separate, and any encryption Dropbox may claim they apply is rendered useless since they’re blending user data on the back end to better manage and streamline their available resources (at the users’ expense).

Ultimately, what this really means is that you should have no expectation of privacy for any data you place on Dropbox’s network, unless you go out of your way to encrypt it prior to ever placing the data into the Dropbox folder. Encrypting your data prior to dropping into a Dropbox folder will truly render the data unique, forcing a full upload of the entire file as well as depriving Dropbox of any benefit of deduplication.

What this means for Dropbox is increased costs for servers and bandwidth to backup encrypted data since it cannot be deduplicated. While I understand Dropbox’s need to maximize profits and keep costs down, it shouldn’t be at the users’ expense.

Ultimately, no faith can be put in a public cloud to protect one’s own data. They’re great solutions for offsite storage as well as convenience, so long as proper precautions are taken. Encryption ahead of time is the best way to enjoy the fruits of this great technology.