Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dropbox Lack of Security

tirania.org

Post reply on HN
Print view View original

61–70 of 193 posts

Re: Dropbox Lack of Security

#61

Post by steve19 »

arashf wrote: post #3
zdw wrote: post #2

Couple this with the unencrypted metadata on mobile problem: https://grepular.com/Dropbox_Mobile_Less_Secure_Than_Dropbox... And how their "encryption" on the server side is basically a lie, as they do dedupe on data: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u... I'm stunned that anyone would use them for anything for ephemeral data you wouldn't mind posting in public.

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…

I love your product but your encryption is pretty useless and y'all must know it.

It only protects my data if your S3 account is compromised. There is a much greater chance that your web frontend, servers or client are compromised (either by an external or internal attacker) and then my files are easily accessed and decrypted.

It is like naive programmers who store user passwords with 'government level encryption' instead of correctly salting and hashing them, thus having to put encryption key in the source code

select AES_ENCRYPT("user password", "our secret key");

Saying your CEO can't access it, is just more security theater.

Re: Dropbox Lack of Security

#62

Post by bdhe »

tzs wrote: post #25
tzs wrote: 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…

That's an excellent solution. A couple of points:

1. It is usually not a good idea to use your key as a function of the message. Here, you would require your hash function to have a good min-entropy given inputs from whatever distribution M comes from. I believe SHA-256, as of today, will satisfy these needs.

2. Even if H is modeled as a perfect hash function (i.e., a random oracle, in crypto literature) you would require that AES itself does not use H in any particular special way. Think of AES' which is just like AES except when k=h(m) for any message, it just outputs k (i.e., cheats). It would be nearly impossible to detect this behaviour of AES' under normal circumstances because H is pre-image resistant, but clearly, this would trivially void the security of the scheme.

The suggestion is exactly what came to my mind, but the proof, although should most definitely hold when instantiated with AES and SHA-256 will require some work to be proven in general.

Re: Dropbox Lack of Security

#63

Post by tlrobinson »

bdhe wrote: post #59
tlrobinson wrote: post #44

Earlier quoted context omitted.

And where would the decryption keys come from?

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 an open source client you can inspect and compile yourself (i.e. tarsnap).

Re: Dropbox Lack of Security

#64

Post by oconnore »

shin_lao wrote: post #56
palish wrote: post #52

Earlier quoted context omitted.

One of the reasons Dropbox is successful is because anyone can use it. Even your mother. In fact, one of the reasons Drew was originally accepted into the YC program was because his sister was using it when he applied. "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." In order for the data to be encrypted securely, you would need to generate a…

The authentication token can be generated and managed by the software. It would then be protected by the account password, if any (Windows and MacOS X offer this feature). Doable, and even better, you can make that a 30 € / month corporate option. ;)

Isn't one of the major cool things about dropbox that if your computer hard drive gets smashed (and thus the key is destroyed), you can still access your files somewhere else?

Re: Dropbox Lack of Security

#65

Post by bdhe »

earl wrote: post #6

truecrypt ftw If you're uncomfortable with dropbox, put a truecrypt partition right inside your dropbox folder.

In theory, if multiple snapshots of truecrypt are maintained, I believe it must be secure, but did the designers of truecrypt keep that in mind? Does dropbox maintain periodic snapshots of uploaded files?

Re: Dropbox Lack of Security

#66

Post by bradgessler »

arashf wrote: post #58
bradgessler wrote: post #48

Earlier quoted context omitted.

To parse that, are you saying that under such a circumstance, a government agency would have to provide the names of each person they suspect have that particular file? Or could they demand the names of all users that have a particular digest of that file?

basically, the government could try to make that type of request independent of backend implementation. what protects users against such an obtrusive action (effectively violating every user's privacy in search of the bad guys) are the provisions of the electronic communications privacy act.

Link http://en.wikipedia.org/wiki/Electronic_Communications_Priva...

Re: Dropbox Lack of Security

#67

Post by gst »

tzs wrote: 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…

This system already exists.

* Wuala (using encryption but somewhat insecure deduplication)

* SpiderOak (using more secure deduplication: https://spideroak.com/blog/20100827150530-why-spideroak-does...)

Re: Dropbox Lack of Security

#68

Post by bdhe »

tlrobinson wrote: post #36
theFco wrote: post #28

Earlier quoted context omitted.

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.

Yes, I read that article too. That information leakage vulnerability can be eliminated by requiring the user always upload the file the first time they store it. Subsequent uploads of the same file for the same user could be skipped. De-duplication across users in storage is also possible without leaking information. What is not possible (AFAIK) is the combination of the two requirements: 1) de-duplication across use…

You can do (1) and (2) but it is not trivial to prove that it works. See: http://news.ycombinator.com/item?id=2461713

Re: Dropbox Lack of Security

#69

Post by bdhe »

tlrobinson wrote: post #63
bdhe wrote: 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 was thinking about the subpoena situation, when the Govt. demands Dropbox to hand over keys. I presume DropBox can definitely send compromised JS or even a malicious client. This is very reminiscent of the whole notion of trusting trust! http://en.wikipedia.org/wiki/Backdoor_(computing)#Reflection...

Re: Dropbox Lack of Security

#70

Post by rarrrrrr »

patio11 wrote: post #32

This is the first time I've heard someone on HN actually ask for more security theatre. Sure, Dropbox could spend seven figures to get a ISOxxxx whatever consultancy to draw up a 125 page document describing their internal checks, do the obligatory all-hands yearly mandatory training where you have to get 10/10 questions right and question 1 is "A user has uploaded naked pictures of themselves to their account. True…

#1 is not true. SpiderOak and Wuala both have products in the marketplace today that demonstrate the effective use of encryption in a backup and sync app. SpiderOak has no ability to examine or to give the plaintext of a user's data to a government or anyone else - not filenames, folder names, etc. On the servers, we just see sequentially numbered encrypted containers. We are incapable of betraying our customers in this way.
Post reply on HN