So apparently Dropbox might have a security problem. Someone who has access to your machine can apparently grab a config file that confers access to your Dropbox data, and that access can continue from other machines despite password changes. That last bit is important, and seems to be what many commentators on “Spews for Herds” web sites are missing. If a machine M is already connected to a resource R, then R will be available to anyone with access to M as long as that access lasts, unless periodic re-authentication (or re-connection) is required. Such re-authentication can burdensome enough that many people are willing to let it be infrequent or forego it altogether, so I’m not going to fault Dropbox for that. On the other hand, if an attacker might retain access to your Dropbox account even after you get them off your machine and change your password, that’s a whole different kettle of fish. The reports I’ve seen are a bit unclear, but here are several possible interpretations.
- Your Dropbox password is not used in any way that actually confers protection, and is essentially useless. This would be fraud on Dropbox’s part.
- Your Dropbox password is only used when fetching a hostid and there’s no check for duplicate connections from the same hostid. Therefore, once you have the hostid – however you acquired it – your access can no longer be interrupted. This would be incredibly sloppy on Dropbox’s part.
- Your Dropbox password is only used when you first connect, so existing connections are unaffected. In other words, you’d better change the password before your unwelcome visitor establishes a connection from somewhere else. This is almost as sloppy as the previous possibility, but not quite.
- Your Dropbox password is in fact used for periodic re-authentication, and/or periodic checks are made for duplicate hostids, but Derek Newton didn’t wait long enough to see that before rushing out to sound the alarm. This would be kind of sad, but I think it fits into the realm of understandable error.
- Dropbox is in fact reasonably secure and there’s some other reason why Derek Newton’s analysis is flawed.
- Derek Newton knew there was no problem, but made a fake report anyway. This would be fraud on Derek’s part, but I’m including this only for completeness. I don’t know Derek from a random coffee bean on the floor at Starbucks, and have no reason to believe he’d be even remotely capable of such a thing.
We don’t know yet which of these scenarios will actually turn out to represent the truth. The real point, though, is that the differences mostly have to do with how Dropbox is using those passwords, keys, hostids, or whatever other security-related artifacts are involved. None of us know that, and that’s the real problem. You see, I’ve had to think through a lot of the exact same issues for CloudFS. One conclusion I reached very early is that you shouldn’t need to know or care whether your cloud-storage provider is competent, diligent, or trustworthy enough to be keeping your data safe. All of the keys and similar resources needed to access your data should be under your control, so that you can prevent access to your data by forbidding access to the keys at your end. Even if Dropbox is actually secure, users around the world might well wonder whether that has always been true or will continue to be true. They shouldn’t have to wonder. An architecture that would allow them to have peace of mind even when reports like this come out is harder to implement – and a lot harder to implement without significant sacrifices in performance – but it’s necessary.
UPDATE 2011-Apr-19: Miguel de Icaza points out another problem with Dropbox security. As I said on Twitter back when this was originally posted, if a storage provider has your keys then they don’t have deniability, and that’s bad for both of you.