Forgot your password?
typodupeerror
Security Data Storage Encryption Privacy

Dropbox Head Responds To Snowden Claims About Privacy 176

Posted by samzenpus
from the protect-ya-neck dept.
First time accepted submitter Carly Page writes When asked for its response to Edward Snowden's claims that "Dropbox is hostile to privacy", Dropbox told The INQUIRER that users concerned about privacy should add their own encryption. The firm warned however that if users do, not all of the service's features will work. Head of Product at Dropbox for Business Ilya Fushman says: "We have data encrypted on our servers. We think of encryption beyond that as a users choice. If you look at our third-party developer ecosystem you'll find many client-side encryption apps....It's hard to do things like rich document rendering if they're client-side encrypted. Search is also difficult, we can't index the content of files. Finally, we need users to understand that if they use client-side encryption and lose the password, we can't then help them recover those files."
This discussion has been archived. No new comments can be posted.

Dropbox Head Responds To Snowden Claims About Privacy

Comments Filter:
  • umm duh? (Score:3, Insightful)

    by Noah Haders (3621429) on Wednesday July 23, 2014 @10:03PM (#47520085)

    Search is also difficult, we can't index the content of files.

    umm duh, that's the point? sucks when your customers can't trust you.

    • Re:umm duh? (Score:5, Insightful)

      by AudioEfex (637163) on Wednesday July 23, 2014 @10:21PM (#47520151)
      Yeah, uh, because all "cloud" services aren't inherently ridiculous for anyone to consider secure or anything...
      • Re: (Score:3, Interesting)

        by Anonymous Coward

        Hehe, I have some clients from New Zealand and they were inquiring about some of my company's cloud service offerings. I talked a bit about them but mentioned that they would be better served by hardware that they owned. I asked if they had heard of Mega and what happened to them. They said it was on the news ALL THE TIME in New Zealand. So then I said "Well then you know that law enforcement raided Mega's servers, took them, and have since refused to give all of that data back to its owners. Would yo

      • Yeah, uh, because all "cloud" services aren't inherently ridiculous for anyone to consider secure or anything...

        Trust the math, not the people.

        • by Immerman (2627577)

          That can assure you that the providers can't access your data (Assuming you can also trust the software that implements the math), but it can't provide any assurance that *you* will still be able to access your data tomorrow. They could go out of business, their servers could be confiscated, etc,etc,etc. There's more to security than locking people out, otherwise instead of high-security door locks we'd simply fill the entire building with hardened concrete. Or burn it down. Much more reliable way of keep

      • Re:umm duh? (Score:5, Insightful)

        by Charliemopps (1157495) on Thursday July 24, 2014 @07:21AM (#47521459)

        Yea, we use a very expesnsive cloud service that per the contract is encrypted at rest and in transit. After 5yrs I happened to have a networking issue and did a packet capture on the stream... no encryption. So we approached them... "Encryption? No, we don't do that..." We explained that it was in the contract and they HAD to do that. So after 2 months they had to move us to a "Special" server and we were encrypted. I checked the packets again and we were at least encrypted in transit. A few months later we had another trouble ticket with them. One of their techs was working on it and explained how he logged in an edited the table raw to fix it. So I asked how he could do that if the data was encrypted. "Encryption? No, we don't do that..." ugh... so now we're supposedly "really" encrypted.

        The problem with cloud services is they can lie cheat and steal with your data and there's nothing you can do about it. You can't verify it, you can't test it, and if anything happens to it you wouldn't have a clue. You're entirely at the mercy of the provider and as time goes on their internal staff can turn over, competence can wane, controls can get lax, and you'll have no idea any of that is happening.

        • Re:umm duh? (Score:4, Informative)

          by hsmith (818216) on Thursday July 24, 2014 @08:52AM (#47521821)
          You do realize there are several flavors of encryption, right? Microsoft SQL Server TDE is an example. You can login, perform queries, update data in any table, but all data is encrypted - it is - transparent as the name indicates.

          That also ignores things like encrypted volumes, etc. Just because individual files aren't encrypted with unique keys, doesn't mean that encryption isn't there.
          • You do realize there are several flavors of encryption, right? Microsoft SQL Server TDE is an example. You can login, perform queries, update data in any table, but all data is encrypted - it is - transparent as the name indicates.

            That also ignores things like encrypted volumes, etc. Just because individual files aren't encrypted with unique keys, doesn't mean that encryption isn't there.

            The data he updated was someones password. Wouldn't that concern you? ;-)

          • Probably using something like 2ROT13. Lame. I wouldn't use anything less than 4ROT13 even for low-security stuff.

        • Re:umm duh? (Score:5, Insightful)

          by Immerman (2627577) on Thursday July 24, 2014 @09:26AM (#47522011)

          So, when you contracted with these folks did they issue you a kilobyte-long encryption key with a warning not to lose it or your data would be permanently inaccessible? And did you have to use that key every time you stored or retrieved data with them? If not, then that's your glaring red flag that any encryption they might offer is a sham. Even if it were stored encrypted on their servers, if you can access it without supplying the encryption key that means they're essentially storing the keys in the lock to the safe.

          Which is why, honestly, I'm okay with folks like Dropbox being a bit lax about security, provided they're open about it. Encryption in transit is nice if you just want to keep idle prying eyes off your not-terribly-sensitive data, and SSH provides a convenient way to implement it. But if you want real security on the stored data the *only* way to get it is if you do just what they're suggesting and exercise total personal control over the encryption. That data should be securely encrypted before it ever leaves your computers, and you are the only one who should possess the keys to decrypt it. If you want people in your organization to have easy access without worrying about encryption then establish a local proxy that will transparently handle the encryption and decryption as data flows through it to your cloud provider.

          Actually that could be a great internet appliance - it could even perform indexing of the data if you wanted it to, while providing near-perfect security for *any* remote data-server offering. If anyone decides to market such a thing I want 1% for the idea - we can make each other rich.

    • Re:umm duh? (Score:5, Interesting)

      by TheRaven64 (641858) on Thursday July 24, 2014 @07:09AM (#47521437) Journal
      There are techniques that allow searching within encrypted files, but they rely on the client creating the index. You can then search the index for an encrypted search term and, if you know the keys, interpret the answer. Getting this right is quite tricky (there are several research papers about it), so he's right, but it's not impossible.

      The main reason that I suspect DropBox discourages encryption is that they rely a lot on deduplication to reduce their costs. If everyone encrypted their files, then even two identical files would have different representations server-side if owned by different users, so their costs would go up a lot.

      • Also, Dropbox is quite popular because of the capability to share files. So I upload a file to Dropbox, and then at some point I want to make it available to my coworker. I can either share it so that it appears in my coworker's Dropbox, or I can just create a public link and allow anyone to access it if I want.

        The simplest model of client-side encryption would not allow for that kind of sharing. I'd encrypt the files with an encryption key, and then I'd need that private encryption key to be able to de

        • The anonymous poster pointed out a simpler mechanism, which is used in practice on file stores that want to be encrypted on the server. This technique also has a number of advantages. Using a symmetric cypher is generally faster than an asymmetric one and using a different key for each file is just good practice anyway as it limits the damage that certain kinds of trojan can do. If you're sharing with everyone, then you may as well just give the server the AES key and ask it to decrypt the file. If you'
          • then you may as well just give the server the AES key and ask it to decrypt the file

            But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.

            I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you n

            • then you may as well just give the server the AES key and ask it to decrypt the file

              But in that model, if "the server" has the key, wouldn't Dropbox have the key? I thought that was the whole thing people were freaking out about.

              No, you'd have the key. If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.

              I understand what you (and the AC) are saying about storing an encrypted key on the server, and then re-encrypting the key for each new user you'd want to share with. That's a clever arrangement and I admit that I hadn't thought of it, but it still seems like it has the potential to create more complexity than most people want to deal with. It still means you need to manage various encryption keys, and we (Internet culture) seem intent on not developing a coherent system for managing encryption keys.

              The client just needs one key, the RSA (or equivalent) public key. You'd need to copy this between devices, but it's relatively small (under 1KB). It's small enough to fit in a version 40 QR code quite easily, so you could set up mobile devices by displaying the QR code on your la

              • If you wanted to share the file publicly, then there's no point in keeping it encrypted, so you'd provide the server with the key and it would decrypt, saving you the cost of downloading and reencrypting.

                Right, so Dropbox would have the key. Part of my point is that an awful lot of people use Dropbox for sharing, at times not terribly concerned with who is being given access, and so all this freaking out would be unfounded for that subset of cases.

                The client just needs one key, the RSA (or equivalent) public key.

                Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encry

                • Please correct me if I'm wrong because I may not have imagined this system properly. I was thinking the idea was that you encrypt each file with a single unique key, and then to use a public-key encryption scheme to encrypt that key. You can then send the encrypted file and the encrypted key to another user, knowing that it will need that users private key to decrypt.

                  Every time you upload a file, you generate a random symmetric key. You encrypt the file with this key and the key with your public key. If you want to download the file, you get the file and the encrypted key and then you decrypt the key with your private key and then decrypt the file. When you create the account, you upload your public key.

                  When you want to share a file with everyone, with no access control, you download the encrypted key, decrypt it, and provide it to the server. The server can then

                  • We do have standards and off-the-shelf libraries for everything required to implement this

                    Yes, exactly. There are libraries available so that you can create your own solution for encrypting files and managing the keys. You can do it, and I can do it, and some other guy can do it, and if anyone is unlucky enough to want to use all of the services we create, then he can have several implementations of what is essentially the same encryption scheme with multiple different methods of managing the many associated keys. Some of the key management will be made transparent by having it automatically

                    • Everything you ask for exists. The reason that Google, Microsoft, and Dropbox don't use them is that their entire business model depends on differentiation. If you could connect to their services with any third-party client that also worked with a server that you set up yourself and with their competitors' services, then their hold on the market becomes very tenuous. You're searching for technical solutions to business problems.
                    • You're searching for technical solutions to business problems.

                      Sometimes there are technical solutions to business problems. But my point from the beginning is that it wasn't simply a technical issue of whether we can encrypt things. It's whether we, the users and developers on the Internet, can agree on a set of standards that make encryption easy for people who don't understand encryption and can't be trusted to figure it out.

                      You keep pointing out that we theoretically could do all the things that needed to be done. I'm trying to point out that still, we keep not

  • by Y2K is bogus (7647) on Wednesday July 23, 2014 @10:10PM (#47520107)

    With the keys we readily hand over when warranted.... o_O

    • by Anonymous Coward on Wednesday July 23, 2014 @10:28PM (#47520193)

      I wouldn't expect anything more than that from services that are aimed at businesses, and I think you've got to be an idiot if you view a free (or dirt cheap) storage service like Dropbox as anything other than temporary space some stranger's letting you use for a while. You've got to expect that you can't rely on the data to persist when you want it, and that it'll always be there if the government or hackers or anyone besides you wants it. I don't really have a problem with that. At zero dollars, it's been handy to have around and their API is probably the simplest and best of the cloud services I've used (even though their handling of file-type-based app permissions is bizarre).

    • by Gr8Apes (679165)

      With the keys we readily hand over when warranted.... o_O

      Who needs a warrant? Just a couple of bucks for our "anonymized" (wink wink) data.

  • Duh (Score:5, Insightful)

    by backslashdot (95548) on Wednesday July 23, 2014 @10:15PM (#47520127)

    Dropbox has Condoleeza Rice on its board of directors. If anyone remembers, she was Secretary of State and also the president's National Security Advisor during the Bush administration. She basically allowed torture, and is responsible for Guantanamo. She had no problem with torturing people without even doing a basic check to see if the person being tortured was guilty of the crime he was being tortured for. And you want to talk about spying? She was part of the administration that developed the PATRIOT Act. The justification being "it's ok to spy on foreigners" .. Oh and we can DECLARE you a foreigner without any due process by making you prove your Americanness. She was cool with torturing foreigners without giving them any sort of due process, so why would you assume that she wont torture citizens if she was scared into doing so? We already know she doesn't think people need privacy.

    • by rsborg (111459)

      Why is this comment rated so low? If anything, having such a politically invested person on the board of directors really does say something about Dropbox and their views on privacy and security (yes, I do think the same about Apple and Al Gore - his values did seem to align with the company's).

      Ever since 1Password moved to iCloud sync, I've stopped using Dropbox for even stashing an encrypted file. For everything else there're more targeted cloud services.

    • Re: (Score:3, Insightful)

      by operagost (62405)
      Good thing she's not a Democrat, or we'd all be calling you racist and sexist.
      • I wonder if some of that is due to being among the first black people in a position of power. She can't really rock the boat to much and ruin things for future black politicians, so she has to be a bit conservative. I think Obama is doing much the same thing.
    • by towermac (752159)

      Dude, the election is long over, and your guy won.

      "She basically allowed torture"

      Huh. I remember Bush being in charge during that time.

      "is responsible for Guantanamo"

      I don't even know what to do with that.

      "torture"

      I guess she held the garden hose eh?

      "She was part of the administration that developed the PATRIOT Act."

      the Act passed the House 357 to 66; passed the Senate by 98 to 1. But somehow her fault..

      People hate on her because she's a black female Democrat that switched parties, which is not allowed. Tha

      • Nobody that resorts to such a cowardly and fear driven act as torture is a badass. A badass wouldn't be so scared of the consequences of not torturing someone that they would be willing to give up their humanity. Only fear, paranoia, and revenge can drive someone to torture another.

  • Dropbox is cloud. Cloud is a remote hard disk. My hard disk has nothing to do with privacy; anyone who can SSH into my computer can read my hard disk. Put that hard disk on the Internet, in "the cloud", and the same thing applies, anybody logged in to the Internet can read your dropbox. Hey, I thought that was the PURPOSE of Drop box, to share files. If you want privacy, burn a DVD and hand it to the guy.

    For me, my notebook has a 1TB hard disk. I have a web site I control. Yeah, my web site is hostile to

    • Re: (Score:3, Insightful)

      How is that insightful? You've completely missed the whole point of privacy laws. In law, your hard drive in your computer is yours, and it is not public unless you go out of your way to make it so. In particular, anyone who uses ssh to access your hard drive breaks the law, unless you've specifically authorized them to do so. Lots of people, some slashdot readers, have gone to jail for doing just that.

      Also, your hard disk, in your computer, in your house isn't searcheable by law enforcement unless they h

      • by HuguesT (84078)

        Exactly. Also the NSA doesn't even need warrants. How convenient for them that everyone is leaving these fine files in the same place for them to search...

      • Which is why I wouldn't put anything on Dropbox that I wouldn't want the NSA or FBI to know about. Being traceable publicly is not a problem for me; I just want the ability to do less traceable things when I want to.

    • My hard disk has nothing to do with privacy; anyone who can SSH into my computer can read my hard disk.

      Really? Can you give me the IP, login, and password? I'm curious. I normally set up SSH in such a way to prevent any ol' person on the Internet from logging in, but that's just me.

      anybody logged in to the Internet can read your dropbox

      Maybe if you share your whole Dropbox publicly, and then pass the link around. But as for me, I usually don't do that. In fact, my company Dropbox is set up so that I can't even share files with people outside of my company. I guess Dropbox can see my data, but that's not the same as "anybody logged in to the Internet".

      How

  • people need to stop using these services and host it themselves. its not hard and its the only way to get control.

    • by davmoo (63521)

      Yep, that's exactly what I do. I know exactly what's going on with my data, and if its insecure, I know its my own dang fault.

      • the only way you get hacked is if someone hacks YOU. Which is a lot less likely then someone hacking facebook or whatever. If the NSA etc wants to get access they have to penetrate you specifically. The big dragnet operations will largely pass you by if you host it yourself.

  • Trust No One = TNO (Score:5, Insightful)

    by Streetlight (1102081) on Wednesday July 23, 2014 @10:54PM (#47520311) Journal
    Steve Gibson's mantra: TNO. If the host has your encryption password/key, then they can't be trusted. If you don't believe that, ask Snowden's email provider, Lavabit's founder Ladar Levison: http://www.wired.com/2014/04/l... [wired.com]
  • by scottbomb (1290580) on Wednesday July 23, 2014 @10:56PM (#47520319) Journal

    I don't need them to do "rich document rendering" (whatever the hell that is) nor do I need them (or anyone else to) index the contents of my files. All I want is for someone to STORE the shit and keep it synced between all my machines. Dropbox does this very well.

    As for encryption, I don't have time for that nonsense. Anything sensative such as financials is kept locally on my own server or burned to a DVD and put in the closet. I couldn't care less if someone gets a hold of my vast collection of pictures and documents. It is private, but not going to hurt me if someone at the NSA starts snooping around.

    • by SuluSulu (1039126)
      You might consider checking out Spideroak.com [spideroak.com] as they claim to not store your password on their servers so that it is impossible for them to decrypt your files without you. Also they have a decent synchronization client for all major OSs. Disclaimer: I am not affiliated with Spideroak, just a user.
      • by chihowa (366380) * on Thursday July 24, 2014 @11:27AM (#47522751)

        If you use their web interface, they will store your password on their servers. Be aware of that.

        Also, your account password is the the key used to encrypt your data (easy to verify: accessing your data on a new device only requires your account password). They use PDKDF2, which expands the password into a larger key, but (obviously) doesn't add any entropy to that already present in the password. Choose your password wisely.

        That password is also used to access the billing, etc web interface, so they do keep at least a hashed copy of your password on their servers.

        As with any closed source and opaque solution, you shouldn't depend in any way on unverifiable claims. They could now, or at any time in the future, store your passwords. You're better off handling your own security than trusting magic black boxes.

    • by rioki (1328185) on Thursday July 24, 2014 @05:55AM (#47521263) Homepage

      You know there is a web interface to Dropbox too? People expect to read their documents, like word or PDF right there online. To do this the service must index the files and read them. Obviously if you encrypt the files, this can not be done.

      I use Dropbox as my offsite backup of sensitive information and I trust the information to be safe. Simple, I encrypt the tar-ball with symmetric GPG. But then again I can only download the file vie the web interface if I wish and not view the contents online... buhuhu

  • by Animats (122034) on Wednesday July 23, 2014 @11:37PM (#47520455) Homepage

    iDrive [idrive.com], which is supposed to be a remote backup service, has a similar problem. They used to be a honest remote backup service, with client-side encryption. (They didn't protect the client password very well on the client machine, but at least the server didn't have it.) File contents were encrypted, but filenames were not, so you could look at logs and the directory tree on line. Then they came out with a "new version" of the service, one that is "web based" and offers "sharing".

    For "sharing" to work, of course, they need to know your encryption key. They suggest using the "default encryption key". Even if you're not "sharing", when you want to recover a copy of a file, you're prompted to enter your encryption key onto a web page. The web page immediately sends the encryption key to the server as plain text, as can be seen from a browser log. Asked about this, they first denied the problem, then, when presented with a browser log, refused to answer further questions.

    They try real hard to get their hands on your encryption key. After you log into their web site, a huge pop-up demands your encryption key. Without it, some of the menu items at the top of the page still work, and with some difficulty, you can actually find logs of what you backed up. You can't browse your directory tree, though.

    It's possible to use the service securely (maybe), but you have to run only the application for recovery, and never use the web-based service. They don't tell you that.

    This isn't a free service. I pay them $150 a year.

    • by jhaar (23603)

      You're still paying money with those concerns?? Just move your money (and data) to SpiderOak and be happy: good client-side crypto can be done properly.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        And Spideroak gives you a closed binary to run on your endpoints, and you quite happily type your password into that. Uh-huh.

        Spideroak are just another vendor saying 'trust us not to have been served an NSL' and trust us not to capture your key with the client software if served an NSL/warrant.

        Once the spideroak client is open and audited, perhaps at that point their marketing about a secure server architecture makes a difference.

      • by chihowa (366380) *

        Just move your money (and data) to SpiderOak and be happy: good client-side crypto can be done properly.

        And you're basing that on what, exactly? Marketing claims. And in reply to a post about how marketing claims ended up not being true in iDrive's case.

  • Syncplicity [syncplicity.com] lets enterprises store files on their own servers, with an extra layer of authentication that prevents Syncplicity staff from getting to the files. It still allows for access to these files through a web browser. When enterprises use single-sign-on, users don't even realize that they're authenticating multiple times.

    This is a very hard problem to solve for consumers, though. Most people don't have the time to set up their own cloud servers.

  • by ddt (14627) <ddt@davetaylor.name> on Thursday July 24, 2014 @01:56AM (#47520805) Homepage
    Perhaps "hostile" was unfair, but I appreciate that he said made it sound shocking. I am shocked when I learn people store secret docs unencrypted on Dropbox. Then they are then shocked when I tell them Dropbox is insecure. There should be a lot less shock all around.
    • by Immerman (2627577)

      It would be nice if Dropbox et. al. included prominent disclaimers to warn the less-savvy (i.e. most of their user base) that data stored on their servers is insecure, but given the number of shady competitors who claim security without delivering anything better I suppose I can understand why they don't.

  • by Craig Ringer (302899) on Thursday July 24, 2014 @02:09AM (#47520837) Homepage Journal

    That's an accurate and sensible response.

    In fact, 3rd party client encryption tools might be better than built-in support by Dropbox. They can be produced outside the USA by companies or individuals unaffiliated with DropBox and potentially harder to pressure into backdooring the software in an update.

    I'll stick to SpiderOak personally, despite the awful transfer speeds and somewhat clunky usability, because I just want a remote store that stores my gibberish bytes and gives me the same gibberish bytes back later.

  • I tried using SpiderOak, but it was a bit too slow for me atm. What I really needed was a off-site backup, so I ended up with Amazon Glacier with client side encryption. Can't beat the price :) I have dropbox too, and it's ok for it's use. Just have to realize that everything you upload to them is not private anymore. I wish more services did secure by default and option to reduce security for wanted features.
  • There is also a strong argument for company like Dropbox to avoid or at least not encourage too much client side encryption: deduplication. If deduplication is no more working, it will considerably increase their storage cost, which the core of their business.
  • by DrXym (126579) on Thursday July 24, 2014 @04:29AM (#47521091)
    Hi Dropbox, stop blaming users. You are in the strongest position possible to offer encryption in Dropbox because it's your software. You know the triggers that cause files to be exchanged. You know the optimal way to minimize network traffic. If you can send and receive files, then why can't you also encrypt / decrypt files in this step? This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client. This encryption could also scramble file names and break up large files into parts to obfuscate their size.

    Yes you'd have to warn the user that a protected folder means exactly that and there are restrictions on what you can do with it, e.g. access in some dropbox clients, web browsers, sharing to others. People will get it.

    Even better, this encryption / decryption could be thrown open as a pluggable API so 3rd parties could write their own encryption protocols to whatever personal or corporate standard they desired. For transparency the aforementioned passphrase encryption could even be supplied for review.

    Same goes for Skydrive, Google Drive etc. There is no excuse for not offering encryption. Not that I'm in the tinfoil hat camp to think this is to facilitate monitoring (although it does). More likely it's because these cloud storage servers use file hashing to spare themselves the bother of storing 1,000,000 copies of the same file. It still sucks though and even if the option is off by default, encryption of at least one folder should be provided.

    • by coofercat (719737) on Thursday July 24, 2014 @08:46AM (#47521801) Homepage Journal

      You realise dropbox is free, right? Why should they do something expensive like offer encryption on a service that is (a) free, and (b) for sharing files. Sharing's hard if your stuff is encrypted, and sharing is the source of most of Dropbox's value.

      If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.

      There's room to suggest Dropbox should offer a pay-for encrypted service. The thing is, no matter how well they do it, it'll always be vulnerable to government interference, and it'll never be fully trusted anyway. BYO means no government interference and trust *for the relatively small number of people who care* without raising the costs too much for the multitudes who don't.

      • by trawg (308495)

        You realise dropbox is free, right? Why should they do something expensive like offer encryption on a service that is (a) free, and (b) for sharing files. Sharing's hard if your stuff is encrypted, and sharing is the source of most of Dropbox's value.

        I'm a paying Dropbox customer.

        I would love a feature that lets me client-side encrypt my files before they go to their server; one where the keys never left my machine - being aware that if I lose them, I lose all my data.

        I would want the client software to be open source though and suspect that might not be in their interests.

        Ultimately though I think they've made a conscious choice to not offer a feature like this not because they don't want to or because NSA, but because they see it as a support nightma

        • I like my idea for client-side encryption. I get some crypto software from a third party, preferably open source, and I encrypt stuff and then put it in the Dropbox folder. If I'm feeling paranoid, I get a cheap computer, don't connect it to anything else, and use USB sticks to move plaintext in and ciphertext out.

          I wouldn't trust any feature from the vendor to do encryption and decryption on the fly. If I'm going to be cautious and secure, I'm going to do it right.

      • by DrXym (126579)

        You realise dropbox is free, right?

        Basic Dropbox is, none of the other options are. And besides, why is that an excuse? If they can encrypt data as they send it, and as they store it on the cloud, why is it impossible to encrypt it on the client, or provide an API to allow a 3rd party to encrypt it? Furthermore, as it is the paid service that pays their wages, why aren't they implementing a feature that customers, particularly corporates would pay for and which would enhance their reputation for secure storage?

        If you want encryption, then fine, do it yourself. You obviously know that your stuff won't be indexable or shareable so won't be calling for support or slagging Dropbox off online when you find indexing and sharing not working.

        Well that's a stupid argument

    • by Immerman (2627577)

      There absolutely are several reasons for not offering encryption. Some of the big ones that leap out at me:
      1) Most users are technically incompetent, and when they lose their encryption key they'll be prone to blaming Dropbox for the loss of data.
      2) Compression and data de-duplication between users is effective on unencrypted data, not so much on white noise. Make encryption standard and plan on being able to offer only a small fraction of the capacity at the same price point.
      3) If you want real security

      • by DrXym (126579)
        1) Then you put a big warning on the feature making it clear that the user must remember their passphrase. You could also make it only work on a folder explicitly called Protected to hammer this home.

        2) Most encryption schemes compress before encrypting. So nothing is lost there. As for de-duplication, I don't see that being a huge concern because a) even if encryption is an option most people won't use it and b) When TFA has dropbox's head honcho saying "We think of encryption beyond that as a users choi

        • by Immerman (2627577)

          1) Rule #1 of UI programming - essential messages will never be read. A "protected" folder might work though. You could also potentially offer an offline key storage service (with heavy validation for retrieval) so that those who are willing to trust you can at least get protection from anyone *else* accessing their data.

          2) you may have a point

          3) Umm, exactly? You seem to be agreeing with my point. Client-side encryption offers a shot at real security, server-side mostly only offers a minor inconvenienc

          • by DrXym (126579)
            Read my original message. I was never pushing for server side encryption. As far as I'm concerned server side encryption is pretty worthless. It might stop an employee stealing data without authorization but it doesn't stop the government, or any 3rd party armed with a subpoena coming in and taking your stuff. But DropBox has fat clients. They can implement encryption on the client side before it ever reaches the server. They could also make the encryption pluggable so somebody with a hard token, or a finge
    • 1. Dropbox implements server-side encryption.
      2. NSA/TLA drops by.
      3. Dropbox gives them your keys.
      4. No profit.

      You are utterly failing to understand the issue. Have you been living under a rock for the last several years?

      • by DrXym (126579)
        "This could be as simple as providing a settings screen where the user enters a passphrase and once enabled all files within a protected folder are encrypted before they leave the client." You are utterly failing to read my post. I didn't say server side encryption.
        • Then they aren't actually "offering strong encryption." They're just offering an endpoint for the user to hook into? How is that different from what they're already doing?

          • Personally, trusting the closed-source Dropbox desktop client to do your encryption for you and not ever transmit your keys back to the mothership for the inevitable NSA demands is more trust than I'm willing to give. And you remember the hullabaloo where it turned out that their desktop client auth was horribly, horribly insecure?

            Just make a dynamic TrueCrypt volume.

            • by DrXym (126579)
              False security. If you're paranoid that Dropbox sends your password back then you shouldn't be using it at all. Period. It wouldn't be hard for them to infer that the frequently changing, fixed size random file they were stashing was a truecrypt volume and for them to enumerate the mount points to see what was in it.
              • It wouldn't provide much in the way of plausible deniability, but please tell me about how easy it is for them to mount it without the keys. There definitely wasn't a federal case [wikipedia.org] with some guy from South America where the FBI admitted after a year that they couldn't crack his encryption.

                enumerate the mount points to see what was in it.

                Not quite sure what you mean by this...as a dynamic file, it's only going to have one "mount point," and while encrypted at rest it's more or less (less) indistinguishable from entropy except for the headers.

          • by DrXym (126579)
            Please read what I wrote. Dropbox could offer to encrypt a protected folder. By default that could be passphrase based encryption. The encryption could be pluggable to allow other forms of encryption. The passphrase based encryption source / algorithm could be submitted for review.
  • Use TrueCrypt! (Score:3, Informative)

    by Anonymous Coward on Thursday July 24, 2014 @09:40AM (#47522083)

    As long as you still trust TrueCrypt, there's no reason you shouldn't use an encrypted container file (or multiple smaller containers) in your Dropbox. Some people might not know this, but Dropbox only re-uploads the parts of the file that change (it does a binary comparison), and TrueCrypt typically only updates relatively small sections of the container file when you add/remove/modify a file in the container, so it doesn't take much bandwidth except for the initial upload. Just make sure you dismount frequently enough to allow Dropbox to sync when you make changes. (I'd recommend setting TrueCrypt to automatically dismount after an hour or so of no data being read/written.)

    You could use the dynamic disk option when creating the TC container to save bandwidth during the initial upload, if you're starting with an empty container (the size of the container will change, up to a set maximum, to match the contents), but that will have other performance penalties when using the container, and it brings with it the increased risks. In particular, it makes it possible for an analyst to get some idea of how you are storing files in the container, potentially making it easier to break the encryption.

    And since it's being stored in the cloud, you should maximize your security by using local keyfiles/tokens rather than a single password. You might as well assume that the whole world has a copy of the container.

    For convenience, you can store a portable unencrypted copy of TrueCrypt in Dropbox as well, but you should really only do that if you keep a local copy of the checksums for the binaries and compare them to the files whenever you run them. (That will ensure that nobody has accessed your account and replaced your portable TC binaries with compromised versions capable of stealing your keys.) Or carry a portable version on a USB drive.

    The only downside I can see to this is that if you need access to your files on a new machine, you will need to download the whole container, and if the new machine is compromised, you could have your keys stolen. Even so, it's much more secure than using Dropbox on its own, and in my opinion, it's worth the potential inconvenience to have good encryption and cloud access.

  • How to do this transparently: Use Dropbox normally. Create a folder call ".encrypted". Use "encfs" to mount this folder to some mount point, say "DropboxData". The stuff you put into DropboxData will be will be encrypted locally before being put into the ".encrypted" folder on Dropbox.

    Anything you don't consider private goes into Dropbox normally. Anything sensitive goes into DropboxData. You decide the balance.

    You can get encfs clients for Linux, Mac, Windows and even Android.

  • "It's hard to do things like rich document rendering if they're client-side encrypted."

    The documents are only rendered at the client where the encryption is,nobody else has to render.

    Indexing every word in a document at a 3rd party, is kinda counter-productive for encrypted documents.

  • People ought to know by now that the internet is not "private." You can't expect privacy from providers. Everyone is responsible for their own security. You can't store something on someone else's server and expect no one will ever look at it, unless you've encrypted it, and encrypted it on your own machine. The only area where we don't have this control is with email, since it takes two to encrypt. But that's not your email provider's fault.

  • by Kazoo the Clown (644526) on Thursday July 24, 2014 @01:15PM (#47523553)
    So in other words, Dropbox confirmed Snowden's claims.

The study of non-linear physics is like the study of non-elephant biology.

Working...