Live data from Hacker News

Dropbox Lack of Security

tirania.org

101–110 of 193 posts

Re: Dropbox Lack of Security

#101
post #82

Earlier quoted context omitted.

Everything on your website that in any way addresses "Dropbox's security" should make absolutely clear the extent to which users can expect their data to be "secure". In Dropbox's case, users can expect the following: - Data is probably secure from sniffers That's it. It matters little whether "Drew has physical access to our storage servers anymore". Your code obviously has easy access to the keys used to encrypt an…

you're right in that all these things are theoretically possible in a system where the encryption key is not stored client-side. I don't know of many services that advertise every way in which their systems could be compromised. I think you'd be hard pressed to find a company doing this. in the case of google - is there a document explaining all the places your email could end up? we believe that what we advertise is…

But you are not Google, and I expect you to have higher standards. Don't take Google as the reference data point, it's a fairly low one as far as reference data points go.

On a related note, Dropbox is not the only company that advertises security even though what really is offered is kind-of-security. See Backblaze, for example — yes, the data is (supposedly) encrypted using my private key, which (supposedly) only stays on my machine, but I can't be sure because it isn't auditable, and to do a restore I have to supply my private key to the Backblaze website, instead of using a local decryption tool. Not good.

Re: Dropbox Lack of Security

#102
post #57

Earlier quoted context omitted.

and is the hashing done by the client, or server-side? because client-side would make spoofing even easier.

Client side. If you upload a very popular 500+mb file, maybe try a popular linux distribution iso, it will sync instantly.

so has someone written a client where you just enter hashes of popular files you are interested in and get them snyced to your dropbox?

Re: Dropbox Lack of Security

#104
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…

Wait, Truecrypt? Haven't I seen warnings in the Truecrypt docs against keeping several copies of the same file? And doesn't Dropbox backup every little change? You might want to add a note on your security page that storing encrypted files on a service with automated backups, like Dropbox, may pose security risks.

How does the second part follow from the first? What is the 'security risk'?

Re: Dropbox Lack of Security

#105
post #78

Earlier quoted context omitted.

I might have misunderstood what you meant, but #1 is invalid. If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream. Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key. Your killer argument is to me #3. If you don't trust a company, don…

Have fun decrypting AES in Javascript, and downloading the file through your browser. (edit: on your cell phone...)

My Cellphone is as powerful as a 2002 state-of-the-art desktop machine. There are problems here, but this is not it.

Re: Dropbox Lack of Security

#106
post #95

Earlier quoted context omitted.

That's a severe oversimplification, IMO. Just recently there was news that duplicating the host_id from the Dropbox config onto another system will immediately gain access to all of the Dropbox files associated with that host_id, without further authentication. It's not security theatre to acknowledge that the security in such a system could be improved, especially as an option for those that require it. #3 could eas…

duplicating the host_id from the Dropbox config onto another system will immediately gain access to all of the Dropbox files associated with that host_id, without further authentication Sounds like the host_id is the secret key. So to paraphrase: "If you type someone's username & password into the facebook login page, you get complete access to their account"

The difference being that you can change your facebook password. It's not that easy with dropbox.

Re: Dropbox Lack of Security

#107
post #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 k…

There's still a big problem with de-duplication: Dropbox can still figure out which users have the same file, thus leaking information. That, combined with the fact that they'll know the size of the file already gives them a lot of info.

For example, if the FBI seizes a computer and finds some illegal files, they can still request Dropbox to give a list of users that have the same file.

Re: Dropbox Lack of Security

#108
post #95

Earlier quoted context omitted.

duplicating the host_id from the Dropbox config onto another system will immediately gain access to all of the Dropbox files associated with that host_id, without further authentication Sounds like the host_id is the secret key. So to paraphrase: "If you type someone's username & password into the facebook login page, you get complete access to their account"

The difference being that you can change your facebook password. It's not that easy with dropbox.

It's just as easy to de-authorize devices (and hence invalidate host IDs) on Dropbox as is is to change your Facebook password.

Re: Dropbox Lack of Security

#109
post #59

Earlier quoted context omitted.

You generate the key from your username and password and/or store it locally?

function decrypt(cipertext, key) { var req = new XMLHttpRequest(); req.open("POST", "/retrieve_user_key?key="+key); req.send(); // decryption routines return result; } Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place? Of course you also need to trust the desktop Dropbox client. The only (approximately) truly secure way to do this is with a…

> Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place?

I don't trust Dropbox to do either of these things, but at least in theory I can examine the JavaScript each time they send it to me, whereas there is no way for me to inspect Dropbox's internal operations to make sure they aren't misusing my key.

The problem becomes mechanically verifying that a received chunk of client-side JavaScript is indeed the decryption routine that it claims to be. I think this is a solvable problem.

Re: Dropbox Lack of Security

#110
post #57

Earlier quoted context omitted.

Client side. If you upload a very popular 500+mb file, maybe try a popular linux distribution iso, it will sync instantly.

so has someone written a client where you just enter hashes of popular files you are interested in and get them snyced to your dropbox?

As far as I know, not yet. It's not even publicly known how exactly the deduplication API works.

For example: is the hash enough to "prove" you have a file? Or do you need the file size (and potentially other properties, such as the first block) as well?

The only way to find this out would be to look at the protocol that the proprietary client uses.

Post reply on HN