

Dropbox Ticket: Enhanced mobile client communication security - charlief
https://www.dropbox.com/votebox/4452/enhanced-mobile-client-communication-security-encrypt-both-files-and-metadata-

======
dpritchett
Interesting that this post title doesn't properly spell Dropbox. Is that an
anti-SEO measure?

------
h5n1
Lifehacker's re-post had me scared about this. Glad HN has this to clarify;
mind's at ease once more. [http://lifehacker.com/#!5781788/dropbox-mobile-
apps-less-sec...](http://lifehacker.com/#!5781788/dropbox-mobile-apps-less-
secure-than-the-desktop-utility)

------
tayl0r
It's just the file metadata. I don't get why this is such a huge issue. Your
precious file contents are still 100% secure.

Yes, dropbox needs to change its terms or switch to https, but no reason to
get your panties in a wad over this.

~~~
abyssknight
It's just your password. I don't get why this is such a huge issue. Your
precious username and email are still 100% secure.

As easy as it is to set up SSL these days, I refuse to use that phrase: "I
don't get why this is such a huge issue." Especially when we're talking about
information leakage. It may not be a huge deal _for you_ but for _some users_
it is. Thus, it is a huge deal.

See firesheep, Tunisia, et al.

~~~
SirWart
Just to clarify things (I work on the iPhone app), the only thing being
transmitted in plaintext are the names of the files, not the file data or
username/password, and because we are using OAuth, no session cookie is
getting sent so you can't steal credentials (a la firesheep). This is also not
a technical limitation, we already use SSL in our app so sending metadata over
https is a trivial change.

The only reason we send metadata unencrypted is for user experience issues:
setting up SSL requires extra round trips , and because cell networks have a
lot of latency this makes browsing your Dropbox slower. We are close to
shipping our next release and we'll definitely be reviewing our policy before
we ship, so what are people's feelings on this tradeoff?

~~~
cstross
Here's my problem with not encrypting metadata:

Suppose we have a determined attacker who is looking to target DropBox
accounts. They can attempt to crack username/password pairs, or maybe
intercept an entire SSL session and do a brute-force attack on it later. (If
there are virgin credit card records in that session stream it may be worth
doing this even if the cost is CPU-years.)

Letting this attacker see the names of files in a session gives them a clue as
to what's stored in the DropBox account in question, and therefore lets them
choose their targets -- if a user is uploading nothing but files with names
like Hot-Fuzz-Directors-Cut.h264, they probably don't want to bother: but if
the user is updating files like customer-accounts-backup.sql or passwords.txt,
there may be money to be made. If the metadata is encrypted it forces
attackers to tackle accounts at random in hope of finding something worth
money. Which is much less attractive because the attacker has to do a lot more
work in order to be assured of a pay-off.

At the very least, it would be best if the decision of whether or not to
encrypt metadata was in the customer's hands. (Then maybe I wouldn't need to
keep my business-critical files on DropBox inside an encrypted filesystem
image, which almost certainly causes a much worse performance hit than an
extra SSL roundtrip.)

