Hacker News new | past | comments | ask | show | jobs | submit login

I've read through dropbox's security PDF and I still have a lingering question: What prevents employees/intruders from looking at your dropbox files stored on the server?

As I understand it (and perhaps I'm wrong), your dropbox password is not your encryption key. The fact that I can change my password and then still have instant access to all of my data (ie - it is not batch re-encrypted with new key) all but confirms this, correct? If that's the case, then it implies that, somewhere on their servers, they store an encryption key for each user (or gasp a single encryption key for all users).

If that's the case and someone is able to access those keys (employee, breakin, etc.), then they can decrypt the data for any user.

If this is all true, then this makes the service too risky (for me) for anything that could be considered medium to high security. I'd prefer it if the good folks at dropbox offer me the option to provide my own encryption key that is only known to me and is provided by me each time I want to gain access to the dropbox files.




Personally, I don't trust the folks at Dropbox much more than I trust a random hacker. (No offense, of course. I just don't know them.) It's not even a matter of a security breach. Can you really be sure that one of their interns can't gain access?

So I would never put anything more than mildly sensitive on Dropbox unless I could encrypt it locally at each computer I use before I sent it too them. Yes, I guess it would be somewhat better than the current situation if they encrypted it on their system using a key I sent every times I wanted a file, but I'd still be trusting them to properly destroy the key, etc.


Personally, I don't trust the folks at Dropbox much more than I trust a random hacker. (No offense, of course. I just don't know them.) It's not even a matter of a security breach. Can you really be sure that one of their interns can't gain access?

By that logic, you should also not trust the guy who makes your next carry out. You don't know him after all. For all you know he could be some evil guy who likes to spit in the customers' orders.


If you've ever worked in a kitchen, you'd know that you definitely shouldn't trust that your food isn't spit in. It doesn't happen often, but it happens. Luckily, occasionally eating some spit isn't that big of a deal, and it's something I accept as part of the the convenience of having food prepared for me.

On the other hand, if you had very sensitive financial or business info on Dropbox, then the consequences are much much more akin to having your food poisoned. So then you're question becomes: why aren't I afraid of being poisoned by my take out? And the answer is that (1) nobody stands to gain from me being poisoned while they do stand to gain from stealing my financial info, and (2) the perceived seriousness of poisoning means that many more resources are put into finding and punishing people who poison (per incident) than people who steal financial data, so people are strongly discouraged from the former.


> The fact that I can change my password and then still have instant access to all of my data (ie - it is not batch re-encrypted with new key) all but confirms this, correct?

I don't know what Dropbox does, but it is possible to encrypt all data with a random session key, and then encrypt that session key with a password. Then a change of password simply needs the stored encrypt session key to be replaced. This is what LUKS does, for example.


I think you are right; the encryption key must be stored in their servers so if they are compromised the files would be compromised.

As a general rule you shouldn't trust a third party with the security or encryption of your very sensitive files but encrypt those files yourself before they go into dropbox (or other services).


What encryption mechanism would you recommend for this?

I have some pretty low risk files in my Dropbox but I still encrypted them with a long complex password with 256-bit AES encryption through WinZIP. I've heard GnuPG is better as it allows asymmetric encryption, but this should be good enough.


If the files are just for you there wouldn't be an advantage having asymmetric (public) encryption.


The dropbox business model doesn't really work for encryption. They hash files and avoid storing multiple copies of the same file, this is great for our business - we can 'instantly' upload large files if another user on our system already has an identical copy of that file - but it means that files can't be securely encrypted.

Basically trust Dropbox about as much as you trust email, if it matters encrypt it locally


"...but it means that files can't be securely encrypted"

I'm sorry, but I don't follow.

For all bit-identical copies of a file, the secure hash will be the same. For all copies of that file encrypted with the same symmetric encryption key, the same property holds. Encrypt it with AES-256 using a shared key, and all users can still take advantage of the LAN copies and de-duping that Dropbox supports for unencrypted files.

Now, if you want full asymmetric (RSA, PGP, whatever) encryption of files with per-user keys and fast LAN copies/de-dupling of the plaintext version, you're of course out of luck. That's not a failing of Dropbox, though; the same would be true of any NAS solution, locally-hosted or not.


If two files uploaded by different users used the same key (ie the server stores the key) then you have no security anyway.

If you can detect that two files encrypted with different secure keys are the same then you are similarly screwed.


You can use different keys for each file that you derive from the file itself. So if two user's store the same file they encrypt to the same data, but no one is able to decrypt such data without knowing the file.

On the user's account you would then store a list with keys for each file. Before this list is stored or updated on the server, it is encrypted on the client-side with the user's password, so that the server cannot retrieve this information.

Of course, the security with such a scheme is somewhat lower than with "traditional" encryption, as you can find out who shares a given file. But the advantage of this is that you are still able to block particular files, if, e.g., required to do so by law.


I was really just talking about trusted parties reusing a private key (say, for an encrypted disk image shared amongst team members) not arbitrary strangers on the 'net.

That doesn't require that a server know the key; it only requires that those parties exchange a shared key in advance. It's no different than, i.e., a PSK WPA network password, or a shared encryption key on a workgroup document.

You could still use a service like Dropbox as a reliable offsite backup, while doing all your crypto locally. Think of it as the "availability" service to complement your local policies that insure integrity and confidentiality.


Yes, but that's no different from encrypting a file locally using truecrypt/pgp etc and then uploading that.

The problem is that Dropbox can't offer seamless encryption while still having lazy file sharing.


If you have the technical savvy to set it up, encfs works REALLY well as overlay encryption for Dropbox. Unlike other options such as Truecrypt, it encrypts and obfuscates at the file level, so Dropbox's per-file synchronization and conflict resolution still work.


The information on the encryption is not that in-depth. While I also don't have more information than available on Web-site, from the information available it seems that they server-side encrypt all files with the same key which is (therefore) available to Dropbox. Maybe they just use an encrypted partition or something like this.

If you want a similar system with better encryption look at Wuala or SpiderOak.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: