An OAuth problem?
OAuth provides long-lived access tokens once the client is authenticated. I could never figure out how to store these securely.
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 …
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)
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.
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.
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.
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.
Biting the hand that feeds IT © 1998–2021