Dropbox authentication: insecure by design

For the past several days I have been focused on understanding the inner workings of several of the popular file synchronization tools with the purpose of finding useful forensics-related artifacts that may be left on a system as a result of using these tools. Given the prevalence of Dropbox, I decided that it would be one of the first synchronization tools that I would analyze, and while working to better understand it I came across some interesting security related findings. The basis for this finding has actually been briefly discussed in a number of forum posts in Dropbox’s official forum (here and here), but it doesn’t quite seem that people understand the significance of the way Dropbox is handling authentication. So, I’m taking a brief break in my forensics-artifacts research, to try to shed some light about what appears to be going on from an authentication standpoint and the significant security implications that the present implementation of Dropbox brings to the table.

To fully understand the security implications, you need to understand how Dropbox works (for those of you that aren’t familiar with what Dropbox is – a brief feature primer can be found on their official website). Dropbox’s primary feature is the ability to sync files across systems and devices that you own, automatically. In order to support this syncing process, a client (the Dropbox client) is installed on a system that you wish to participate in this synchronization. At the end of the installation process the user is prompted to enter their Dropbox credentials (or create a new account) and then the Dropbox folder on your local system syncs up with the Dropbox “cloud.” The client runs constantly looking for new changes locally in your designated Dropbox folder and/or in the cloud and syncs as required; there are versions that support a number of operating systems (Windows, Mac, and Linux) as well as a number of portable devices (iOS, Android, etc). However, given my research is focusing on the use of Dropbox on a Windows system, the information I’ll be providing is Windows specific (but should be applicable on any platform).

Under Windows, Dropbox stores configuration data, file/directory listings, hashes, etc in a number of SQLite database files located in %APPDATA%\Dropbox. We’re going to focus on the primary database relating to the client configuration: config.db. Opening config.db with your favorite SQLite DB tool will show you that there is only one table contained in the database (config) with a number of rows, which the Dropbox client references to get its settings. I’m going to focus on the following rows of interest:

email: this is the account holder’s email address. Surprisingly, this does not appear to be used as part of the authentication process and can be changed to any value (formatted like an email address) without any ill-effects.

dropbox_path: defines where the root of Dropbox’s synchronized folder is on the system that the client is running on.

host_id: assigned to the system after initial authentication is performed, post-install. Does not appear to change over time.

After some testing (modification of data within the config table, etc) it became clear that the Dropbox client uses only the host_id to authenticate. Here’s the problem: the config.db file is completely portable and is *not* tied to the system in any way. This means that if you gain access to a person’s config.db file (or just the host_id), you gain complete access to the person’s Dropbox until such time that the person removes the host from the list of linked devices via the Dropbox web interface. Taking the config.db file, copying it onto another system (you may need to modify the dropbox_path, to a valid path), and then starting the Dropbox client immediately joins that system into the synchronization group without notifying the authorized user, prompting for credentials, or even getting added to the list of linked devices within your Dropbox account (even though the new system has a completely different name) – this appears to be by design. Additionally, the host_id is still valid even after the user changes their Dropbox password (thus a standard remediation step of changing credentials does not resolve this issue).

Of course, if an attacker has access to the config.db file (assuming that it wasn’t sent by the user as part of social engineering attack), the assumption is that the attacker most likely also has access to all of the files stored in your Dropbox, so what’s the big deal? Well, there are a few significant security implications that come to mind:

Relatively simple targeted malware could be designed with the specific purpose of exfiltrating the Dropbox config.db files to “interested” parties who then could use the host_id to retrieve files, infect files, etc.

If the attacker/malware is detected in the system post-compromise, normal remediation steps (malware removal, system re-image, credential rotation, etc) will not prevent continued access to the user’s Dropbox. The user would have to remember to purposefully remove the system from the list of authorized devices on the Dropbox website. This means that access could be maintained without continued access/compromise of a system.

Transmitting the host_id/config.db file is most likely much smaller than exfiltrating all data found within a Dropbox folder and thus most likely not set off any detective alarms. Review/theft/etc of the data contained within the Dropbox could be done at the attackers leisure from an external attacker-owned system.

So, given that Dropbox appears to utilize only the host_id for authentication by design, what can you do to protect yourself and/or your organization?

Don’t use Dropbox and/or allow your users to use Dropbox. This is the obvious remediating step, but is not always practical – I do think that Dropbox can be useful, if you take steps to protect your data…

