'Insecure by design': the 2011 host_id flaw that let a copied config file hijack any account
April 2011
Researcher Derek Newton showed that Dropbox's desktop client stored an unencrypted authentication token (host_id) in a local config.db file — copy that one value to another machine and you owned the victim's account, with no password and no notification.
What happened
In April 2011 security researcher Derek Newton published 'Dropbox authentication: insecure by design,' revealing that the Windows client kept its login state in a local SQLite file, config.db, in the %APPDATA%\Dropbox directory. Of its fields, only host_id actually governed authentication — and that token was stored in plaintext, was not tied to the machine that generated it, and did not contain the user's password. Anyone who could read that single value could paste it into a fresh Dropbox install on another computer and begin silently syncing the victim's entire account.
Crucially, the stolen token stayed valid until the victim manually unlinked the device from the Dropbox website; changing the password did not invalidate it, and the legitimate user received no alert about the new device. Dropbox argued this was not a flaw because an attacker with local file access had already won, but in October 2011 it shipped client version 1.2.48 that encrypted the local database and added safeguards against credential theft.
Impact
The disclosure became a foundational entry in the long-running case that Dropbox's security model traded safety for convenience, and it directly anticipated the 2015 Man-in-the-Cloud token-theft research. It taught a generation of malware authors that a sync client's local token was a portable skeleton key, and it pushed Dropbox toward encrypted local storage and clearer device-management controls.