Live data from Hacker News

Dropbox Lack of Security

tirania.org

21–30 of 193 posts

Re: Dropbox Lack of Security

#21
post #16
post #3

Earlier quoted context omitted.

hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. I'm not sure why you're concluding that de-duplication implies lack of encryption. the de-duplication occurs prior to encryption. all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud. re. employee access to f…

Dedupe and cleartext metadata as stated in the article I referenced, would allow for the following possibilities: If an attacker could figure out the hash method used by dropbox on the files and intercept a few hashes from a victim, it's plausible that an attacker could trick the service into thinking that he had uploaded the files on his own account, allowing access to the victim's files. Could you explain what woul…

cryptographic signatures of files are never transmitted over plaintext. yes, the current incarnation of the mobile apps don't encrypt the names of the files but we are working on a fix for this as soon as we can adequately improve the SSL performance of our mobile apps.

Re: Dropbox Lack of Security

#23
Regardless of how you want to parse a company's public statements and written policies, it's the height of naivete to think that a data host (ANY host) wouldn't share your data with law enforcement or has encrypted data in such a way that they guarantee that no one can access it.

If you have sensitive data, encrypt it yourself. Encrypt it on your local drive, back up encrypted data, encrypt it before uploading it to Dropbox. Doing otherwise is akin to not having a proper backup process: it's either because of laziness or ignorance.

Re: Dropbox Lack of Security

#24
post #8

hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud. re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage serve…

What's the ETA for detailed security architecture whitepaper?

"(A)ll data is encrypted before it's stored on the backend" statement is completely worthless unless (at the very least) you also describe how the keys are generated and managed.

Re: Dropbox Lack of Security

#25
post #5

It is possible to design a Dropbox-like system with the following properties: 1. Files are stored encrypted. 2. The service provider does not have the ability to arbitrarily decrypt the files. By "arbitrarily decrypt" I mean decrypt at any time they wish. They will be able to decrypt if the owner's client is actively connected. 3. When someone uploads a file that is identical to an existing file, it initially is stor…

Scratch that. I've got an even better design than what I was thinking of above. It makes it so the service provider never has access to the unencrypted data, and they can fully de-dup immediately, and it supports all Dropbox features.

   Let F be an arbitrary file.
   Let N(F) be the name your client knows the file by.
   Let H(F) be a hash of the file that produces a 256 bit hash.
   Let AES(X,K) be X encrypted using AES with key K.
When you upload to the cloud, you upload AES(F,H(F)). In a local database, you store (N(F), H(F)). When you later retrieve the file from the cloud, you receive the encrypted data, and you can lookup the key, H(F), in your local database.

Note that if two different upload files with the same content, they pick the same encryption key (since the key comes from a hash of the content), and so the same data gets uploaded. The service can thus do de-duplication, even though it has no access to unencrypted data.

So far, all this provides is secure storage. What makes Dropbox useful is that a file uploaded on one computer can be downloaded on another, and that only works if the downloader knows H(F).

This is solved by also uploading a copy of that local database I mentioned, the one that stores the (N(F), H(F)) pairs. This can be encrypted with the account password.

Syncing between different devices on the same account is then a two step process. First, the name/key database is synced, and then both devices have access to the keys and then the files can be synced.

I believe web access can be handled via this system. Dropbox's web interface requires Javascript, so it could have the browser retrieve the name/key database and decrypt it using the account password, which gives it the access to the key to decrypt a given file.

For shared folders, you can use a public key system, where the keys for the shared files are encrypted with the public keys of each person you are sharing the folder with, and the encrypted key files are stored in the cloud. Anyone accessing the shared folder grabs the key file for the folder and uses their private key (which is protected by the account password) to get K(F) for the file.

I believe this covers everything Dropbox does, with the properties that:

1. They can't decrypt your files.

2. They can de-duplicate completely.

3. Your account password is the key for everything for you.

4. It satisfies all of their advertising claims for security.

Re: Dropbox Lack of Security

#26
post #5

It is possible to design a Dropbox-like system with the following properties: 1. Files are stored encrypted. 2. The service provider does not have the ability to arbitrarily decrypt the files. By "arbitrarily decrypt" I mean decrypt at any time they wish. They will be able to decrypt if the owner's client is actively connected. 3. When someone uploads a file that is identical to an existing file, it initially is stor…

Tahoe-LAFS seems to fit the bill, except I don't know about #3. From what I understand it's rather stronger on #2, though.

Re: Dropbox Lack of Security

#28
post #11

Earlier quoted context omitted.

tarsnap

I'm guessing tarsnap doesn't satisfy the 3rd criteria, nor is tarsnap able to decrypt the user's files, even when the client is connected. Perhaps cperciva can comment.

3rd criteria can be considered a vulnerability, it may allow to know that certain user has a known file. It can be exploited to reveal information about the encrypted files.

Re: Dropbox Lack of Security

#29
post #8

hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud. re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage serve…

[deleted]

Re: Dropbox Lack of Security

#30
post #8

hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud. re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage serve…

Technically speaking, whats the point of encrypting data on the backend if you can decrypt it? This strikes me as a waste of computations for no real gain.
Post reply on HN