Protect your data: use strong encryption to protect sensitive data stored in your Dropbox and protect your passphrase (do not store your passphrase in your Dropbox or on the same system/device).

Be diligent about removing old systems from your list of authorized systems within Dropbox. Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox. If you see a system checking in that shouldn’t be, unlink it immediately.

Hopefully, Dropbox will recognize the need for additional security and add in protection mechanisms that will make it less trivial to gain long-term unauthorized access to a user’s Dropbox as well as provide better means to mitigate and detect an exposure. Until such time, I’m hoping that this write-up helps brings to light how the authentication method used by Dropbox may not be as secure as previously assumed and that, as always, it is important to take steps to protect your data from compromise.

Update (10/31/2011): Dropbox has release version 1.2.48 that utilizes an encrypted local database and reportedly puts in place security enhancements to prevent theft of the machine credentials. I have not personally re-tested this release – feel free to comment if you’ve validated that the new protection mechanisms operate as described.

Comments

It’s disheartening to see many of the comments on here follow the lines of:

“You can’t make it perfectly secure so why are you bringing this up”

Since when did highlighting issues with a product and promoting discussion warrant a deluge of this type of thinking?

By this logic why implement a firewall, since they can be defeated (often trivially). Or anti-virus – since new malware is created on a regular basis.

How about instead of saying “This isn’t an issue because:

a) The attacker already has access to ONE of your hosts b) There isn’t a better way to do it c) It’s too hard d) ”

We instead realize what exactly Derek is saying, which is that there are flaws in the product. Whether you see these flaws as configuration related (multiple hosts should not be able to check in with the same config.db) or UI related (all hosts syncing should show up uniquely in the UI for management purposes) – there are solutions to each problem.

The entire solution space of IT security is not limited to IPs and passwords folks – get with the times. And frankly even if it were, I’ll keep my firewall, IPS and AV solutions because defense in depth and more work for the attacker(s) is always a good thing even if its not perfect security.

Does that mean Dropbox is an unusable product and everyone should fear for their lives? Not at all, but sticking your collective heads in the sand and saying “but that’s just the way it is” is myopic at best.

Quote: “You can’t make it perfectly secure so why are you bringing this up” Since when did highlighting issues with a product and promoting discussion warrant a deluge of this type of thinking?

Well, in short because that’s the right way to think about security – least common denominator.

If it would cost me $100 to physically steal your laptop and gain access to all the data on it, then it’s not worth your spending $1000 on firewalls and anti-malware; instead you should spend $50 on _that_ and another $50 on hard-disk encryption software, the latter so that my $100 hardware theft is fruitless.

It’s economics. Thus: if someone is already in your system and in a position to steal your Dropbox credentials, you actually have much larger concerns than Dropbox itself.

However, I participate in projects with 50+ users sharing the same folder over project times of 2 years. Today, one of these computers gets comprimised only stealing a small file. If I understand the issue correct, the forthcoming work could be observed by anyone for the coming two years outside of the project without ever producing traffic or any other hint?

“Dongleing” the dropbox authentification to a computer, I expected, is already done. There are MAC:addresses for routers etc, it could be the ProductID of Windows or whatsoever – anything which is harder to get than a small file.

I can only assume that paying $1k+/user in AV fees is someone’s idea of a straw-man, semi-troll argument. Please omit the hyperbole if you want us to take you seriously.

Using the rationale “they’re already on ONE of your systems, therefore the world has ended” is not an excuse for poor security management in a piece of multi-system software. I use passwords on my SSH keys – why? Because even if an attacker can ultimately break the password, the more time and effort it takes him, the less likely he is to bother and/or be effective. And the more time I have to find/stop him and replace the key before he hits other hosts.

I expect no less from Dropbox.

Instead of endlessly debating about issues that are, at best, tangential (and at worst unrelated or hyperbolic), I’m going to propose three changes that I believe would make Dropbox a more secure product. These changes will cost the user nothing, other than perhaps having to re-key a password from time to time.

1) Add a per-connection unique identifier (maybe have users give their computers “names” in the Dropbox software when first installing? Users love anthromorphism!). Also add “first-added” and “last-seen” fields, and a partial hash identifier field to the management UI. Couple that with a simple button that revokes a given login hash (or all hashes) and you can now trivially detect and lock-out most attackers. Cost to user? $0. Benefit to user? Quite a bit if they are concerned about keeping their account monitored.

