- Make a big fuss about how Christians are wrong and are wasting their life worshiping God.
- Themselves waste their life on the Internet complaining about step 1.
I'm a socially conservative pro-life and pro-family computer science major. That sums up what to expect here!
Note: Please make sure to read the response to my email from Dropbox at the bottom. Everything in this post was using Dropbox Android client version 1.2.4, which was published to the market on the 18th of August, 2011. Any desktop comparisons were using v1.1.40.
A couple of weeks ago I was playing around with my Dropbox account on my phone. I was trying to work out how secure my data is on my phone, and what would happen if it were stolen. When looking in the Dropbox app preferences, I noticed a feature that said “passcode,” which allows you to place a passcode on your Dropbox. So that in essence, you can’t access the Dropbox account from the phone without that passcode.
If my phone was lost or stolen, at the moment I would presume that everything on my SD card has been compromised. That said, I don’t have much on my SD card other than Music, Photos and a select few files downloaded from Dropbox. The files that I have on my phone from Dropbox aren’t particularly important files, or at least ones that I can live with being compromised (such as my KeePass database, as it’s encrypted.) What I’m more concerned about is people being able to download more important files from my Dropbox account when they have my phone. This is where I thought the passcode would come in handy.
There’s a problem with the passcode though. Most people using the passcode on Dropbox probably don’t have a passcode for their phone (and why should they? They can already access my SD card, it’s more or less my Dropbox account that I’m concerned about.) This means that any one who has access to the phone could access all features, except Dropbox.
The problem occurs when, because all features are available to a thief, the thief can place the phone into Dev mode, hook it up to their computer, and extract the settings database, and view it in a SQLite viewer. As a proof of concept, I set my passcode to “1234.” See the screenshot below…
Yep, that’s right. Passcode is stored in plain text. The thing to note is, if there is no lock on the phone, this information is easily accessible with just the Android SDK and a USB cable. As mentioned before, people likely to be using the Dropbox passcode lock are those who haven’t locked their phone with a passcode or pattern, since if you have, there is no need for the Dropbox passcode.
I believe this will give people a false sense of security. I was hoping, with the passcode, and I lost my phone, I’d be able to think to myself “all my data on my SD card has been compromised, but that’s OK, because they can’t download any more files from my Dropbox.”
There are also concerns with the way that Dropbox handles the authentication of devices, as described in an article entitled Security researcher warns over Dropbox authentication security flaw. I myself have been able to test this, and confirm independantly that, if given access to a computer for a short period of time, it’s possible to lift the preferences database and duplicate those preferences onto another computer, completely undetectable (it won’t show up as another device.) The CTO say’s this isn’t an issue because if the system has already been compromised, then the attacker may as well grab all the data they want whilst they’re in there.
I see 2 problems with the statements the CTO made:
Response to Responsible Disclosure Email
I received an email from them on the 15th saying that this issue I have bought up will be forwarded to their mobile development team. Dropbox also “recommends that users follow good security practices to protect your computers and devices, which does include pass coding your phone.” They did not indicate they wished me to refrain or delay from posting this, which I said I would on the 20th of November unless asked to delay (which I clearly said in my original email to give them time to fix the issue.)
They also informed me that the issue I linked to regarding their Windows desktop client has been fixed in version 1.2.48 (which I was not using in my tests.)