Live data from Hacker News

Dropbox Lack of Security

tirania.org

111–120 of 193 posts

Re: Dropbox Lack of Security

#111
post #55

I don't care. I use Dropbox because of the unparalleled feature set and ease of integration. I have my taxes stored on Dropbox, along with a lot of other sensitive information. They're in an encrypted RAR file with a line-noise passphrase, just like they would be if I were storing them anywhere (including locally -- after all, what if Mallory steals your hard drive? Or, to parrot the most common movie plot threat, wh…

You should consider using something like truecrypt rather than rar encryption.

http://www.truecrypt.org/

Re: Dropbox Lack of Security

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

I think you're missing the point. On their website it says "Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)" and in their terms of service they say that they will turn over files to a government agency if subpoenaed.

The problem isn't security theater, it's the fact that both of the above can't be true at the same time. In other words: Dropbox lied.

Re: Dropbox Lack of Security

#113
post #65
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?

Unlimited versions within last 30 days for all free and paid users (including changesets where files are deleted), paid users can also pay extra to keep every version since file creation.

So if you were suspected of getting a secret file and placing it in a dropbox hosted truecrypt volume, there would be a record of the time/date of altering the truecrypt volume and the possibility to compare the differences between two versions.

Re: Dropbox Lack of Security

#114
post #109

Earlier quoted context omitted.

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 verifyin…

Actually, checking that two pieces of code are equivalent is undecideable:

http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_...

So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.

Re: Dropbox Lack of Security

#116

Earlier quoted context omitted.

You can store a key escrow on the dropbox server protected by a password or a token. Just a matter of designing something secure and useable. Not easy, but possible.

That doesn't work, Dropbox/your favourite TLA will just wait for you to supply the password and then save the key. Trading off the inconveniences of good crypto (e.g. no web interface) for that little security isn't worth it.

The system suggested by shin_lao does not require that the password be passed back to Dropbox to retrieve the key.

Re: Dropbox Lack of Security

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

The point is that these are the kinds of claims you should be making in the marketing. Users are smart enough to understand "We are vigilant about making sure that user data is never compromised". You shouldn't be trying to bamboozle them with official-sounding acronyms like AES - that when it comes down to it, mean little.

Re: Dropbox Lack of Security

#118
post #116

Earlier quoted context omitted.

That doesn't work, Dropbox/your favourite TLA will just wait for you to supply the password and then save the key. Trading off the inconveniences of good crypto (e.g. no web interface) for that little security isn't worth it.

The system suggested by shin_lao does not require that the password be passed back to Dropbox to retrieve the key.

If Dropbox wants to serve the files to a standard browser, it does need the decryption key. If I misunderstood and shin_loa wants to drop the web interface, why "key escrow" - why not directly derive the key from the passphrase?

Re: Dropbox Lack of Security

#119
post #107
post #25

Earlier quoted context omitted.

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.

As has been mentioned elsewhere in the thread -- de-dupe isn't responsible. If Dropbox is storing your files -- then the TLA can always request Dropbox to give a list of users that have the same file. (Unless you have some form of independant crypto/hashing)

Re: Dropbox Lack of Security

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

As others said, #1 is false. You can look at your data whenever you want without letting others do the same, even if they have access to the data. That's what asymmetric (or even symmetric) cryptography does.

Apart from that, did anyone ever think Dropbox was completely secure? The mere fact that they perform deduplication, which is not possible if they can't read your data, should have tipped people off to it. Not to mention showing the files in the web client, sharing, etc.

Post reply on HN