2) Have a per-login password prompt. This will at least keep a given hash compromise lifetime to something reasonable. You could even go so far as to have the hashes time-out after a configurable period of time if you wanted. This might be unused by many people, but many others would welcome it. Cost to user $0.

3) Utilize a UID that is non-trivially ported to another host (and not stored on disk). Environmental generation comes to mind – as long as you have the legitimate password, even an environment change is a minor issue – just regenerate the hash if something changes. Cost to user: $0.

I can already see the “but what if you get keylogged!?!??!!”. Yes I know, the world has ended. I have never claimed, nor ever will, that all problems have a technical solution. If someone takes your password outright, then you clean up, create a new account and move on.

However even in that case, having the right tools (better UI management) could help you determine that you have a persistent problem instead of being in the dark.

Dropbox is using a machine independent and persistent magical ticket to access your data. The “attacker access == ticket comprise == screwed” point is a valid point, but so are all the “make the ticket harder to transfer” points.

Arash from Dropbox pretty is silly to compare the id to an HTTP session cookie because those expires. Dropbox magic tickets don’t. Can drop box change the fact they are using a magical ticket? No can they limit the damage down by a stolen ticket and made it easier to detect and stop stolen tickets. Yes. Should they? Absolutely.

Hi Han – I’m sure you can cope with a little hyperbole and humour, and yes it was intentional.

The point was “not spend vastly more on a solution to one problem when a different vulnerability is exploitable much more cheaply”. I think most people took that away from my comment.

You say “I use passwords on my SSH keys” because “more time and effort it takes him, the less likely he is to bother” – I understand that point, and agree; however since we’re talking about a “vulnerability” that requires an attacker to already be inside your defences, it’s fair to assume they can probably propagate out to other machines you own by the same method. Again, that’s a guess, but that’s the point – one has to be inside to exploit this.

The thing is: there is nothing they can do without compromising either usability or cost.

Regards your suggestions:

1) dropbox already does something like that. go check the control panel for “my machines”

2) the idea of dropping creds after a lifetime is attractive, until a) it goes wrong in the middle of a transaction or b) somebody forgets the password / has to put a widely used password recovery mechanism in place, leading to social engineering along the lines of http://goo.gl/phWF0

3) there is no robust UUID that is non-trivially ported across platforms. Ask any software-licensing vendor. You’re getting into the realms of trusted hardware, and that’s both specialist and pricey. This is the one I used to work with: http://goo.gl/M3SYV – see the section on the HSM. Lovely beast.

I’ve been working on problems of this sort for the past 20 years – and honestly, none of it works. How on earth (for instance) are virtualised system instances / Xen / EC2 / VMWare going to have a robust UUID? There are no concrete assumptions that can be made.

Dropbox is prettymuch on the ball with this one. They’ve made a call, and it’s a good call. If what they offer is not suitable for your / anyone’s requirement (“we want to store nuclear launch codes” – probably not a good job for Dropbox[1]) – if it’s not good for you, then don’t use it.

Not to get too far off topic, but regarding HSM’s… as you note they have traditionally been complicated and very expensive. However, Yubico, makers of the Yubikey USB device, have just recently announced a USB-based HSM for about $500 that they call “YubiHSM”. More about it here: http://www.yubico.com/Yubico-introduces-YubiHSM

Leo LaPorte and Steve Gibson discussed this in fairly nice detail in a recent “Security Now!” podcast. You can listen to it at: http://www.twit.tv/sn295

ps: I have one comment in moderation at the moment, but here’s an additional thought.

What if I have a couple hundred EC2 instances which I want to deploy, hands-off, using Dropbox to sync config files?

Were I to require manual setup of each one to bind it to some UUID – a concept which doesn’t really work for virtualisation, but for the sake of argument – then the whole thing would be rendered infeasible.

So: sometimes there is a good argument for being able to cut-and-paste credentials.

Mac OS X provides a keychain system exactly for storing credentials of this sort, but a quick look at my OS X keychain suggests that Dropbox is not making use of this. ~/.dropbox/config.db contains the same kind of hash-id described.

Has anyone actually tested using the host-id on a different system for which the Dropbox password was never given?

And a note to those trying to dismiss the problem because “if they can get at config.db they can already get at everything in your Dropbox folder”. The concern is that one-time, brief, non-root access to the client machine can grant long term read and write access to the person’s Dropbox data.

