Attackers able to get their hands on a Dropbox configuration file would be able to access and download any files a user synchronises through the service without betraying any signs of compromise, a security researcher has discovered. Derek Newton discovered that a Dropbox authentication token, stored in a config file of the …
An OAuth problem?
OAuth provides long-lived access tokens once the client is authenticated. I could never figure out how to store these securely.
Another reason to destroy old hard drives?
If you bin a PC and someone gets this file off the old hard drive, they'll have permanenet access to your dropbox account without you knowing, right?
I dub thee "Sir Post"
It's worth noting that exactly the same difficulty exists if, say, you authenticate SSH by certificate and someone had away with that file.
The token can be invalidated by unlinking/relinking the machine who's credentials were compromised.
Dropbox ought to highlight that this issue exists. However, if someone has access to your file system and is able to poach a certificate file, you've probably got bigger problems than them rummaging through your dropbox (assuming you're not daft enough to link on a machine you don't trust)
So, what happens once Dropbox has been uninstalled from a PC? Does this config file and authentication token get deleted? OR is it just left in the user's %appdata% folder ready for a reinstall?
Using Dropbox for sensitive files...
Don't get me wrong, Dropbox is a massively useful application that saves me bucket loads of time syncing stuff around the place but this sort of thing is why the only sensitive files I have on there are otherwise encrypted in their own right.
It all boils down to the standard rule of not storing anything 'in the cloud' (god I hate that term) that you wouldn't want your mother to see without taking your own measures to ensure sufficient security. It's just common sense.
snow job(s) coming
Storing stuff in the cloud. Somehow I smell a snow job coming, lots of 'em in fact.
Who owns your data when the cloud goes away?
Dropbox & Roaming Profiles = insecure
I was looking at Dropbox a couple of days ago after noticing that Dropbox installs itself in the user's Roaming Profile directory under Windows 7 (same for XP). Dropbox adds about 25MB to a user's roaming profile, which is undesirable and slows down user logon/logoff.
User roaming profiles *should* be well secured on the corporate fileserver(s), but Domain Admins & Support Desk staff often have Read access for troubleshooting purposes (e.g. roaming profile bloat). See where I'm going with this... Anyone with access to the user's roaming profile will be able to access a user's Dropbox config.db file.
Roaming profile bloat? Check.
This doesn't bother me in the slightest - see title.
Also, I was impressed that Dropbox is intelligent enough to synchronise at block-level, so even within an encrypted file, only the changed parts are copied.
DropBox have a valid point on the "if you're comprimised enough to give someone our file"
you're pretty much already so screwed...
That being said, it really is mind boggling that they don't send a notice when a new device is connected to the service. There are advantages to infecting the system, grabbing a small bit of data, and downloading the bulk from the DropBox servers. Although the DropBox servers are probably better configured for most aspects of monitoring, since the wholesale transfer of data to another system is their purpose, they aren't likely to notice the extra load. Not that I'd really expect the servers elsewhere to notice it in time either.
Also, defense isn't just about the perimeter anymore. It's about layers and depth. Securing that token is part of that layering. Two factor is better than one. My current preference is a cert plus a password. Password doesn't need to be complicated as long as there's also a lock-out provision.
"...freemium based service"
Please God, tell me that's a typo!
But it says in Truecrypt's documentation that if an attacker has two or more copies of an encrypted file, each of which is slightly different from the other (because files inside it have been added, deleted, modifed) then it makes it easier to crack the encryption.
So if you upload your TC container to Dropbox, and they make a backup copy, and you then upload another copy of your TC container that's slightly different, they have two copies of your container and this vulnerability exists and gets worse each time you upload another copy.
The only way round this that I can see is to create a new TC container and copy your files to it, before uploading it to Dropbox (or any other online storage) each time, which means you can't just upload the modified blocks but have to upload the entire container.