If you are concerned about the Dropbox design flaw exposed by the dbClone attack, then have we got a link for you!

The intrepid DB devs have tossed up a forum release which purports to fix all the thorny security issues. You can no longer just copy a config file to a separate machine to clone a filesystem and the file itself is now also encrypted. (Forum builds do not automagically download like standard Dropbox updates)

Given the fact that Dropbox did not prompt me for any credentials when I started the new version, I’m still a bit skeptical that it has truly fixed the problem. Given my schedule today, I doubt I’ll have time to poke at it before someone else does, but the thoroughness of this fix does need to be independently validated. The local Dropbox client has to be getting the encryption key/passphrase from *somewhere*, and if it’s not prompting me on start, then it’s stored online or locally and that’s a recipe for another hack.

There is nothing overt in the application bundle (looking on OS X) or quickly discernable from a dump of a few of the app’s .pyc files. Granted, a bit of obfuscation will stop the current hack and dissuade some other sophomoric attempts, but I can almost guarantee that the passphrase (or the algorithm one needs to discern the passphrase) will be found by folks.

The new build replaces your local configuration file with a new, encrypted one (now named config.dbx). I didn’t see signs of either SQLiteEncrypt, SEE, SQLCipher or SQLiteCrypt but haven’t had time to dig more thoroughly. It’s completely possible the Dropbox devs just built an encryption layer over the Dropbox calls themselves (which is not a difficult task).

Please note that forum builds are not necessarily stable and that this is a pretty major architecture change. I had no issues on OS X, but I suspect that any micro-errors in your SQLite config.db may cause some heartache if you do attempt the upgrade. Best to wait for a full production release if you do not have your Dropbox backed up somewhere.