Dropbox Lack of Security(tirania.org)
tirania.org
Dropbox Lack of Security
http://tirania.org/blog/archive/2011/Apr-19.html
24 comments
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 easily be paralyzing for many businesses. There are already services (like Tarsnap) which are engineered to not require you to trust them; why should we ignore such services and limit ourselves to doing business only with those companies that we can trust implicitly?
As a specific example, I've had a client for a few years which is government funded and quite paranoid about security. However, they also need to communicate with outside contractors. I don't advise them to "trust" their ISP, the outside contractors' network, and all the other businesses in-between. I tell them that nothing sensitive leaves the building unless it's been encrypted, and that once someone else opens that file, it can no longer be considered secure in any sense.
"Trust us" is not a compelling requirement for doing business, nor can businesses limit themselves only to relying on service providers that they trust. Fortunately, the technology exists now to eliminate that requirement.
Dropbox is currently off-limits to all employees at my client.
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 easily be paralyzing for many businesses. There are already services (like Tarsnap) which are engineered to not require you to trust them; why should we ignore such services and limit ourselves to doing business only with those companies that we can trust implicitly?
As a specific example, I've had a client for a few years which is government funded and quite paranoid about security. However, they also need to communicate with outside contractors. I don't advise them to "trust" their ISP, the outside contractors' network, and all the other businesses in-between. I tell them that nothing sensitive leaves the building unless it's been encrypted, and that once someone else opens that file, it can no longer be considered secure in any sense.
"Trust us" is not a compelling requirement for doing business, nor can businesses limit themselves only to relying on service providers that they trust. Fortunately, the technology exists now to eliminate that requirement.
Dropbox is currently off-limits to all employees at my client.
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
Sounds like the host_id is the secret key. So to paraphrase: "If you type someone's username & password into the facebook login page, you get complete access to their account"
Sounds like the host_id is the secret key. So to paraphrase: "If you type someone's username & password into the facebook login page, you get complete access to their account"
The difference being that you can change your facebook password. It's not that easy with dropbox.
It's just as easy to de-authorize devices (and hence invalidate host IDs) on Dropbox as is is to change your Facebook password.
If you dupe someone's Dropbox host ID, they'll only see the one entry on their page, so it's quite likely they would not be aware that they've been "duped".
To dupe the key they would need access to your system, though. At which point they would also have access to all your files anyway.
Now, if you fix your system to no longer be vulnerable the duped key will allow them to keep snooping your files, but personally I think this risk is marginal.
Now, if you fix your system to no longer be vulnerable the duped key will allow them to keep snooping your files, but personally I think this risk is marginal.
I think this risk is marginal.
No, this risk is most certainly not marginal.
There is a difference between someone stealing a snapshot of your data, and someone gaining permanent, undetectable access to your data.
It's also about attack scenarios;
With an USB stick crafted for this purpose I could steal your credentials in under 10 seconds, while you're on the toilet and forgot to enable your screensaver. Locating and downloading the actual data would take much longer, planting a trojan for later would be much more difficult and unreliable.
No, this risk is most certainly not marginal.
There is a difference between someone stealing a snapshot of your data, and someone gaining permanent, undetectable access to your data.
It's also about attack scenarios;
With an USB stick crafted for this purpose I could steal your credentials in under 10 seconds, while you're on the toilet and forgot to enable your screensaver. Locating and downloading the actual data would take much longer, planting a trojan for later would be much more difficult and unreliable.
Whether or not the risk is marginal depends on the circumstances of the user. I there's probably a time and an place for this security model, though I don't see myself using it.
I see two key questions:
* Has the security model has been properly implemented?
* Have its properties have been communicated to the users of the system in a clear enough way that people can evaluate how the risks apply to them?
I don't know about the first question, but on the second they could certainly stand some improvement.
I see two key questions:
* Has the security model has been properly implemented?
* Have its properties have been communicated to the users of the system in a clear enough way that people can evaluate how the risks apply to them?
I don't know about the first question, but on the second they could certainly stand some improvement.
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.
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...
If this violates their ToS, they need to rethink their policies. There a ton of reason you might have an encrypted file in your dropbox. Like sharing it with a friend or holding it there because you are moving files around etc.
That's a severe oversimplification
You mean patio11 used oversimplification, folksy language, and cutesy examples to make a point? Say it ain't so!
You mean patio11 used oversimplification, folksy language, and cutesy examples to make a point? Say it ain't so!
I think you're missing the point. On their website it says "Dropbox employees aren't able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents)" and in their terms of service they say that they will turn over files to a government agency if subpoenaed.
The problem isn't security theater, it's the fact that both of the above can't be true at the same time. In other words: Dropbox lied.
The problem isn't security theater, it's the fact that both of the above can't be true at the same time. In other words: Dropbox lied.
I would be cautious in making the conclusions. Technically, it's quite trivial to implement precisely what you say is impossible.
How: give the private key of an RSA keypair to US Govt; use the public key of that keypair on the clientside to encrypt the key that is used for the symmetric encryption of the contents of the file.
The employee on the other end will be able to see the metadata, but he will not be able to access the contents.
The authorized government agent, on the other hand, would be able to read the file - he will have to subpoena dropbox to get the encrypted file data, and RSA-encrypted bulk encryption key, which they decrypt on their side.
What do you think ?
(As for my 2 cents on the story - someone claiming to be concerned with security who is not performing their own encryption of the data using the standard algorithms, tools and processes needs to rethink how concerned they are really).
How: give the private key of an RSA keypair to US Govt; use the public key of that keypair on the clientside to encrypt the key that is used for the symmetric encryption of the contents of the file.
The employee on the other end will be able to see the metadata, but he will not be able to access the contents.
The authorized government agent, on the other hand, would be able to read the file - he will have to subpoena dropbox to get the encrypted file data, and RSA-encrypted bulk encryption key, which they decrypt on their side.
What do you think ?
(As for my 2 cents on the story - someone claiming to be concerned with security who is not performing their own encryption of the data using the standard algorithms, tools and processes needs to rethink how concerned they are really).
Yes, I think this is exactly right. The key can be in some sort of 'escrow' where it is not accessible to DropBox employees, but accessible to the government upon subpoena.
It could be even simpler: Dropbox's admin interfaces for employees may simply not reveal data that could technically be revealed.
When I started my own law practice, my partners insisted that "everything must be encrypted" so that no third parties would have access to see any files. I had a feeling my partners were parroting this requirement and didn't really understand how security works. I tried to explain the pros and cons of this approach, but my warnings fell on deaf ears; the requirement was absolutely total encryption of all file data so that no third party could even theoretically peek at our data.
So, I set up JungleDisk backups to S3 with a key that only I knew about. This was an awesome solution that cost a few bucks per user per month.
Not long afterward, one of my partners insisted on having his home PC and his laptop synced. At the time, JungleDisk didn't offer syncing.
Sure enough, a few weeks later, I find out that the same guy who insisted I encrypt everything was secretly using Dropbox to sync his files. (I won't even get into the fact that he was backing up his sync folder to my JD solution!)
In summary, idiots are idiots, and security is often misunderstood.
By the way, I'm no longer working with people who fail to understand security, and we've got what I suspect are the most innovative, cost-effective and secure backups at any law firm in the world.
When I started my own law practice, my partners insisted that "everything must be encrypted" so that no third parties would have access to see any files. I had a feeling my partners were parroting this requirement and didn't really understand how security works. I tried to explain the pros and cons of this approach, but my warnings fell on deaf ears; the requirement was absolutely total encryption of all file data so that no third party could even theoretically peek at our data.
So, I set up JungleDisk backups to S3 with a key that only I knew about. This was an awesome solution that cost a few bucks per user per month.
Not long afterward, one of my partners insisted on having his home PC and his laptop synced. At the time, JungleDisk didn't offer syncing.
Sure enough, a few weeks later, I find out that the same guy who insisted I encrypt everything was secretly using Dropbox to sync his files. (I won't even get into the fact that he was backing up his sync folder to my JD solution!)
In summary, idiots are idiots, and security is often misunderstood.
By the way, I'm no longer working with people who fail to understand security, and we've got what I suspect are the most innovative, cost-effective and secure backups at any law firm in the world.
"Dropbox's admin interfaces for employees may simply not reveal data that could technically be revealed"
This is not the same as "is not accessible to employees". Interfaces are just that. There are quite a few very sharp developers at Dropbox if reputations are to be believed. I don't think an interface is a sufficient control.
This is not the same as "is not accessible to employees". Interfaces are just that. There are quite a few very sharp developers at Dropbox if reputations are to be believed. I don't think an interface is a sufficient control.
Sharp developers != sharp developers who understand how to properly implement security into product.
I think it's been shown multiple times that smarts devs that do not do security all the time still are susceptible to making mistakes about security. IMO, this is one of those cases.
Miguel is right in calling for an audit but even better, Dropbox could just ask for help. I'm sure any number of savvy HN peeps would be happy to help.
I think it's been shown multiple times that smarts devs that do not do security all the time still are susceptible to making mistakes about security. IMO, this is one of those cases.
Miguel is right in calling for an audit but even better, Dropbox could just ask for help. I'm sure any number of savvy HN peeps would be happy to help.
I fully understand your point, but those words could be interpreted either way.
Only Dropbox can confirm whether it is theoretically possible for Dropbox engineers to peek at user data.
Only Dropbox can confirm whether it is theoretically possible for Dropbox engineers to peek at user data.
Dropbox keeps your encryption key somewhere. They say that (a) the files stored with them are encrypted and (b) you don't have the decryption key. Conclusion: they have your plain-text key. Thus it is theoretically possible. I take their statement that their employees cannot view your files as "their employees are not allowed to view your files" with some basic precautions surrounding this. However, whoever wrote the code for revealing the plain-text key to the server when you request a file should be smart enough to figure out how to fake being that server.
Right, so "...is not accessible to employees" is very misleading and arguably incorrect.
I might have misunderstood what you meant, but #1 is invalid.
If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream.
Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key.
Your killer argument is to me #3. If you don't trust a company, don't do business with it. It all comes down to this.
If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream.
Giving access to my data to someone else would therefore just be a question of sharing the key with that person, again, without Dropbox ever having access to this key.
Your killer argument is to me #3. If you don't trust a company, don't do business with it. It all comes down to this.
One of the reasons Dropbox is successful is because anyone can use it. Even your mother. In fact, one of the reasons Drew was originally accepted into the YC program was because his sister was using it when he applied.
"If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream."
In order for the data to be encrypted securely, you would need to generate a key on your own computer which Dropbox then uses to perform the encryption. (Tarsnap works this way.)
Forcing Drew's sister (or your mother) to generate a key would be bad for accessibility.
"If I can look at my data any time I want, I just need the key to it. Dropbox just gives me access to the encrypted stream."
In order for the data to be encrypted securely, you would need to generate a key on your own computer which Dropbox then uses to perform the encryption. (Tarsnap works this way.)
Forcing Drew's sister (or your mother) to generate a key would be bad for accessibility.
Funny, when I visit my mom I use her computer for emergency bug fixes and I have my Dropbox installed on her computer. Every now and then I'll see a notification about a document being added to my DB so I checked and it turns out she's saving her documents there cause she "likes the name of the folder".
So yeah, mom's can definitely use it.
So yeah, mom's can definitely use it.
The authentication token can be generated and managed by the software. It would then be protected by the account password, if any (Windows and MacOS X offer this feature).
Doable, and even better, you can make that a 30 € / month corporate option. ;)
Doable, and even better, you can make that a 30 € / month corporate option. ;)
If the key file is stored on Dropbox servers, then Dropbox has access to all of your files. This defeats the original purpose (security).
If the key file is not stored on Dropbox servers, then you can't easily use Dropbox across several different computers. This defeats the other purpose (accessibility).
If the key file is not stored on Dropbox servers, then you can't easily use Dropbox across several different computers. This defeats the other purpose (accessibility).
You can store a key escrow on the dropbox server protected by a password or a token. Just a matter of designing something secure and useable. Not easy, but possible.
That doesn't work, Dropbox/your favourite TLA will just wait for you to supply the password and then save the key. Trading off the inconveniences of good crypto (e.g. no web interface) for that little security isn't worth it.
The system suggested by shin_lao does not require that the password be passed back to Dropbox to retrieve the key.
If Dropbox wants to serve the files to a standard browser, it does need the decryption key. If I misunderstood and shin_loa wants to drop the web interface, why "key escrow" - why not directly derive the key from the passphrase?
When you forget your password you'll lose access to all of your data. Password recovery won't be possible if the key is password protected.
Isn't one of the major cool things about dropbox that if your computer hard drive gets smashed (and thus the key is destroyed), you can still access your files somewhere else?
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.
The cloud is a scary place. Making it easy to use is not necessarily a good thing.
De-duplication is not really the topic of this discussion, is it?
Tarsnap provides exactly the sort of service you're referring to, where they only store encrypted data and don't have a copy of the key.
I'm a big fan of that architecture, if only because it greatly reduces the payoff of a successful attack. When everything is stored unencrypted (or with a common master key), there's an absolutely massive payoff for the hacker who breaches the security.
I'm a big fan of that architecture, if only because it greatly reduces the payoff of a successful attack. When everything is stored unencrypted (or with a common master key), there's an absolutely massive payoff for the hacker who breaches the security.
Tarsnap is great and its author knows what he's doing but dropbox is many UA ahead in terms of useability and platform interoperability.
Dropbox is incredibly easy to use, that's where its power comes from. It's "secure enough" for casual use.
Additionally I believe you can't share data between users with tarsnap.
There is a market opportunity for a corporate-level secure data exchange infrastructure.
Dropbox is incredibly easy to use, that's where its power comes from. It's "secure enough" for casual use.
Additionally I believe you can't share data between users with tarsnap.
There is a market opportunity for a corporate-level secure data exchange infrastructure.
> dropbox is many UA ahead in terms of useability and platform interoperability
That's besides the point. Tarsnap is more than useable enough for its target audience, which is why cperciva (rightfully) doesn't give a rat's ass about making it as user-friendly as Dropbox and its ilk.
The two issues are completely separate. Implementation of client-side encryption and user-friendliness are not mutually exclusive. Tarsnap is simply proof that client-side encryption is entirely within the realm of possibility for cloud-based data storage services.
That's besides the point. Tarsnap is more than useable enough for its target audience, which is why cperciva (rightfully) doesn't give a rat's ass about making it as user-friendly as Dropbox and its ilk.
The two issues are completely separate. Implementation of client-side encryption and user-friendliness are not mutually exclusive. Tarsnap is simply proof that client-side encryption is entirely within the realm of possibility for cloud-based data storage services.
Dropbox+ecryptfs is pretty usable, too.
Tahoe-LAFS provides a storage service that is encrypted by the client, but the original uploader of the data is still able to delegate read-only or read-write access to others on a per-file or per-directory basis.
The overall design, including how it is possible to do secure delegation, is fairly well described in a paper from the 'Storage Security and Survivability 2008' workshop - http://tahoe-lafs.org/~zooko/lafs.pdf
The overall design, including how it is possible to do secure delegation, is fairly well described in a paper from the 'Storage Security and Survivability 2008' workshop - http://tahoe-lafs.org/~zooko/lafs.pdf
Have fun decrypting AES in Javascript, and downloading the file through your browser. (edit: on your cell phone...)
Hint: downloading client-side generated files is not possible without assistance from Flash.
Downloading client-side generated files is possible using data-uri. However these are usually small; it would be very difficult to store a 1GB file in memory (in javascript) while you decrypted it and I doubt data-uris that large work across different browsers.
True, but there's no way to specify the filename and extension, so in practice you have to use Flash.
It depends on the browser. Safari 5 works, but Chrome doesn't, not sure about Firefox, and I suspect IE doesn't.
I use it on my torrent-conversion bookmarklet on http://hid.im.
I use it on my torrent-conversion bookmarklet on http://hid.im.
Not quite true: http://jszip.stuartk.co.uk/
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.
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.
#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 this way.
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 your browsing session. Your password is only stored only in encrypted memory (and never written to an unencrypted disk) and is destroyed when your browsing session ends."
Seems pretty cool. I might have to check them out.
"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 your browsing session. Your password is only stored only in encrypted memory (and never written to an unencrypted disk) and is destroyed when your browsing session ends."
Seems pretty cool. I might have to check them out.
> "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.
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.
I don't think that is what he is asking for. I took that he said 'Dropbox lied on this point, why should we believe them on others'
As others said, #1 is false. You can look at your data whenever you want without letting others do the same, even if they have access to the data. That's what asymmetric (or even symmetric) cryptography does.
Apart from that, did anyone ever think Dropbox was completely secure? The mere fact that they perform deduplication, which is not possible if they can't read your data, should have tipped people off to it. Not to mention showing the files in the web client, sharing, etc.
Apart from that, did anyone ever think Dropbox was completely secure? The mere fact that they perform deduplication, which is not possible if they can't read your data, should have tipped people off to it. Not to mention showing the files in the web client, sharing, etc.
> The mere fact that they perform deduplication, which is not possible if they can't read your data
It is possible because it's client-server. When a new file appears in the Dropbox folder, the Dropbox client calculates a hash of it and checks if that hash already exists with Dropbox's server-side storage. If not, then the file is uploaded and stored encrypted. You do have to trust that the Dropbox client is actually doing what it claims to do, that it isn't uploading with no or trivial encryption (like an xor or something.)
It is possible because it's client-server. When a new file appears in the Dropbox folder, the Dropbox client calculates a hash of it and checks if that hash already exists with Dropbox's server-side storage. If not, then the file is uploaded and stored encrypted. You do have to trust that the Dropbox client is actually doing what it claims to do, that it isn't uploading with no or trivial encryption (like an xor or something.)
And what happens when the file that matches the hash isn't yours?
I don't use Dropbox so I recently learned that they performed data deduplication. For me this is still a breaking story.
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 can tell nobody's created such a service so far. All the tools are there, with the exception of maybe some novel way to facilitate key transfers from my desktop to my laptop to my phone.
Dropbox offers some level of security: if they leak your raw files, it'll be damn hard to unencrypt them. On the other hand, how does it prevent people who work for them from snooping on you?
The only way I found to deal with this so far, is to rent your own servers and copy the keys only when two computers are physically connected together.
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 can tell nobody's created such a service so far. All the tools are there, with the exception of maybe some novel way to facilitate key transfers from my desktop to my laptop to my phone.
Dropbox offers some level of security: if they leak your raw files, it'll be damn hard to unencrypt them. On the other hand, how does it prevent people who work for them from snooping on you?
The only way I found to deal with this so far, is to rent your own servers and copy the keys only when two computers are physically connected together.
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.
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.
All he's really asking for is for Dropbox to explain their security in ways that don't overpromise what they actually deliver. If they want to live up to their promise, then he's suggesting a way to do that.
Ultimately it all boils down to admin's or developer's conscience. If he wants to check the data out, he will.
Why all the argument? Why not just provide encryption that would make it so that all files are encrypted and decrypted so that all users' files are completely protected?
Straw man.
hi there, arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend.
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
What about allowing government access to files? Do you require a warrant?
Under what circumstances?
Under what circumstances?
we take as firm as stance as possible on user privacy (google faces and fights these very issues)
the government needs to comply with the provisions of the electronic communications privacy act by obtaining a warrant supported by probable cause (or in some cases a court order from a judge). these safeguards protect user privacy, even when the government is involved.
the government needs to comply with the provisions of the electronic communications privacy act by obtaining a warrant supported by probable cause (or in some cases a court order from a judge). these safeguards protect user privacy, even when the government is involved.
Yes, but under the Stored Communications Act (18 U.S.C. 2703), no warrant is needed to obtain communications stored longer than 180 days.
This is why encryption of data in the cloud, where the keys are not held by the provider, is essential.
This is why encryption of data in the cloud, where the keys are not held by the provider, is essential.
Assuming you store files as a combination of a hash digest function as a key and file data as a value; what controls do you have in place to handle situations where law enforcement discovers some sort of 'illegal' file data on one users account subsequently requests details on users with hash digests that match the data in that file?
de-duplication doesn't make users any more vulnerable to intrusive government actions. today, a government agency could ask any online service to provide the names of all users who have a particular file, whether or not the service employs de-duplication. and in that case, the government would also need to support its request with a warrant or court order. the rules that provide a check against unwarranted government snooping apply to online services equally, regardless of their backend architecture.
To parse that, are you saying that under such a circumstance, a government agency would have to provide the names of each person they suspect have that particular file? Or could they demand the names of all users that have a particular digest of that file?
basically, the government could try to make that type of request independent of backend implementation. what protects users against such an obtrusive action (effectively violating every user's privacy in search of the bad guys) are the provisions of the electronic communications privacy act.
Due to Dropbox's implementation of de-duplication of identical files, any user can (in theory) determine whether (but not who) some other user is storing the same file. If you upload a file that any other user has aleady uploaded, your file transfer will be nearly instantaneous.
See: "How Dropbox sacrifices user privacy for cost savings"
http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u...
See: "How Dropbox sacrifices user privacy for cost savings"
http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u...
What's the ETA for detailed security architecture whitepaper?
"(A)ll data is encrypted before it's stored on the backend" statement is completely worthless unless (at the very least) you also describe how the keys are generated and managed.
"(A)ll data is encrypted before it's stored on the backend" statement is completely worthless unless (at the very least) you also describe how the keys are generated and managed.
[deleted]
Technically speaking, whats the point of encrypting data on the backend if you can decrypt it? This strikes me as a waste of computations for no real gain.
Someone in an Amazon datacenter that gets ahold of a random backup tape/hard drive can't read it. I'm not sure if Dropbox is hosted on EC2, but if not, it means that Amazon couldn't read the data at all. (If it's hosted on EC2, Amazon could probably get ahold of the key if they really wanted to)
Going off of that assumption, what if the decryption keys were also stored in an Amazon data center? It is then possible for Amazon read the contents of these files.
I'd like to hear from Dropbox how this works instead of speculation.
I'd like to hear from Dropbox how this works instead of speculation.
[deleted]
If their storage API is compromised your data isn't... you need to compromise their decryption API and the storage API.
With luck the same sets of staff will not have access to both, et cetera.
With luck the same sets of staff will not have access to both, et cetera.
Everything on your website that in any way addresses "Dropbox's security" should make absolutely clear the extent to which users can expect their data to be "secure".
In Dropbox's case, users can expect the following:
It matters little whether "Drew has physical access to our storage servers anymore". Your code obviously has easy access to the keys used to encrypt and decrypt the data. This means all of the following scenarios are possible:
In Dropbox's case, users can expect the following:
- Data is probably secure from sniffers
It matters little whether "Drew has physical access to our storage servers anymore". Your code obviously has easy access to the keys used to encrypt and decrypt the data. This means all of the following scenarios are possible:
- User's data is obtained via the government (users
aren't necessarily even informed about this)
- User's data is obtained by rouge employee (potentially
leaking to _anyone_ or _anything_)
- User's data is obtained by hacker (again, implies ZERO
assurance of data security).
you're right in that all these things are theoretically possible in a system where the encryption key is not stored client-side. I don't know of many services that advertise every way in which their systems could be compromised. I think you'd be hard pressed to find a company doing this. in the case of google - is there a document explaining all the places your email could end up?
we believe that what we advertise is in our userbase's best interest. in theory, we could generate a lengthy document attempting to explain every possible way dropbox could be compromised. but in practice, discussing these extremely unlikely theoretical vulnerabilities would generate undue fear. as an ironic sidenote: this thread was spawned by an attempt we made to clarify our handling of court orders (see: http://www.businessinsider.com/dropbox-updates-security-term... )
I say "undue fear" for a couple reasons. first and foremost because we are vigilant about making sure that user data is never compromised. our reputation would be permanently damaged if dropbox is compromised. we have a lot of smart, security conscious people making sure data in dropbox is safe.
we're also listening to feedback we've been hearing from the community on things we can do to improve security. a couple concrete examples: we're working on better protecting the authentication token (config.db) so that gaining access to a dropbox account on a compromised machine is much more difficult. similarly we're working on a performant way to transmit file metadata over SSL on the mobile apps.
secondly, we believe that storing data in dropbox is far more safe than the alternatives. we've designed dropbox to protect user data against threats of all kinds, but we've focused the most on helping users avoid the most common threats to their data: not having any backups at all, not having current backups, accidentally deleting files, losing hours of work, leaving files on the wrong computer, losing a USB drive with sensitive info, protecting from curious snoopers on the dorm network, etc.
for all the talk of security issues in the last few weeks, we're not aware of anybody having been affected by these theoretical vulnerabilities. on the flip side, we have (literally) saved thousands of college kids from losing their theses :-).
we believe that what we advertise is in our userbase's best interest. in theory, we could generate a lengthy document attempting to explain every possible way dropbox could be compromised. but in practice, discussing these extremely unlikely theoretical vulnerabilities would generate undue fear. as an ironic sidenote: this thread was spawned by an attempt we made to clarify our handling of court orders (see: http://www.businessinsider.com/dropbox-updates-security-term... )
I say "undue fear" for a couple reasons. first and foremost because we are vigilant about making sure that user data is never compromised. our reputation would be permanently damaged if dropbox is compromised. we have a lot of smart, security conscious people making sure data in dropbox is safe.
we're also listening to feedback we've been hearing from the community on things we can do to improve security. a couple concrete examples: we're working on better protecting the authentication token (config.db) so that gaining access to a dropbox account on a compromised machine is much more difficult. similarly we're working on a performant way to transmit file metadata over SSL on the mobile apps.
secondly, we believe that storing data in dropbox is far more safe than the alternatives. we've designed dropbox to protect user data against threats of all kinds, but we've focused the most on helping users avoid the most common threats to their data: not having any backups at all, not having current backups, accidentally deleting files, losing hours of work, leaving files on the wrong computer, losing a USB drive with sensitive info, protecting from curious snoopers on the dorm network, etc.
for all the talk of security issues in the last few weeks, we're not aware of anybody having been affected by these theoretical vulnerabilities. on the flip side, we have (literally) saved thousands of college kids from losing their theses :-).
Arash good security is about mitigating theoretical risks before they become actual.
I am most disappointed in Dropbox because you had made statements like all our data is AES encrypted and our staff do not have access to your data. These are clearly incomplete for the former and are plainly not true for the latter. They are misleading and un-ethical in that they have assisted you in gaining you all these customers. As stated above you should clearly stop using security as selling point and only state you provide security in transit (https) or actually put in place technical measures to make those statements true.
Personally I will no longer be recommending Dropbox and will instead recommend your competitors including changing my answers on Quora: http://www.quora.com/Dropbox?q=dropbox
I am most disappointed in Dropbox because you had made statements like all our data is AES encrypted and our staff do not have access to your data. These are clearly incomplete for the former and are plainly not true for the latter. They are misleading and un-ethical in that they have assisted you in gaining you all these customers. As stated above you should clearly stop using security as selling point and only state you provide security in transit (https) or actually put in place technical measures to make those statements true.
Personally I will no longer be recommending Dropbox and will instead recommend your competitors including changing my answers on Quora: http://www.quora.com/Dropbox?q=dropbox
Really, dropbox is probably more secure than most complainers' computers; but when you say things like
- All transmission of file data occurs over an encrypted channel (SSL).
- All files stored on Dropbox servers are encrypted (AES-256)
This is a discussion of the consistency of advertised security claims with disclosures about availability of data to government subpoena.
In that context, statements like "we believe that what we advertise is in our userbase's best interest" make my ears prick up. I'm not a crypto expert, but this sort of thing does not seem like a straightforward response to the OP.
In that context, statements like "we believe that what we advertise is in our userbase's best interest" make my ears prick up. I'm not a crypto expert, but this sort of thing does not seem like a straightforward response to the OP.
The point is that these are the kinds of claims you should be making in the marketing. Users are smart enough to understand "We are vigilant about making sure that user data is never compromised". You shouldn't be trying to bamboozle them with official-sounding acronyms like AES - that when it comes down to it, mean little.
There are classes of users who will consider it snake oil if well-known encryption algorithm names aren't used, because it implies home-grown encryption.
"Our reputation would be permanently damaged if dropbox is compromised."
This is why I trust DropBox with my data: because I'm a paying customer. That means our goals are aligned.
This is why I trust DropBox with my data: because I'm a paying customer. That means our goals are aligned.
But you are not Google, and I expect you to have higher standards. Don't take Google as the reference data point, it's a fairly low one as far as reference data points go.
On a related note, Dropbox is not the only company that advertises security even though what really is offered is kind-of-security. See Backblaze, for example — yes, the data is (supposedly) encrypted using my private key, which (supposedly) only stays on my machine, but I can't be sure because it isn't auditable, and to do a restore I have to supply my private key to the Backblaze website, instead of using a local decryption tool. Not good.
On a related note, Dropbox is not the only company that advertises security even though what really is offered is kind-of-security. See Backblaze, for example — yes, the data is (supposedly) encrypted using my private key, which (supposedly) only stays on my machine, but I can't be sure because it isn't auditable, and to do a restore I have to supply my private key to the Backblaze website, instead of using a local decryption tool. Not good.
>we're not aware of anybody having been affected by these theoretical vulnerabilities. on the flip side, we have (literally) saved thousands of college kids from losing their theses
I like the idea of what your service does, but this statement just advertizes the success of one feature to back up the failings of another.
If you just want to offer file storage, just set up an http-only svn server and be done with it.
If you want to offer proper encryption, do so, or don't say that you do.
I like the idea of what your service does, but this statement just advertizes the success of one feature to back up the failings of another.
If you just want to offer file storage, just set up an http-only svn server and be done with it.
If you want to offer proper encryption, do so, or don't say that you do.
[deleted]
Wait, Truecrypt? Haven't I seen warnings in the Truecrypt docs against keeping several copies of the same file? And doesn't Dropbox backup every little change? You might want to add a note on your security page that storing encrypted files on a service with automated backups, like Dropbox, may pose security risks.
Really? That'd be amazingly broken - consider any of the append-only log-structured filesystems currently in vogue on Linux, which are very likely to preserve multiple versions of any file being stored (right?). Not to mention normal backups.
How does the second part follow from the first? What is the 'security risk'?
A point of feedback: I know it is illegal for you to inform users if you have received a warrant for their data, but you should devise a method where a flag such as 'third party access' is set in the user preference panel to let them know that somebody has accessed the data
architect this flag as part of any 'admin' access and describe it on your website - users would feel better about it
if the feds know your system is designed in a way that you can't help but to inform users that data has been accessed, it might dissuade them from approaching you with warrants in the first place
architect this flag as part of any 'admin' access and describe it on your website - users would feel better about it
if the feds know your system is designed in a way that you can't help but to inform users that data has been accessed, it might dissuade them from approaching you with warrants in the first place
Interesting technical idea, but it ignores how power works.
The govt will just request that they change the code so that you're in compliance.
The govt will just request that they change the code so that you're in compliance.
I poured through the laws and talked to a lawyer about it, though this was years ago. It is illegal to inform a user directly in any way, they can't make you re-architect your system to provide them a backdoor unknown to the user.
also the wording can not mention 'warrant' or 'fbi' so it has to be something like 'third party access'
I have been meaning to do this as a 'project' with full legal advice etc. and suggest it to google, other cloud providers
Edit: found that rsync.net already do this, in a different way, as a warrant canary: http://www.rsync.net/resources/notices/canary.txt
also the wording can not mention 'warrant' or 'fbi' so it has to be something like 'third party access'
I have been meaning to do this as a 'project' with full legal advice etc. and suggest it to google, other cloud providers
Edit: found that rsync.net already do this, in a different way, as a warrant canary: http://www.rsync.net/resources/notices/canary.txt
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/
You could have client side javascript that decrypts the files. http://crypto.stanford.edu/sjcl/
You're getting (maybe unfairly) downvoted because the popular opinion in security is that client-side JavaScript anything is worthless in terms of security. Since it's not authenticated in any way by the browser, any successful MITM attack on a connection can feed malicious JavaScript which would request the user's key. Or, a malicious add-on in the browser could do the same. Or, possibly, an XSRF.
I'm somewhat skeptical of this because I think that such attacks can be successfully mounted against most other web-related activities. DNS poisoning and self-signed SSL would be enough to phish many people's bank login credentials, and a lot of attacks don't even go to that much trouble.
But, anyway, client-side JavaScript for security purposes is supposed to be verboten.
I'm somewhat skeptical of this because I think that such attacks can be successfully mounted against most other web-related activities. DNS poisoning and self-signed SSL would be enough to phish many people's bank login credentials, and a lot of attacks don't even go to that much trouble.
But, anyway, client-side JavaScript for security purposes is supposed to be verboten.
The number of people who will find an attack in the middle of a ton of Javascript is much smaller than the number of people who properly handle a certificate warning.
Thanks for the information. I didn't realize that it is verboten. I presumed it was for efficiency purposes and implementation hassles. I do realize that there are plenty of attack vectors the moment you start trusting JS from a remote website.
It was just a proof-of-concept of how Dropbox can still allow you to view files in your browser, but perhaps flash a big warning saying that this is a lot weaker security-wise than locally running your dropbox client. That way they cater to people who are willing to forego a little security for convenience.
It was just a proof-of-concept of how Dropbox can still allow you to view files in your browser, but perhaps flash a big warning saying that this is a lot weaker security-wise than locally running your dropbox client. That way they cater to people who are willing to forego a little security for convenience.
And where would the decryption keys come from?
You generate the key from your username and password and/or store it locally?
function decrypt(cipertext, key) {
var req = new XMLHttpRequest();
req.open("POST", "/retrieve_user_key?key="+key);
req.send();
// decryption routines
return result;
}
Of course you also need to trust the desktop Dropbox client. The only (approximately) truly secure way to do this is with an open source client you can inspect and compile yourself (i.e. tarsnap).
> Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place?
I was thinking about the subpoena situation, when the Govt. demands Dropbox to hand over keys. I presume DropBox can definitely send compromised JS or even a malicious client. This is very reminiscent of the whole notion of trusting trust! http://en.wikipedia.org/wiki/Backdoor_(computing)#Reflection...
I was thinking about the subpoena situation, when the Govt. demands Dropbox to hand over keys. I presume DropBox can definitely send compromised JS or even a malicious client. This is very reminiscent of the whole notion of trusting trust! http://en.wikipedia.org/wiki/Backdoor_(computing)#Reflection...
> Do you trust Dropbox to not send compromised JavaScript every time? If so, why not trust them with your keys in the first place?
I don't trust Dropbox to do either of these things, but at least in theory I can examine the JavaScript each time they send it to me, whereas there is no way for me to inspect Dropbox's internal operations to make sure they aren't misusing my key.
The problem becomes mechanically verifying that a received chunk of client-side JavaScript is indeed the decryption routine that it claims to be. I think this is a solvable problem.
I don't trust Dropbox to do either of these things, but at least in theory I can examine the JavaScript each time they send it to me, whereas there is no way for me to inspect Dropbox's internal operations to make sure they aren't misusing my key.
The problem becomes mechanically verifying that a received chunk of client-side JavaScript is indeed the decryption routine that it claims to be. I think this is a solvable problem.
Actually, checking that two pieces of code are equivalent is undecideable:
http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_...
So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.
http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_...
So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.
True. However, we don't need to be able to compare two arbitrary chunks of code. As long as our algorithm provides no false positives, I would settle for something as simple as a checksum.
Reminds me of the Underhanded C Contest, the goal is write a C programme that appears innocent when someone examines the source code, but actually has an intentional malicous action (e.g. stores user data)
Hashing your passphrase a million times just most other decryption keys.
I don't care. I use Dropbox because of the unparalleled feature set and ease of integration. I have my taxes stored on Dropbox, along with a lot of other sensitive information. They're in an encrypted RAR file with a line-noise passphrase, just like they would be if I were storing them anywhere (including locally -- after all, what if Mallory steals your hard drive? Or, to parrot the most common movie plot threat, what if the NSA secretly breaks into your house when you're out at the movies and images all your disks then slips them back in without your knowledge?)
The features DB offers for sharing, web access, etc. are well worth the tradeoff, and I am ashamed to see the security pedants constantly pillorying Dropbox because it's not some imaginary "verified secure" system. They don't advertise to be that. A claim of "we encrypt your files with RSA" should be utterly meaningless to you without knowledge of how the key is controlled, and a few seconds' thought and examination of the feature set should inform you that yes, Dropbox has to have the key to decrypt the files. That doesn't make the claim of "your files are encrypted" any less true.
The features DB offers for sharing, web access, etc. are well worth the tradeoff, and I am ashamed to see the security pedants constantly pillorying Dropbox because it's not some imaginary "verified secure" system. They don't advertise to be that. A claim of "we encrypt your files with RSA" should be utterly meaningless to you without knowledge of how the key is controlled, and a few seconds' thought and examination of the feature set should inform you that yes, Dropbox has to have the key to decrypt the files. That doesn't make the claim of "your files are encrypted" any less true.
You should consider using something like truecrypt rather than rar encryption.
http://www.truecrypt.org/
http://www.truecrypt.org/
>
paying Dropbox customer here, I wouldn't call the features "unparalleled". SugarSync offers more, and for slightly less: https://www.sugarsync.com/sync_comparison.html
...or so I'm assuming. I never tried it because last time I checked they require a credit card for a free trial.
paying Dropbox customer here, I wouldn't call the features "unparalleled". SugarSync offers more, and for slightly less: https://www.sugarsync.com/sync_comparison.html
...or so I'm assuming. I never tried it because last time I checked they require a credit card for a free trial.
Seems like you can get a free 5g account without CC here:
https://www.sugarsync.com/signup?startsub=5
https://www.sugarsync.com/signup?startsub=5
Do a lot of people think that Dropbox is some sort of super-private service?
I'm no security expert, but do I hope it's obvious to most people that Dropbox wouldn't be able to do stuff like reset your password if they didn't have access to the contents of your files at some level. A truly secure and private service would look a lot different, and be much more complicated to set up. That's the tradeoff.
I'm no security expert, but do I hope it's obvious to most people that Dropbox wouldn't be able to do stuff like reset your password if they didn't have access to the contents of your files at some level. A truly secure and private service would look a lot different, and be much more complicated to set up. That's the tradeoff.
>I hope it's obvious to most people that Dropbox wouldn't be able to do stuff like reset your password if they didn't have access to the contents of your files at some level
Those are pretty damn high hopes even for the average user from the generation that grew up with computers.
Those are pretty damn high hopes even for the average user from the generation that grew up with computers.
Three points:
1. Sensationalism aside, Dropbox should review questionable security claims to reduce false sense of security if any. With millions of users, careless words formed out of marketing needs are no longer needed. What Dropbox users need now is more clear picture of what they are giving up to gain Dropbox's services.
2. The weakest security link is the user and their computer, not Dropbox which has enough financial incentives at stake to be diligent security wise. In the end, no computer open to external data or code is safe. What protect most users today is actually not security technologies but cost/benefit ratio to potential attackers, tempered by goal and scale. 99.9999% of Dropbox user data is useless to attackers and cost of mining questionable nuggets out continually expanding sea of data from 20 million users is not a trivial task.
3. While it's true that user must trust Dropbox in the end, some of its security measures could use strengthening even if it's just intended to raise the level of sophistication necessary to steal Dropbox data.
1. Sensationalism aside, Dropbox should review questionable security claims to reduce false sense of security if any. With millions of users, careless words formed out of marketing needs are no longer needed. What Dropbox users need now is more clear picture of what they are giving up to gain Dropbox's services.
2. The weakest security link is the user and their computer, not Dropbox which has enough financial incentives at stake to be diligent security wise. In the end, no computer open to external data or code is safe. What protect most users today is actually not security technologies but cost/benefit ratio to potential attackers, tempered by goal and scale. 99.9999% of Dropbox user data is useless to attackers and cost of mining questionable nuggets out continually expanding sea of data from 20 million users is not a trivial task.
3. While it's true that user must trust Dropbox in the end, some of its security measures could use strengthening even if it's just intended to raise the level of sophistication necessary to steal Dropbox data.
Agreed. Except a lot of companies have a lot of " financial incentives at stake to be diligent security wise" but aren't.
Something I very recently heard: "World of Warcraft has had RSA-style two-factor token authentication for years, and my bank still doesn't"
Something I very recently heard: "World of Warcraft has had RSA-style two-factor token authentication for years, and my bank still doesn't"
Some thoughts re WoW vs banks:
WoW Authenticator is optional, costs $30~40, and intended for serious WoW players in a community with very strong peer support. Banks can do first two but don't have a community of tech savvy users to reduce cost of support manageable.
So Blizzard could but banks couldn't. Will this change? I think so but it'll have to be opt-in and paid for by customers, likely through third-party services first.
WoW Authenticator is optional, costs $30~40, and intended for serious WoW players in a community with very strong peer support. Banks can do first two but don't have a community of tech savvy users to reduce cost of support manageable.
So Blizzard could but banks couldn't. Will this change? I think so but it'll have to be opt-in and paid for by customers, likely through third-party services first.
$6.50, not 30-40: http://us.blizzard.com/store/search.xml?q=authenticator - this omits the free apps for most smartphones.
As far as peer support, honestly, there's almost no peer support. There is a strong first-line of FAQs and automated systems (regularly ensuring secondary contact information is accurate, well-defined systems for lost authentication devices,etc) and well-trained second-tier tech support.
There are enough third-party auth providers now that would be well able to provide the entire support chain for the banks. In fact, Gemalto has built for this: http://www.gemalto.com/financial/ebanking/
As far as peer support, honestly, there's almost no peer support. There is a strong first-line of FAQs and automated systems (regularly ensuring secondary contact information is accurate, well-defined systems for lost authentication devices,etc) and well-trained second-tier tech support.
There are enough third-party auth providers now that would be well able to provide the entire support chain for the banks. In fact, Gemalto has built for this: http://www.gemalto.com/financial/ebanking/
Every bank in Germany (that I know of) uses TAN lists. They mail you a list of generated numbers, and for each transaction, you need to enter one of those numbers, which is then consumed.
No fancy gadgetry required. Just a sheet of paper gives you all the same security advantages.
No fancy gadgetry required. Just a sheet of paper gives you all the same security advantages.
Regardless of how you want to parse a company's public statements and written policies, it's the height of naivete to think that a data host (ANY host) wouldn't share your data with law enforcement or has encrypted data in such a way that they guarantee that no one can access it.
If you have sensitive data, encrypt it yourself. Encrypt it on your local drive, back up encrypted data, encrypt it before uploading it to Dropbox. Doing otherwise is akin to not having a proper backup process: it's either because of laziness or ignorance.
If you have sensitive data, encrypt it yourself. Encrypt it on your local drive, back up encrypted data, encrypt it before uploading it to Dropbox. Doing otherwise is akin to not having a proper backup process: it's either because of laziness or ignorance.
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't able to access it, they mean that they, as a company, choose not to access it.
A good analogy is the post office. Anyone who works there and handles your mail could, if they so desired, tear open your package and steal the cookies your mother sent you. We trust them anyway, because we know they take precautions to ensure it doesn't happen. Dropbox is the same, but even tougher (I doubt the average Dropbox employee has access to their decryption mechanisms, but plenty of people at the post office can unseal your envelopes).
That said, to not acknowledge it as even possible for the company you send your data to you be able to access that data seems, to me, a bit naive. That's not the promise they made, and so the claim that they lied is false.
A good analogy is the post office. Anyone who works there and handles your mail could, if they so desired, tear open your package and steal the cookies your mother sent you. We trust them anyway, because we know they take precautions to ensure it doesn't happen. Dropbox is the same, but even tougher (I doubt the average Dropbox employee has access to their decryption mechanisms, but plenty of people at the post office can unseal your envelopes).
That said, to not acknowledge it as even possible for the company you send your data to you be able to access that data seems, to me, a bit naive. That's not the promise they made, and so the claim that they lied is false.
> 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.
There is no need for this data to be sent unencrypted. Encryption could be handled completely on the client side.
The plain English meaning of the words "aren't able to access user files" is not the same as "choose not to access user files".
Dropbox could just keep keys in a store where only automated user accounts can get to them -- ones where only the founders have passwords, or they are in escrow. I think there are ways to restrict the access to founders and a fail-safe, without opening them up to anyone who works at Dropbox.
Dropbox could just keep keys in a store where only automated user accounts can get to them -- ones where only the founders have passwords, or they are in escrow. I think there are ways to restrict the access to founders and a fail-safe, without opening them up to anyone who works at Dropbox.
If you run their client you've already made the decision to trust them to behave responsibly. The rest of this discussion is simply about obfuscation.
>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.
Much of that trust is based on the fact it is a felony, not what could just be an internal slap on the wrist.
All this press about Dropbox is getting ridiculous. I'm almost suspecting it's a hit job, but I'm wondering why people like De Caza are getting involved.
Pay attention to the two following rules. They are, and always have been true. Write them down if need be:
1.) The government can demand files from any US (and many non-US) companies. The company is then legally-obligated to turn them over.
In the past, the government has even successfully demanded data without the proper warrants (read about the VZW/AT&T/Qwest/NSA fiascos).
2.) Your cloud data is always subject to security breaches and provider employee abuse. Encrypt accordingly (I prefer DMG and TrueCrypt).
Why is this news? Did people not understand this?
Pay attention to the two following rules. They are, and always have been true. Write them down if need be:
1.) The government can demand files from any US (and many non-US) companies. The company is then legally-obligated to turn them over.
In the past, the government has even successfully demanded data without the proper warrants (read about the VZW/AT&T/Qwest/NSA fiascos).
2.) Your cloud data is always subject to security breaches and provider employee abuse. Encrypt accordingly (I prefer DMG and TrueCrypt).
Why is this news? Did people not understand this?
It is possible to design a Dropbox-like system with the following properties:
1. Files are stored encrypted.
2. The service provider does not have the ability to arbitrarily decrypt the files. By "arbitrarily decrypt" I mean decrypt at any time they wish. They will be able to decrypt if the owner's client is actively connected.
3. When someone uploads a file that is identical to an existing file, it initially is stored separately, but in most cases can be eventually de-duplicated, without compromising #1 or #2.
I'll leave the details as a fun exercise.
1. Files are stored encrypted.
2. The service provider does not have the ability to arbitrarily decrypt the files. By "arbitrarily decrypt" I mean decrypt at any time they wish. They will be able to decrypt if the owner's client is actively connected.
3. When someone uploads a file that is identical to an existing file, it initially is stored separately, but in most cases can be eventually de-duplicated, without compromising #1 or #2.
I'll leave the details as a fun exercise.
tarsnap
I'm guessing tarsnap doesn't satisfy the 3rd criteria, nor is tarsnap able to decrypt the user's files, even when the client is connected. Perhaps cperciva can comment.
3rd criteria can be considered a vulnerability, it may allow to know that certain user has a known file. It can be exploited to reveal information about the encrypted files.
Yes, I read that article too. That information leakage vulnerability can be eliminated by requiring the user always upload the file the first time they store it. Subsequent uploads of the same file for the same user could be skipped. De-duplication across users in storage is also possible without leaking information.
What is not possible (AFAIK) is the combination of the two requirements: 1) de-duplication across users, and 2) service provider is not able to decrypt your files. The latter requires the encryption/decryption be done on the client only (service provider doesn't have the keys at all). The former requires access to the unencrypted file, or for the clients to share keys.
What is not possible (AFAIK) is the combination of the two requirements: 1) de-duplication across users, and 2) service provider is not able to decrypt your files. The latter requires the encryption/decryption be done on the client only (service provider doesn't have the keys at all). The former requires access to the unencrypted file, or for the clients to share keys.
You can do (1) and (2) but it is not trivial to prove that it works. See: http://news.ycombinator.com/item?id=2461713
Clever. I like it.
Yes, exactly.
at the expense of conveniences like web access, document previewing, simple sharing, etc. - sure :-). if your answer to the web access concern is: derive the key from the password, who's to say we wouldn't store the key and later use it to decrypt your data?
web access non-withstanding, you'd be making a leap of faith to believe that the client is 100% trustworthy and that encryption is actually happening. at some point you have to make a decision as to whether or not you trust the entity (dropbox, google, or anybody else). if you don't, you should use something like truecrypt between you and the service.
all arguments made against dropbox apply to your gmail attachments, gmail mail, google docs, etc.
web access non-withstanding, you'd be making a leap of faith to believe that the client is 100% trustworthy and that encryption is actually happening. at some point you have to make a decision as to whether or not you trust the entity (dropbox, google, or anybody else). if you don't, you should use something like truecrypt between you and the service.
all arguments made against dropbox apply to your gmail attachments, gmail mail, google docs, etc.
> make a decision as to whether or not you trust the entity
If I don't trust the entity, how could I be installing any of its software on my machines? I have to trust what I am told if I am to use the software for its intended purpose.
If Dropbox claims what Miguel has quoted in his post, and then it happens that claims are (basically) not true, then it raises the question of integrity, i.e. what other assumptions that I have made were off? Say, that your .sys is not doubling as a key logger or your software is not scanning my disks at government's request, etc.
If I don't trust the entity, how could I be installing any of its software on my machines? I have to trust what I am told if I am to use the software for its intended purpose.
If Dropbox claims what Miguel has quoted in his post, and then it happens that claims are (basically) not true, then it raises the question of integrity, i.e. what other assumptions that I have made were off? Say, that your .sys is not doubling as a key logger or your software is not scanning my disks at government's request, etc.
it's unclear to me what statements we're making are 'not true'.
if you don't believe our statements, I'm not going to be able to convince you to trust us over the discourse in this thread :-)
if you don't believe our statements, I'm not going to be able to convince you to trust us over the discourse in this thread :-)
If you publish security spec and adhere to it in a way that allows independent verification of its implementation, then - yes, you will convince that what was claimed is true.
Perhaps, the easier route for you would be to just drop the whole "encrypted" angle and simply state that you provide reasonable protection of files while in transit and in your possession. That would satisfy 99.9% of real users and it will not rub cryptographic pedants the wrong way. The issue at hand is not that you don't encrypt properly, but that you over-promised, and over-promised in a very sensitive area.
(correction) "over-promised" = "implied more than what was said", i.e. what Miguel referred to as "wishy-washy statement".
Perhaps, the easier route for you would be to just drop the whole "encrypted" angle and simply state that you provide reasonable protection of files while in transit and in your possession. That would satisfy 99.9% of real users and it will not rub cryptographic pedants the wrong way. The issue at hand is not that you don't encrypt properly, but that you over-promised, and over-promised in a very sensitive area.
(correction) "over-promised" = "implied more than what was said", i.e. what Miguel referred to as "wishy-washy statement".
If the service provider can ever decrypt the file, then you have to trust them, and then it isn't secure. When it comes to security, you can't trust anybody.
The only way to secure your files in a Dropbox style situation is to use your own client-side encryption that the service provider has no access to... IE the Truecrypt solution that keeps being suggested.
The only way to secure your files in a Dropbox style situation is to use your own client-side encryption that the service provider has no access to... IE the Truecrypt solution that keeps being suggested.
Scratch that. I've got an even better design than what I was thinking of above. It makes it so the service provider never has access to the unencrypted data, and they can fully de-dup immediately, and it supports all Dropbox features.
Note that if two different upload files with the same content, they pick the same encryption key (since the key comes from a hash of the content), and so the same data gets uploaded. The service can thus do de-duplication, even though it has no access to unencrypted data.
So far, all this provides is secure storage. What makes Dropbox useful is that a file uploaded on one computer can be downloaded on another, and that only works if the downloader knows H(F).
This is solved by also uploading a copy of that local database I mentioned, the one that stores the (N(F), H(F)) pairs. This can be encrypted with the account password.
Syncing between different devices on the same account is then a two step process. First, the name/key database is synced, and then both devices have access to the keys and then the files can be synced.
I believe web access can be handled via this system. Dropbox's web interface requires Javascript, so it could have the browser retrieve the name/key database and decrypt it using the account password, which gives it the access to the key to decrypt a given file.
For shared folders, you can use a public key system, where the keys for the shared files are encrypted with the public keys of each person you are sharing the folder with, and the encrypted key files are stored in the cloud. Anyone accessing the shared folder grabs the key file for the folder and uses their private key (which is protected by the account password) to get K(F) for the file.
I believe this covers everything Dropbox does, with the properties that:
1. They can't decrypt your files.
2. They can de-duplicate completely.
3. Your account password is the key for everything for you.
4. It satisfies all of their advertising claims for security.
Let F be an arbitrary file.
Let N(F) be the name your client knows the file by.
Let H(F) be a hash of the file that produces a 256 bit hash.
Let AES(X,K) be X encrypted using AES with key K.
Note that if two different upload files with the same content, they pick the same encryption key (since the key comes from a hash of the content), and so the same data gets uploaded. The service can thus do de-duplication, even though it has no access to unencrypted data.
So far, all this provides is secure storage. What makes Dropbox useful is that a file uploaded on one computer can be downloaded on another, and that only works if the downloader knows H(F).
This is solved by also uploading a copy of that local database I mentioned, the one that stores the (N(F), H(F)) pairs. This can be encrypted with the account password.
Syncing between different devices on the same account is then a two step process. First, the name/key database is synced, and then both devices have access to the keys and then the files can be synced.
I believe web access can be handled via this system. Dropbox's web interface requires Javascript, so it could have the browser retrieve the name/key database and decrypt it using the account password, which gives it the access to the key to decrypt a given file.
For shared folders, you can use a public key system, where the keys for the shared files are encrypted with the public keys of each person you are sharing the folder with, and the encrypted key files are stored in the cloud. Anyone accessing the shared folder grabs the key file for the folder and uses their private key (which is protected by the account password) to get K(F) for the file.
I believe this covers everything Dropbox does, with the properties that:
1. They can't decrypt your files.
2. They can de-duplicate completely.
3. Your account password is the key for everything for you.
4. It satisfies all of their advertising claims for security.
That's an excellent solution. A couple of points:
1. It is usually not a good idea to use your key as a function of the message. Here, you would require your hash function to have a good min-entropy given inputs from whatever distribution M comes from. I believe SHA-256, as of today, will satisfy these needs.
2. Even if H is modeled as a perfect hash function (i.e., a random oracle, in crypto literature) you would require that AES itself does not use H in any particular special way. Think of AES' which is just like AES except when k=h(m) for any message, it just outputs k (i.e., cheats). It would be nearly impossible to detect this behaviour of AES' under normal circumstances because H is pre-image resistant, but clearly, this would trivially void the security of the scheme.
The suggestion is exactly what came to my mind, but the proof, although should most definitely hold when instantiated with AES and SHA-256 will require some work to be proven in general.
1. It is usually not a good idea to use your key as a function of the message. Here, you would require your hash function to have a good min-entropy given inputs from whatever distribution M comes from. I believe SHA-256, as of today, will satisfy these needs.
2. Even if H is modeled as a perfect hash function (i.e., a random oracle, in crypto literature) you would require that AES itself does not use H in any particular special way. Think of AES' which is just like AES except when k=h(m) for any message, it just outputs k (i.e., cheats). It would be nearly impossible to detect this behaviour of AES' under normal circumstances because H is pre-image resistant, but clearly, this would trivially void the security of the scheme.
The suggestion is exactly what came to my mind, but the proof, although should most definitely hold when instantiated with AES and SHA-256 will require some work to be proven in general.
There's still a big problem with de-duplication: Dropbox can still figure out which users have the same file, thus leaking information. That, combined with the fact that they'll know the size of the file already gives them a lot of info.
For example, if the FBI seizes a computer and finds some illegal files, they can still request Dropbox to give a list of users that have the same file.
For example, if the FBI seizes a computer and finds some illegal files, they can still request Dropbox to give a list of users that have the same file.
As has been mentioned elsewhere in the thread -- de-dupe isn't responsible.
If Dropbox is storing your files -- then the TLA can always request Dropbox to give a list of users that have the same file. (Unless you have some form of independant crypto/hashing)
yes, thank you for rewording my comment.
Tahoe-LAFS seems to fit the bill, except I don't know about #3. From what I understand it's rather stronger on #2, though.
This system already exists.
* Wuala (using encryption but somewhat insecure deduplication)
* SpiderOak (using more secure deduplication: https://spideroak.com/blog/20100827150530-why-spideroak-does...)
* Wuala (using encryption but somewhat insecure deduplication)
* SpiderOak (using more secure deduplication: https://spideroak.com/blog/20100827150530-why-spideroak-does...)
* AltDrive - client side deduplication.
Check http://camlistore.org/ it's by a few googlers including the guy that did memcached (Brad Fitz).
This should not be a service, this should a protocol, with RFC.
Couple this with the unencrypted metadata on mobile problem: https://grepular.com/Dropbox_Mobile_Less_Secure_Than_Dropbox...
And how their "encryption" on the server side is basically a lie, as they do dedupe on data: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u...
I'm stunned that anyone would use them for anything for ephemeral data you wouldn't mind posting in public.
And how their "encryption" on the server side is basically a lie, as they do dedupe on data: http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u...
I'm stunned that anyone would use them for anything for ephemeral data you wouldn't mind posting in public.
hi there,
arash from dropbox here. all data is (as we state in the referenced help article) encrypted before it's stored on the backend. I'm not sure why you're concluding that de-duplication implies lack of encryption. the de-duplication occurs prior to encryption.
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
all data on dropbox can be made shareable and is web viewable. as a consequence, we do need the ability to decrypt in the cloud.
re. employee access to files - there are controls to prevent this. for example, even drew (founder/CEO), doesn't have physical access to our storage servers anymore.
for very sensitive data, there's always the option to use truecrypt (we even offer this as a recommendation in our security documentation: https://www.dropbox.com/terms#security)
I love your product but your encryption is pretty useless and y'all must know it.
It only protects my data if your S3 account is compromised. There is a much greater chance that your web frontend, servers or client are compromised (either by an external or internal attacker) and then my files are easily accessed and decrypted.
It is like naive programmers who store user passwords with 'government level encryption' instead of correctly salting and hashing them, thus having to put encryption key in the source code
select AES_ENCRYPT("user password", "our secret key");
Saying your CEO can't access it, is just more security theater.
It only protects my data if your S3 account is compromised. There is a much greater chance that your web frontend, servers or client are compromised (either by an external or internal attacker) and then my files are easily accessed and decrypted.
It is like naive programmers who store user passwords with 'government level encryption' instead of correctly salting and hashing them, thus having to put encryption key in the source code
select AES_ENCRYPT("user password", "our secret key");
Saying your CEO can't access it, is just more security theater.
esteemed mr. arash, perhaps it might be a good idea for someone within dropbox to write a blog post answering common security-related concerns.
having a security sub-section in TOS is great, but it might be buried in google searches. anyways, it seems like this is a common concern amongst bloggers as you guys are exponentially rising in popularity, so some good PR on that front might be needed.
as usual, we're all rooting for you :)
having a security sub-section in TOS is great, but it might be buried in google searches. anyways, it seems like this is a common concern amongst bloggers as you guys are exponentially rising in popularity, so some good PR on that front might be needed.
as usual, we're all rooting for you :)
Dedupe and cleartext metadata as stated in the article I referenced, would allow for the following possibilities:
If an attacker could figure out the hash method used by dropbox on the files and intercept a few hashes from a victim, it's plausible that an attacker could trick the service into thinking that he had uploaded the files on his own account, allowing access to the victim's files.
Could you explain what would need to be done to protect against this attack method?
Security is hard - I hope yours improves.
If an attacker could figure out the hash method used by dropbox on the files and intercept a few hashes from a victim, it's plausible that an attacker could trick the service into thinking that he had uploaded the files on his own account, allowing access to the victim's files.
Could you explain what would need to be done to protect against this attack method?
Security is hard - I hope yours improves.
cryptographic signatures of files are never transmitted over plaintext. yes, the current incarnation of the mobile apps don't encrypt the names of the files but we are working on a fix for this as soon as we can adequately improve the SSL performance of our mobile apps.
Relying on others to safeguard/encrypt your personal data just doesn't make sense to me, in the same way that closed-source cryptography doesn't make sense.
If dropbox is claiming a false sense of security then that is an issue, but users that truly care about their data should resort to truecrypt or something where they are the only ones who control access. You can sync your files with dropbox and keep them safe with a truecrypt volume. Or if that is to much of a pain, only do so for sensitive files. Have your cake and eat it too!
If dropbox is claiming a false sense of security then that is an issue, but users that truly care about their data should resort to truecrypt or something where they are the only ones who control access. You can sync your files with dropbox and keep them safe with a truecrypt volume. Or if that is to much of a pain, only do so for sensitive files. Have your cake and eat it too!
Wouldn't they have to keep the keys on their servers? Otherwise when my computer dies, I wouldn't be able to access my files from a different computer.
This is the second completely unreasonable press attack on Dropbox. They are so unreasonable that I have trouble believing a reasonable person would think they are valid complaints unless they were trying to sell me a competing product.
Everyone with any security sense knows: 1. If someone gains access to your computer, and they can read your hard drive, and your computer can automatically log in to some service, then they can log in to that service. 2. If you can access the data without decrypting it locally, then your service provider can too. In a fantastically secure system, they will have decide to do and then wait for you to log in, but that's pretty unusual.
I predict next week we will get an article pointing out that I can get your files by breaking into your email account and then using the reset password feature.
Everyone with any security sense knows: 1. If someone gains access to your computer, and they can read your hard drive, and your computer can automatically log in to some service, then they can log in to that service. 2. If you can access the data without decrypting it locally, then your service provider can too. In a fantastically secure system, they will have decide to do and then wait for you to log in, but that's pretty unusual.
I predict next week we will get an article pointing out that I can get your files by breaking into your email account and then using the reset password feature.
There was a really good thread in /r/netsec a few days ago about encrypting your dropbox:
http://www.reddit.com/r/netsec/comments/gowvu/doityourself_e...
http://www.reddit.com/r/netsec/comments/gowvu/doityourself_e...
Dropbox is a good service, and I am sure file access is limited to a few employees, but I wouldn't use it for sensitive data or for a business. Any service where you do not control the encryption keys, e.g. Box.net, and myriad others will have the same issue. It's all about tradeoffs. Ultimately they can access your data. The truecrypt option may solve it for some but that means the whole archive has to be shared.
AltDrive unlimited online backup versions your files and allows you to control your encryption key. It runs on *nix, OSX, Windows, and other OSs. http://altdrive.com
AltDrive unlimited online backup versions your files and allows you to control your encryption key. It runs on *nix, OSX, Windows, and other OSs. http://altdrive.com
[deleted]
I don't know if that's how dropbox does it, but I could imagine that they have a master key to which normal employees don't have access, you need the founder and a trusted second person to retrieve it.
Thus their statement "Dropbox employees aren't able to access user files, and when troubleshooting an account" wouldn't be too far off the mark, and they can still make the data available to the government, on request and with higher effort.
Thus their statement "Dropbox employees aren't able to access user files, and when troubleshooting an account" wouldn't be too far off the mark, and they can still make the data available to the government, on request and with higher effort.
forgive me if I'm naive, but can file hashes be spoofed in any way? I'm thinking upload a bunch of files that hash to random numbers, then download the de-duplicated original files.
could someone more knowledgable in this area tell me if this is a credible threat?
could someone more knowledgable in this area tell me if this is a credible threat?
and is the hashing done by the client, or server-side? because client-side would make spoofing even easier.
Client side. If you upload a very popular 500+mb file, maybe try a popular linux distribution iso, it will sync instantly.
so has someone written a client where you just enter hashes of popular files you are interested in and get them snyced to your dropbox?
As far as I know, not yet. It's not even publicly known how exactly the deduplication API works.
For example: is the hash enough to "prove" you have a file? Or do you need the file size (and potentially other properties, such as the first block) as well?
The only way to find this out would be to look at the protocol that the proprietary client uses.
For example: is the hash enough to "prove" you have a file? Or do you need the file size (and potentially other properties, such as the first block) as well?
The only way to find this out would be to look at the protocol that the proprietary client uses.
10 years ago, europeonline launched a service where your traffic downlink would be routed through a satelite connection.
They also had a service that let you predownload files from http/ftp servers and then you could request an offline broadcast from their servers to your home pc.
Instead of refetching every file again and again, they also optimized by only checking the file size + file name. So, someone came along and created a fake ftp server script, which just replied with a listing of the things you wanted to download, and they there instantly added to your account. You only had to know the filename + filesize.
They also had a service that let you predownload files from http/ftp servers and then you could request an offline broadcast from their servers to your home pc.
Instead of refetching every file again and again, they also optimized by only checking the file size + file name. So, someone came along and created a fake ftp server script, which just replied with a listing of the things you wanted to download, and they there instantly added to your account. You only had to know the filename + filesize.
Spoofing is the easy thing, as the hashing is done in the client. You'd just have to figure out the protocol to get the file with a known hash (and other metadata, probably).
However, "guessing" the hash for a file that you don't have is not. The chance that you'll get a file by trying random hashes is very very very small.
However, "guessing" the hash for a file that you don't have is not. The chance that you'll get a file by trying random hashes is very very very small.
You're looking for two files f1 and f2 that hash to the same thing? And hoping that f1 is randomly generated by you, but f2 is someone else's original file which can be downloaded because of dedup?
In general, solving for f1 and f2 (i.e., you get to control both) such that h(f1)=h(f2) is called finding collisions in hash functions and hash functions like SHA are considered collision-resistant. It is very difficult to find collisions. http://en.wikipedia.org/wiki/Collision_resistance
Of course, if f1=f2, then you've magically guessed the original file, so that is highly unlikely. What you're asking for is something stronger than collision resistance; you're asking for a second preimage, given a first. This is for all practical purposes (requires at least 2^120 or more computations) impossible for any well designed hash function.
In general, solving for f1 and f2 (i.e., you get to control both) such that h(f1)=h(f2) is called finding collisions in hash functions and hash functions like SHA are considered collision-resistant. It is very difficult to find collisions. http://en.wikipedia.org/wiki/Collision_resistance
Of course, if f1=f2, then you've magically guessed the original file, so that is highly unlikely. What you're asking for is something stronger than collision resistance; you're asking for a second preimage, given a first. This is for all practical purposes (requires at least 2^120 or more computations) impossible for any well designed hash function.
All US companies will comply with government requests for data, even Google, when a warrant is presented.
If you don't want anyone looking at your data, use your own strong encryption layer and hope that there's not a back door.
If you don't want anyone looking at your data, use your own strong encryption layer and hope that there's not a back door.
I don't use Dropbox because their app on my computer have access to my computer.
The data I could send to Dropbox are as secure as the data i send to a host or email server.
... or may I wrong. :)
You can sandbox it.
If I steal your ssh private key, I can do anything I want
truecrypt ftw
If you're uncomfortable with dropbox, put a truecrypt partition right inside your dropbox folder.
If you're uncomfortable with dropbox, put a truecrypt partition right inside your dropbox folder.
I've been doing this for a while now and it works quite well.
In theory, if multiple snapshots of truecrypt are maintained, I believe it must be secure, but did the designers of truecrypt keep that in mind? Does dropbox maintain periodic snapshots of uploaded files?
Unlimited versions within last 30 days for all free and paid users (including changesets where files are deleted), paid users can also pay extra to keep every version since file creation.
So if you were suspected of getting a secret file and placing it in a dropbox hosted truecrypt volume, there would be a record of the time/date of altering the truecrypt volume and the possibility to compare the differences between two versions.
So if you were suspected of getting a secret file and placing it in a dropbox hosted truecrypt volume, there would be a record of the time/date of altering the truecrypt volume and the possibility to compare the differences between two versions.
How does that work with shared folders?
If you do this, make sure you disable the TrueCrypt option which preserves the original modification time of the encrypted volume when you modify the container, otherwise Dropbox may not notice when you make changes.
The "preserve modification timestamp" option is part of TC's plausible deniability feature.
The "preserve modification timestamp" option is part of TC's plausible deniability feature.
And they'd be exactly where we are today:
1) Yes, we could look at your data any time we want to. This is an inevitable consequence of letting you look at your data any time you want to.
2) We promise not to abuse our power #1.
3) If you don't trust us on #2, you should not do business with us.
Except they'd be out seven figures.