5 ms·

Dropbox will never get security right I fail to see how you conclude that. Yes, they did have several glitches in the past, and no, they did not always respond

by yuvadam 15y ago

Dropbox will never get security right I fail to see how you conclude that. Yes, they did have several glitches in the past, and no, they did not always respond as they should have. But there are some pretty smart people working at Dropbox. What makes you think they do not have the capacity to solve security issues?

arethuza 15y ago
I suspect what that comment means is that Dropbox have traded security for ease of use at a fundamental level - compared to something like tarsnap (which is dedicated to doing backups in a very secure way) Dropbox does look a lot less secure but it is also a lot easier to use and supports a much wider ranges of uses. Edit: I am a pretty happy DropBox user, but I only store files there that I wouldn't really care too much if they were made public. DropBox to me is about convenience, not about security. Edit2: I was a pretty happy DropBox user, now that I think about what having a system that is prone to "failing open" means I'm seriously thinking about closing my account. However, I'll wait and see what the "official" explanation is first.
mike-cardwell 15y ago
They should have made it so files can only be encrypted/decrypted client side. They sacrificed this security so that they could do two extra things. 1.) De-duplication 2.) Web access to the files. They also sacrificed the security of the mobile clients by disabling SSL, in exchange for a small speed increase. Those are the main reasons I have come to this conclusion.
- arethuza 15y ago
  From what I can see the mobile clients do use SSL: http://forums.dropbox.com/topic.php?id=24507 http://forums.dropbox.com/topic.php?id=24507
  - bxr 15y ago
    They do now. Here is a forum post where they admit that mobile SSL was impossible. http://forums.dropbox.com/topic.php?id=10669 http://forums.dropbox.com/topic.php?id=10669
    - arethuza 15y ago
      That is pretty bad! :-(
- ssmoot 15y ago
  I think #1 covers it. It feels a bit awkward to even refer to file-level hashing and lookup as de-duplication as it's more commonly known in block-level de-dupe. Regardless, on documents it's probably safe to assume they get close to 2:1 compression ratio. I'd assume that the de-dupe of large binaries is a huge part of what makes running such a business on very expensive cloud-storage systems financially viable. Would Dropbox work financially without it? They could offer a non-de-duped version at much higher cost for the security minded, but then they've implied that the basic version is fundamentally flawed. Just an interesting technical barriers to think about (IMO).
- tzs 15y ago
  Neither de-duplication nor web access require server-side encryption/decryption. Here's how you do a Dropbox-like service with all encryption handled by the clients, but that allows de-duplication and web access. Let's call the service DBL (for Dropbox-like). 1. Each user has a public/private key pair. This is generated client side, deterministically from the user name and password. The public key is stored on the DBL server. 2. To store a file on the DBL server, the client encrypts the file with, say, AES256, before sending the data to the server. The key is deterministically derived from the file contents, say by SHA256. 3. The client keeps a file that contains a mapping from files to their encryption keys. This file is encrypted using a public key system, with the public key being the user's public key. It is stored on the DBL server (and no doubt cached locally on the client). The above is sufficient for non-shared files. When you wish to retrieve a file from a client other than the one it came from, the retrieval client can grab the file/key mapping file, decrypt it using your private key, and then lookup the decryption key for the file. For files that are to be shared with specific people, the client maintains a file for each person you share with. In this file it stores the mappings of files to encryption keys for the files you are sharing with that person. This file is stored on the DBL server, encrypted with the public key of the person you are sharing with. De-duplication is possible in this system because when two people store identical files, they pick the same encryption key, and so the end result is the same encrypted data. Web access is possible, as long as Javascript is allowed on the client, by implementing the key retrieval and the AES decryption in Javascript. Note that DBL never sees the unencrypted data, and they never see the encryption key for a file in plaintext--they only see it when it is encrypted via your public key (or the public key of someone you are sharing the file with). Even if they are breached, the crackers cannot get your data. Same goes for if they are subpoenaed--they can't give up your plaintext because they don't have access. Note also that DBL doesn't actually need your user name. All they need is your public key (at least as far as operation of the file storage/retrieval/sharing system goes--they need more for billing if you are using paid services, of course).
  - arethuza 15y ago
    "AES decryption in Javascript" How would you display that data as a file or save it locally? I guess you could do it in Flash/Java using something like Downloadify https://github.com/dcneiner/Downloadify https://github.com/dcneiner/Downloadify
bluedanieru 15y ago
What makes you think 'capacity' has anything to do with it? I'm sure those smart people you think work there could get security right, but that doesn't mean management has budgeted the resources for it.
- deleted 15y ago
  [deleted]

by yuvadam 15y ago

arethuza 15y ago

I suspect what that comment means is that Dropbox have traded security for ease of use at a fundamental level - compared to something like tarsnap (which is dedicated to doing backups in a very secure way) Dropbox does look a lot less secure but it is also a lot easier to use and supports a much wider ranges of uses. Edit: I am a pretty happy DropBox user, but I only store files there that I wouldn't really care too much if they were made public. DropBox to me is about convenience, not about security. Edit2: I was a pretty happy DropBox user, now that I think about what having a system that is prone to "failing open" means I'm seriously thinking about closing my account. However, I'll wait and see what the "official" explanation is first.

mike-cardwell 15y ago

They should have made it so files can only be encrypted/decrypted client side. They sacrificed this security so that they could do two extra things. 1.) De-duplication 2.) Web access to the files. They also sacrificed the security of the mobile clients by disabling SSL, in exchange for a small speed increase. Those are the main reasons I have come to this conclusion.

