Update: Dropbox has sent us a response to the issues raised in this article; it is reproduced in full at the end of this post.
Popular cloud file syncing service Dropbox, much beloved by TUAW, has been in the news lately. On the one hand, it announced it had hit a new high of 25 million users, which is a number that is both pleasingly big and pleasingly round. On the other hand, it has been the target of some strongly worded criticism for its security features -- or, more accurately, problems with them.
The most recent of these criticisms arose from an update to the Dropbox Terms of Service to state that if the government asks, it will hand over your files:
This isn't terribly surprising, although on first glance it might sound awful. Consider the alternatives. If Dropbox receives a legally binding
subpoena court order (thanks for the correction, JBB) in a criminal case demanding the release of data, what else could anyone expect it to do except hand the data over, right?
Perhaps not. Earlier today, Miguel de Icaza, a prominent Open Source programmer who founded the GNOME and Mono projects, wrote a blog post pointing out a curious inconsistency between this stance and Dropbox's advertising. He linked to this page on the Dropbox FAQ which says, amongst other bold promises, that "all files stored on Dropbox servers are encrypted (AES-256)" and "Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)."
As de Icaza points out, there are no details beyond these high-level statements about exactly how Dropbox carries out its data encryption. AES-256 is a very secure encryption scheme which basically makes it impossible to hack into the encrypted files without the decryption key. Dropbox's FAQ copy makes it sound like its employees don't have access to this key -- as though it's generated from your Dropbox password, perhaps. That's certainly what I took away from the Dropbox FAQ.
However, if that were true, then in the event the authorities came knocking, Dropbox simply wouldn't be able to supply the decrypted files, subpoena or no. It can't get at the contents of those files without the key. So in fact, we can assume that Dropbox does have those keys after all, which means that the only thing stopping Dropbox staff from reading your files is a matter of policy rather than anything to do with the encryption.
And, of course, key files stored on servers can be stolen -- and we know those keys must be accessible to Dropbox's servers, as without them they wouldn't be able to encrypt and decrypt your files. So now we have an additional concern: a hacker with access to the Dropbox servers could access your files if they can also find the matching key -- which must be there, somewhere.
All this comes on the heels of a report last week by security engineer Derek Newton that revealed another insecurity in Dropbox. Newton reports that the machine hash -- a string that uniquely identifies the computer running Dropbox to their servers -- is stored unencrypted and in a standard location on any machine with Dropbox installed. This means that if someone steals that single small file, perhaps by tricking a user into revealing it or through a malware attack, they can copy the machine hash to a computer of their own and download a copy of the entire contents of the Dropbox account in a manner that is almost undetectable to the user.
For most users, this security hole is potentially far more worrying than the first one -- most people with information that is sensitive wouldn't be storing it on Dropbox in the first place. Those who really have to for whatever reason could always doubly encrypt the file, for example by placing an encrypted disk image inside the Dropbox folder. This second problem, however, does represent quite a tempting target for hackers to attack.
All these problems are purely theoretical, for the moment; there are no known cases of a hacker exploiting them. Nevertheless, they do show that if you have data you care about, whether it's the trap layout of your underground lair or your employer's TPS reports, you ought to be careful where you put it. Trust no-one.
Update: Dropbox have asked us to run the following response from their CTO, Arash Ferdowsi:
In our help article we state that Dropbox employees aren't able to access user files. This is not an intentionally misleading statement -- it is enforced by technical access controls on our backend storage infrastructure as well as strict policy prohibitions. The contents of a file will never be accessed by a Dropbox employee without the user's permission. We can see, however, why people may have misinterpreted "Dropbox employees aren't able to access user files" as a statement about how Dropbox uses encryption, so we will change this article to use the clearer "Dropbox employees are prohibited from accessing user files."
Regarding our Terms of Service:
Like all U.S. companies, Dropbox must follow U.S. law. Our Terms of Service have always stated that Dropbox must comply with law enforcement officials, but as the popularity of Dropbox has grown rapidly, we've gotten an increasing number of questions from users about how we do this. The TOS update was merely a clarification for users, not a policy update -- we will fight vigorously for user privacy. It is also worth noting that all companies that store user data (Google, Amazon, etc.) are not above the law and must comply with court orders and have similar statements in their respective terms of service.
On the authentication file issue reported by Derek Newton, we still stand by our initial statement: once a machine is hacked or compromised, security bets are off. At the same time, we've taken the feedback from our users very seriously and recognize that we can do more to protect Dropbox accounts on compromised machines. To be more concrete, last week's update to the Dropbox desktop application already sets more restrictive permissions on the folder that stores the authentication file. We are also working diligently on a solution that will make the authentication file useless on a second computer.