Dropbox Lack of Security
tirania.org
tirania.org
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.
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.
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.
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.
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
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.
"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.
Doable, and even better, you can make that a 30 € / month corporate option. ;)
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).
The cloud is a scary place. Making it easy to use is not necessarily a good thing.
So yeah, mom's can definitely use it.
I use it on my torrent-conversion bookmarklet on http://hid.im.
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.
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.
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"
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 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.
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.
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.
You mean patio11 used oversimplification, folksy language, and cutesy examples to make a point? Say it ain't so!
"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.
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.
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.
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).
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.
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.
Only Dropbox can confirm whether it is theoretically possible for Dropbox engineers to peek at user data.
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.
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.
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.)
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.
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 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)
Under what circumstances?
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.
See: "How Dropbox sacrifices user privacy for cost savings"
http://paranoia.dubfire.net/2011/04/how-dropbox-sacrifices-u...
This is why encryption of data in the cloud, where the keys are not held by the provider, is essential.
"(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.
I'd like to hear from Dropbox how this works instead of speculation.
With luck the same sets of staff will not have access to both, et cetera.
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).
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 :-).
- All transmission of file data occurs over an encrypted channel (SSL).
- All files stored on Dropbox servers are encrypted (AES-256)
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.
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.
This is why I trust DropBox with my data: because I'm a paying customer. That means our goals are aligned.
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 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.
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
The govt will just request that they change the code so that you're in compliance.
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
You could have client side javascript that decrypts the files. http://crypto.stanford.edu/sjcl/
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).
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 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.
http://en.wikipedia.org/wiki/Lambda_calculus#Undecidability_...
So mechanically checking that Dropbox-supplied code is the decryption routine claimed is impossible.
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.
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.
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.
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.
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.
Those are pretty damn high hopes even for the average user from the generation that grew up with computers.
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.
Something I very recently heard: "World of Warcraft has had RSA-style two-factor token authentication for years, and my bank still doesn't"
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.
No fancy gadgetry required. Just a sheet of paper gives you all the same security advantages.
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/
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.
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.
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.
Much of that trust is based on the fact it is a felony, not what could just be an internal slap on the wrist.
There is no need for this data to be sent unencrypted. Encryption could be handled completely on the client side.
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?
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.
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.
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.
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 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 :-)
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".
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.
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.
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.
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.
* Wuala (using encryption but somewhat insecure deduplication)
* SpiderOak (using more secure deduplication: https://spideroak.com/blog/20100827150530-why-spideroak-does...)
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.
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)
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 :)
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.
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.
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!
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.
http://www.reddit.com/r/netsec/comments/gowvu/doityourself_e...
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
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.
could someone more knowledgable in this area tell me if this is a credible threat?
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.
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.
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.
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.
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're uncomfortable with dropbox, put a truecrypt partition right inside your dropbox folder.
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.
The "preserve modification timestamp" option is part of TC's plausible deniability feature.