This is the first time I've heard someone on HN actually ask for more security theatre. Sure, Dropbox could spend seven figures to get a ISOxxxx whatever consultancy to draw up a 125 page document describing their internal checks, do the obligatory all-hands yearly mandatory training where you have to get 10/10 questions right and question 1 is "A user has uploaded naked pictures of themselves to their account. True or false: it is permissible to download these and take them home with you.", etc etc.
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.
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.
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"
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.
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.
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.
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.
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.
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).
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.
"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.
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.
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.
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.
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.
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.
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. ;)
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).
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.
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?
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?
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.
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".
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.
> 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.
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
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.
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.
#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.
> "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.
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.
> 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.)
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.
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.
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.
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?
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.