Here’s the problem: 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).
Dropbox authentication: insecure by design via Slashdot.
This is a somewhat big deal, especially for anyone using Dropbox file sync on a mobile device that could be easily borrowed for a minute. It will become a very big deal if someone writes a virus that takes advantage of it.
I love Dropbox, I don’t use it on anything mobile other than my laptop which I do keep a close eye on. I encrypt files with anything good on them before I put them in the Dropbox. I think all my machines are pretty well hardened against viruses. And this still makes me unhappy.