Yes – I did test moving the config.db file (containing the host_id) from one system to a another system (actually several) and was able to get access to the associated Dropbox without any prompt for credentials (you’ll need to modify dropbox_path to point to a valid, and empty, directory before running the Dropbox client). I only tested this on Windows systems so I’d be interested in hearing if the same process worked on the other OS’s that Dropbox supports (Mac OS, Linux).

“The concern is that one-time, brief, non-root access to the client machine can grant long term read and write access to the person’s Dropbox data.”

I think this point is not made strong enough……

I am new to all the crypto issues, but….

Why couldn’t the dropbox client use the hardware key to encrypt the condig.db. Then when the client does a query to the server for syncing it check the last time it inquired, and compare itself to the previous time it inquired, if they are different then there is an false user, thus raising a flag in the client to reconfirm user credentials.

I would be happy with the following 3 things. Can they be circumvented? Sure. But they go a long way to making a working solution without removing the convenience of DropBox (which I don’t currently use, but have been thinking of doing).

1) When a new device is accessing my files, which has never done so before, even if it is in the config file … prompt me via email to accept the connection. Yes, I know, if they got to my local device’s files they have access to my email … which is why the next item is important.

2) Give me an easy way to audit the list of devices in my config (like Gmail’s ability to tell you all currently logged in session locations).

3) (and DropBox may already do this, don’t know) Give me an audit trail to show me which files have been accessed by which devices. That way if my host IS compromised I can see which files I need to worry about.

I’m perfectly willing to accept risk for convenience. I am confident enough in the security of my home PC that I will probably go ahead and use DropBox for what I was planning (using DropBox to share an encrypted file of my KeePass entries between my home PC and my phone … since even if DropBox was compromised the file would still be encrypted). However, I also know how clueless the vast majority of people are and the changes above would give them a better way of protecting their data.

Heck, even make the items above optional (though they should be enabled by default). Yes, this means DropBox will need some additional infrastructure, but it should be minimal.

I just verified where Drop Box stores its config.db on a Mac and it’s an unbelievable security mess:

The config.db file is in fact stored in that world-readable “.dropbox” folder in the user’s Home folder. So every user on the same Mac, including Guest accounts can make a copy of that file and exploit it as described here.

And in case you are using a Network account that is stored on a server, then EVERY other user on the same server (might be thousands of other students, e.g.) will have completely unlimited read-access to that file!

This demands an immediate fix from DropBox, there will be thousands of users out there where absolutely no hacking or malware tricks are needed to get to all their Drop Box files.

You have to actively change this – Apple ships Mac OS X with this setting.

Regardless an app creating folders in the user’s Home directory has to ensure that the folder is rw for the owner, only. This this the case for all Apple default subfolders except ~/Public and ~/Sites which obviously are world-readable.

People like Dwayne are making way too little of a deal out of this. While operating system capabilities vary, there are a combination of approaches that would help mitigate and even partially eliminate the risk caused by this particular implementation. The current implementation means that even with user level privileges I can copy out the config.db from the user’s folder.

First, at the very least, this attack should require root level privileges where possible. While this is harder to accomplish in an environment where the user is not an administrator, it should at least be an option. The majority of personal users are at least administrators of their own computer. A user readable file is not a secure storage place for a credential that can be reused without a passphrase.

Second, tokens should all be individually expirable (perhaps they are when you revoke a computer’s access?).

Third, concurrent access from multiple IP addresses using the same host id is a dead giveaway that something bad is going on. Without assigning blame, Dropbox should simply immediately revoke access to that host id and force any client(s) using it to reauthenticate. Dropbox should never be in a situation where they are distributing updates to two different computers that are using the same host id.

I’m arguing that the permissions required to read my ‘normal’ files and the permissions required to read my credentials should be different. Nothing more, nothing less. You can spin it any way you want, but to me, having two different levels of access for reading my .doc files and for reading my stored credentials is a smart idea security wise. Globally readable files that can be transported to other systems and yield the same level of access elsewhere are a bad idea.

I hadn’t envisioned the use case you’re describing for EC2 systems, but I don’t think that compromising the security model of every Dropbox user for the needs of a few people provisioning EC2 servers is a good idea either. And if that were a use case to be protected, it could easily be a buried, user configurable option by account. Developers are smart enough to turn these options on when they need them, but the proverbial average user should have the right security set up from the moment they install the software.

> the permissions required to read my ‘normal’ files and the permissions required to read my credentials should be different

