Dropbox Ticket: Enhanced mobile client communication security(dropbox.com)
dropbox.com
Dropbox Ticket: Enhanced mobile client communication security
https://www.dropbox.com/votebox/4452/enhanced-mobile-client-communication-security-encrypt-both-files-and-metadata-
3 comments
Interesting that this post title doesn't properly spell Dropbox. Is that an anti-SEO measure?
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...
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.
Yes, dropbox needs to change its terms or switch to https, but no reason to get your panties in a wad over this.
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.
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.
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?
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?
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.)
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.)
I _definitely_ prefer the speed/smaller bandwidth footprint over filename security. I use Dropbox as a utility for sharing, not a mission critical thing that stores sensitive business or client files (or most particularly, filenames).
I understand that some people do, and How this could be important to them.
I understand that some people do, and How this could be important to them.
Personally, I'd prefer Dropbox being quicker to Dropbox being more private. But my guess is most of the techie-crowd will disagree. Also, my guess is most of the non-techie crowd won't understand the issue, but will assume filenames are not able to be snooped on.
Doesn't SSL caching, or even just leaving the connection open, take care of the performance issue?
You are 100% wrong regarding what the problem is. Username & password != file metadata
A non-snarky answer: because even the names of files can be be sensitive.
For example, learning that your boss is working on a file named "Employees to Layoff This Month" reveals information you were not aware of earlier.
For example, learning that your boss is working on a file named "Employees to Layoff This Month" reveals information you were not aware of earlier.
Excellent point, but if you are packet sniffing your boss maybe that file has some merit =)
My only point is that it's not the huge deal that the community is making it out to be.
Anyways, this is the last time I attempt to go against the hive-mind.
My only point is that it's not the huge deal that the community is making it out to be.
Anyways, this is the last time I attempt to go against the hive-mind.
Perhaps it is not a huge deal to you but I personally find it very disconcerting for a company that had always claimed up until now to encrypt all communications and storage.
Someone occasionally going against the "hive-mind" is important, and it only costs some karma.
(I do think you're wrong here, "but I'll defend to the death" etc.)
(I do think you're wrong here, "but I'll defend to the death" etc.)
I hope you don't write any webapps that I use