I love it when people froth at the mouth once they finally realize the blazingly obvious!
For today’s example let’s look at the big Dropbox data privacy controversy. There are a few serious problems with Dropbox, such as not requiring a password after a host is added, making it super easy for someone to pretend to be you (if they get your host ID) and access your data. That’s not great, but there are far worse things out there I worry about.
But the big controversy is that… ghasp… Dropbox employees could access your data! But if you know anything about security you know that if you get a nice, pretty web interface; then somewhere, somehow, the odds are an admin at the service provider can access your data. There are techniques around this using creative programming, but one look at the Dropbox code in your browser makes it clear they aren’t using anything like that.
This is because the Dropbox web servers need to see your data to show you the web interface. Ergo, the servers can decrypt your data. Ergo, someone at Dropbox can see it.
Now this doesn’t need to be true – they could have restricted the web UI to metadata and still encrypted file contents, then used a browser plugin (or maybe even JavaScript) to decrypt the files. But both options entail usability and security tradeoffs.
A great example of how to manage issues like these is the CrashPlan backup service. CrashPlan offers a cascade of security options, each with usability tradeoffs, and all available to users. (All these options protect your symmetric encryption key, not the data itself):
- Protect with your account password. CrashPlan can access and see your data if needed.
- Protect with a separate data password stored locally. CrashPlan admins can’t access your data (even to restore it). You need to keep and secure an extra password.
- Set your own encryption key. Can be on a per-machine basis. Very secure, requiring more management.
There is, of course, much more to their encryption scheme – this is just the user-controllable portion.
Dropbox could do something similar:
- Standard (perhaps the only option on their free plan): Basic account username/password as they have now.
- Enhanced Security: Set a personal password, with metadata in the clear. You can manipulate your files, but they can only be downloaded by the local agent (not via a browser) and you need to remember the password (no password restore capability). You can still share public files, which are stored in a separate directory using your account password as on the old system.
- High Security: Metadata and file data encrypted using your personal passphrase, separate from your account passphrase. Web UI can only manage public files – everything else is accessible only through their client.
These would require serious development effort, and I don’t want to gloss over the complexity or importance of implementing this type of security correctly and safely. This stuff is hard. But it would be manageable if they made it a priority.
But seriously, people – if you want something free/cheap with a pretty web interface to manage your data, odds are you are trading off security. I use Dropbox extensively and just encrypt the things I consider too private to expose.
Reader interactions
3 Replies to “Data Security: Dropbox Should Mimic CrashPlan”
I have been using a service named SpiderOak ( https://spideroak.com/ ) and have been wholly satisfied with their responses to how they do encryption. They use key-generation based on your password, and all encryption and decryption is done on the client side. It also provides a way to copy the encrypted blocks to a secondary server in case there is a problem with their servers ( *cough* Amazon EC2 *cough* ) you can still recover your data.
They have explicitly said in calls with them that they are totally incapable of reading your data, as the servers function as encrypted block storage devices only, and also can’t recover your password, so you better escrow it somewhere!
Wow thanks for the enlightment there. What is McKay’s nickname; captain privacy? Given the content of some of your last several posts, how about Rich being Captain Obvious?
Unfortunately the majority of users will take the couse of least resistance or effort. The CrashPlan example you cite is very good and I would hope that the majority of security/privacy savvy users will at least pick the second option if not accept the key management issues and generate separate keys for each machine.
The problem is that the vast majority are not that savvy. I once had a conversation with a C-level exec in a Fortune 500 company who was amazed by my assertion that someone other than the recipient could read his emails, I remember his words “but surely it is secure?” This was not a stupid guy he just made the mistake of assuming that the world was a better place than it actually is. That every developer when they first sits down to hack up a prototype for the latest think first thinks “how am i going to do this securely”. Those who build better products but risk the lack of uptake that those like DropBox have seen.