You’re a Mac user? Dropbox could store its creds inside the Keychain, which would make things orthogonal with the rest of OSX and make life marginally harder… but it’s true that the keychain access on most systems is left open whilst the user is logged in. One day I should like to find out how exploitable that makes it.

> “compromising the security model of every Dropbox user for the needs of a few people provisioning EC2 servers”

“First, at the very least, this attack should require root level privileges where possible.”

… which would mean that the (proprietary) Dropbox daemon would be running with root privileges. No thanks.

Anyway, my criticism of the original article is that it basically says, “OMG, if you copy the host key, you can impersonate the host!”, which is just a basic fact about any kind of host-based cryptosystem.

Others have raised much more valid criticisms, such as the Unix permissions of the file being world-readable, the lack of automatic re-keying, and the fact that users tend to expect a password change to invalidate all previous authentication.

I’d argue that the credentials shouldn’t be in a file called “config.db” at all, but that they should be in their own file, named something like “secrets.db” or “auth.db” or “hostkeys.db”, that’s only user-readable.

I personally don’t use Dropbox, because I’d rather not use a trusted third party for managing my shared files.

Oh – and another thing: 1password uses Dropbox to sync password and secure note information across systems. If 1password security also had flaws, this could be rather catastrophical for 1password/Dropbox users.

After reading many of the comments, I have a concern and I have some suggestions. – While the ‘key in the homedir’ is the “same as cookies, etc.” may be partially accurate as ‘it’s like everything else’, I think that what concerns me the most is the level of risk is significantly higher than if it was stored using two-factor, required validation by the service (hw based, ip based, username based, … all of the above and score it? ) or some other scheme. While, yes .. someone can do an S/E dialog and get the pw .. or if their l33t, snag it from res-memory, many hackers don’t have that level of expertise. You will NOT protect yourself against the determined attacker, you can easily protect yourself from the casual attacker by making the barrier to entry higher. So by storing it in a very simple place ( and especially one that is routinely exported! by users for mount elsewhere ), IMHO, you’re making the attack un-reasonably easy.

Recommendations: – I would recommend requiring a password at startup. Give the individual of putting it in their keychain or other credential storage at their own peril .. but it doesn’t *hurt* your model, and can help.

– provide the option to use that password both as part of authentication and to decrypt local storage. Yes .. we can all use truecrypt on the contents of the dropbox.. but that gets problematic if you’re doing updates from two different places and get collisions. If the data is encrypted on the server( and it is … right?!) and the client .. you’ve again raised the bar to entry for an attacker that say .. gets a hold of a lappy.. plugs it in and then re-syncs. Further.. moving the sync process above the encryption layre gives you a far stronger product.

I must say, there is a *ton* of fantastic discussion here about what might be done to fix this, but I think the solution is easier than all of that… the root cause is this: the contents of that config.db is legible. I don’t give two diaper-loads about the authentication/keying algorithms. I hate the idea that I’d have to enter a passphrase every time the client starts. Thuck fat. Just hide make it so I can’t read the contents of that file. I suppose that doesn’t explicitly resolve the portability issue, but that’s almost trivial, too. Make the encryption of the file somehow keyed on something unique to the host. OK, I know implementation of this all is a little more than trivial, but the design isn’t all that complicated.

It’s scary to see the decline of quality and security in regards to software lately. I have clients who tell me they are afraid to get online and surf the Internet. I’m about to join them in that boat too

The way most Dropbox users configure their machines is to have their entire Dropbox in a folder on each of their machines. So, anyone with physical access to any of the machines already has access to all the files in the Dropbox. Perhaps I’m missing something, but so what’s the big deal? Physical access is always a problem. I suppose that having the ability to look into my Dropbox risks my future data as well as my current data… Still. You can gain access to my full 8GB of Dropbox’d data if you have physical access of any of my machines, no rooting necessary. The machine doesn’t even need to be online!

I use Dropbox and adore it, and for sensitive work I make an OS X sparsebundle encrypted disk image and store it in my Dropbox folder. I then mount it like any disk image when I need it. Changes are written to it and are thereby backed-up in real-time to its replica in the cloud… and they’re totally useless to anyone lacking the passcode for that file. Oh, I suppose there are some three-letter agencies that can get into the file if they wish, but if they were so interested in me I suspect Dropbox would be least of my worries.

The sparsebundle approach minimizes bandwidth needs as well. It’s a fine solution, and one I’d recommend for any sort of cloud storage.

