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

171–180 of 193 posts

Re: Dropbox Lack of Security

#171

Post by bxr »

csallen wrote: post #121

Dropbox didn't lie. This is simply a misinterpretation (or misunderstanding) of what's meant by the phrase "Dropbox employees aren't able to access user files". It's not the same as saying "It's impossible." The fact is, if you send a company your unencrypted data, it's obviously possible for them to view it at some point. Otherwise they could never encrypt it in the first place. So when they say that employees aren'…

>We trust them anyway

Much of that trust is based on the fact it is a felony, not what could just be an internal slap on the wrist.

Re: Dropbox Lack of Security

#172

Post by fluidcruft »

roblund wrote: post #135
rarrrrrr wrote: post #70

Earlier quoted context omitted.

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

I'd never heard of SpiderOak before. Reading some info on their site here is how they explain how they allow access to your files from a browser. "When you access your data via the website, in order for the SpiderOak server to send you your folder and filenames, and send your browser the plain text versions of your data, you must type in your password, which exists in the SpiderOak server's memory for the duration of…

> "which exists in the SpiderOak server's memory for the duration of your browsing session"

It would be entirely possible for SpiderOak to be compelled to store this key for the government. Once you hand over your private keys to anyone, you've lost control.

Re: Dropbox Lack of Security

#173

Post by joeyh »

IgorPartola wrote: post #162
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…

No. I don't want more security theater on their side. I want to encrypt files with my own key that they'll never get access to. No security theater is necessary in that case: I know that I am the only one that has the key since I did not share it. I spent some time looking for a service that would seamlessly facilitate me setting up a key between all my devices, and at the same time be reasonably priced. From what I…

Use public key cryptography to encrypt a symmetric encryption key. Only those who the symmetric key is encrypted to can decrypt it, and in turn use it to decrypt the content. All existing infrastructure (ie, WoT) for distributing public keys can be used.

This is the scheme I am using in git-annex's encryption. It allows a git repository to treat Amazon S3 as an encrypted git remote on which large files can be stored, rather than checking them into git directly.

Re: Dropbox Lack of Security

#174

Post by Groxx »

jlouis wrote: post #105
Groxx wrote: post #78

Earlier quoted context omitted.

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.

Oh?

Resuming downloads, large downloads (can't decrypt and stream to the disk as it comes in), and handling any future changes to the encryption algorithm (say, asymmetric instead of symmetric)? How about that, as it's in JS / attached to the DOM, an injected script has access to it? Or the several gigabytes of memory it would take to store and decrypt a gigabyte download? It'd also likely end up being an even bigger battery drain than Flash.

It's a definite problem. It won't be for long, I think, but it most certainly is now.

Re: Dropbox Lack of Security

#175

Post by drdaeman »

bdhe wrote: post #43
tlrobinson wrote: post #14

It always seemed obvious to me that Dropbox has access to your unencrypted files because they make them available to you through the web interface .

> because they make them available to you through the web interface. You could have client side javascript that decrypts the files. http://crypto.stanford.edu/sjcl/

http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...

Re: Dropbox Lack of Security

#177

Post by korny »

16s wrote: post #154
thaumaturgy wrote: post #49

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…

Great points. Trust and hope are not IT Security Controls. Take the matter into your own hands and GPG encrypt everything that you place into the cloud. That way, only you hold the decryption key. I'm sure this may violate their ToS and it is inconvenient for end-users, but in order to have a firm technical control, you have to remove "trust and hope" from the equation.

It's hardly against their TOS - they recommend using FreeOTFE or TrueCrypt to do just this: http://wiki.dropbox.com/TipsAndTricks/IncreasePrivacyAndSafe...

Re: Dropbox Lack of Security

#178

Post by rarrrrrr »

fluidcruft wrote: post #172
roblund wrote: post #135

Earlier quoted context omitted.

I'd never heard of SpiderOak before. Reading some info on their site here is how they explain how they allow access to your files from a browser. "When you access your data via the website, in order for the SpiderOak server to send you your folder and filenames, and send your browser the plain text versions of your data, you must type in your password, which exists in the SpiderOak server's memory for the duration of…

> "which exists in the SpiderOak server's memory for the duration of your browsing session" It would be entirely possible for SpiderOak to be compelled to store this key for the government. Once you hand over your private keys to anyone, you've lost control.

We recommend customers access data via the desktop client, which doesn't ever send passwords or keys to the server.

Re: Dropbox Lack of Security

#179

Post by jrockway »

ugh wrote: post #92
wahnfrieden wrote: post #76

Earlier quoted context omitted.

That's why you should always keep backups of your key somewhere. Even on paper in a safe deposit box.

We are talking here about Dropbox being simple to use for everyone and you start talking about keeping backups of keys. In safe deposit boxes, no less. Wow.

You don't need to worry about safe deposit boxes. Just don't be upset when you get a letter in the email from a law firm that's noticed some of the music in your dropbox has the same hashes as the music in someone else's dropbox.

The cloud is a scary place. Making it easy to use is not necessarily a good thing.

Re: Dropbox Lack of Security

#180

Post by bajsejohannes »

csallen wrote: post #121

Dropbox didn't lie. This is simply a misinterpretation (or misunderstanding) of what's meant by the phrase "Dropbox employees aren't able to access user files". It's not the same as saying "It's impossible." The fact is, if you send a company your unencrypted data, it's obviously possible for them to view it at some point. Otherwise they could never encrypt it in the first place. So when they say that employees aren'…

> if you send a company your unencrypted data

There is no need for this data to be sent unencrypted. Encryption could be handled completely on the client side.

Post reply on HN