arethuza 15y ago
From what I can see the mobile clients do use SSL: http://forums.dropbox.com/topic.php?id=24507 http://forums.dropbox.com/topic.php?id=24507
- bxr 15y ago
  They do now. Here is a forum post where they admit that mobile SSL was impossible. http://forums.dropbox.com/topic.php?id=10669 http://forums.dropbox.com/topic.php?id=10669
  - arethuza 15y ago
    That is pretty bad! :-(
ssmoot 15y ago
I think #1 covers it. It feels a bit awkward to even refer to file-level hashing and lookup as de-duplication as it's more commonly known in block-level de-dupe. Regardless, on documents it's probably safe to assume they get close to 2:1 compression ratio. I'd assume that the de-dupe of large binaries is a huge part of what makes running such a business on very expensive cloud-storage systems financially viable. Would Dropbox work financially without it? They could offer a non-de-duped version at much higher cost for the security minded, but then they've implied that the basic version is fundamentally flawed. Just an interesting technical barriers to think about (IMO).
tzs 15y ago
Neither de-duplication nor web access require server-side encryption/decryption. Here's how you do a Dropbox-like service with all encryption handled by the clients, but that allows de-duplication and web access. Let's call the service DBL (for Dropbox-like). 1. Each user has a public/private key pair. This is generated client side, deterministically from the user name and password. The public key is stored on the DBL server. 2. To store a file on the DBL server, the client encrypts the file with, say, AES256, before sending the data to the server. The key is deterministically derived from the file contents, say by SHA256. 3. The client keeps a file that contains a mapping from files to their encryption keys. This file is encrypted using a public key system, with the public key being the user's public key. It is stored on the DBL server (and no doubt cached locally on the client). The above is sufficient for non-shared files. When you wish to retrieve a file from a client other than the one it came from, the retrieval client can grab the file/key mapping file, decrypt it using your private key, and then lookup the decryption key for the file. For files that are to be shared with specific people, the client maintains a file for each person you share with. In this file it stores the mappings of files to encryption keys for the files you are sharing with that person. This file is stored on the DBL server, encrypted with the public key of the person you are sharing with. De-duplication is possible in this system because when two people store identical files, they pick the same encryption key, and so the end result is the same encrypted data. Web access is possible, as long as Javascript is allowed on the client, by implementing the key retrieval and the AES decryption in Javascript. Note that DBL never sees the unencrypted data, and they never see the encryption key for a file in plaintext--they only see it when it is encrypted via your public key (or the public key of someone you are sharing the file with). Even if they are breached, the crackers cannot get your data. Same goes for if they are subpoenaed--they can't give up your plaintext because they don't have access. Note also that DBL doesn't actually need your user name. All they need is your public key (at least as far as operation of the file storage/retrieval/sharing system goes--they need more for billing if you are using paid services, of course).
- arethuza 15y ago
  "AES decryption in Javascript" How would you display that data as a file or save it locally? I guess you could do it in Flash/Java using something like Downloadify https://github.com/dcneiner/Downloadify https://github.com/dcneiner/Downloadify

bluedanieru 15y ago

What makes you think 'capacity' has anything to do with it? I'm sure those smart people you think work there could get security right, but that doesn't mean management has budgeted the resources for it.

deleted 15y ago
[deleted]