Meanwhile, the greatest threat to most folks’ data is loss, not unauthorized access. Placing one’s important and current work in one’s Dropbox ensures it is backed up and retrievable in the event of physical failure, loss or theft of the hardware. (And, your work is versioned on the Dropbox web kiosk, an utter lifesaver which addresses another risk to your data: everyday whoopses as you work.)

The reason dropbox is insecure is simple: They save money by not storing your data if they don’t need to! They first check the hash of your file before uploading it. If someone else has already uploaded it, they don’t bother. This saves them time, money on bandwidth and storage, but is insecure – they cannot encrypt your file locally.

Also Dropbox is written in Python, so it is easily decompiled and modified. A quick search on the hacker forums yields a few black and white – hat modified Dropboxes – useful for spying and info-harvesting!

Why couldn’t the dropbox client use the hardware key to encrypt the condig.db. Then when the client does a query to the server for syncing it check the last time it inquired, and compare itself to the previous time it inquired, if they are different then there is an false user, thus raising a flag in the client to reconfirm user credentials.

You just gave me an idea. What if the client generated a random string on each communication with the server, and store it in the DB? On each communication with the server the client would first send the previous (stored) string to the server. If the server has the same one, cool, proceed with transaction. Then immediately generate a new string, store it on the client DB and send it to the server. However, if the strings don’t match, require password.

This won’t prevent attacker from getting that random string at first, but the success of the attack may be short lived or non-existent: the next time the legit user’s client talks to the server, the random strings won’t match and a password will be required for both legit and attacking users.

Some attacks on web sessions can be mitigated using similar technique.

This isn’t a huge improvement on security, but at least it puts a limit on the damage, and it’s very cheap to implement for both DropBox and in terms of annoyance to the user.

I agree with Dwayne’s many comments. Barring some sort of hardware security module holding a private key, I don’t see how Dropbox can do any better here.

Add me to this list. Although things could be obfuscated a bit, and the ability to re-key a device would be a nice option, this isn’t a DropBox issue. The real issue is there aren’t any good options available for device authentication. To compound the problem, security is far too difficult for the average user to comprehend and it’s easy for them to misinterpret obfuscation as real security (ex: my online banking is secure because they make me tell them my cat is named fluffy every time I log in).

I’ve always been convinced that a better option is to give users a physical device and assume that possessing that device is adequate enough to prove identity. At least with something physical, the average user will have the ability to identify when their security has been compromised – they no longer possess their physical device.

That’s light on details, but the USB authenticator becomes the authorized device. The user can carry it around and authenticate from anywhere using any computer they like. The users’ lack of understanding is removed from the system since all they need to know is ‘I need my USB security device to access my stuff’.

Applications can cache a signed token and web services can easily re-authenticate a device at any time by using a new token. It’s a simple API too – please_sign_this_token(token).

Add some processing power (for decryption) to the same device and you’d also have a pretty decent DRM system.

However, the problem for DropBox is authenticating multiple users that are authorized to access the same resources. Either everyone has a smart card or it’s useless. Do you think you could convince your mom, brother, cousin, etc. to drop $10, $20, $X on a smart card? Not likely. Could you convince them to use a private key with a strong passphrase? Lol. Nope.

Maybe CPU manufacturers could build similar functionality into their CPUs. Isn’t Intel already doing something with a OTP scheme? Yep (http://ipt.intel.com/how-it-works.aspx). I’m not a big fan of OTPs though. The reason vendors like OTPs is because they get to be the authentication middle man and, I presume, charge web services a fee to use the system.

The moral of it all is that we need an authentication system that is dead simple and devoid of user interaction.

another thing: is it possible that the dropbox shell extension makes user tracking? i noticed on a XP machine that every time i open a file of any type and association, the shell extension creates a small file in %appdata%/dropbox/shellext/l. sometimes then, i can find some files with appendix _send in this folder. additionaly, the shell extensions holds on every file and app i open an file handle. that looks a bit curious to me. that’s why i disabled the shell extension completely.

[…] password (thus a standard remediation step of changing credentials does not resolve this issue).Dropbox authentication: insecure by design via Slashdot.This is a somewhat big deal, especially for anyone using Dropbox file sync on a mobile […]

[…] Be diligent about removing old systems from your list of authorized systems within Dropbox. Also, monitor the “Last Activity” time listed on the My Computers list within Dropbox. If you see a system checking in that shouldn’t be, unlink it immediately. via dereknewton.com […]