they say that they don't send the password over the net, but send instead the result from PBKDF2. but how does that make things more secure? couldn't someone simply snoop the PBKDF2 output and send that themselves? (if they could eavesdrop at all - my point is not that eavesdropping is possible, but that a transformed password is equivalent to the password itself).
i thought perhaps they provided a different random seed for PBKDF2, but then they would get a different answer each time and wouldn't be able to check it.
i get why PBKDF2 is better than just using a "simple" password. but i don't get why they make a point of saying your password is not transmitted. i mean, HTTP basic auth uses a hash, but that's considered just as insecure as the password for exactly this reason. and PBKDF2 is just a a glorified hash.
it just seems confused. claiming something is an advantage when it's not, as far as i can tell (although i suspect the confused party is me - it just reminded me so much of http basic auth...).
the point is that in FileRock, several things depend on your password, and some of them must be kept confidential and never sent even to the FileRock servers.
You are right, from the only point of view of the authentication, using a password gives you the same level of security as using one of its derivations (given a deterministic generation of the derivations and a password with same length and randomness of its derivations).
The mechanism that actually protects your credentials from being sniffed and used to get the first level of access to your account, is the industry standard SSL/TLS.
But even if someone discovers which is the derivation that you use to authenticate with the FileRock servers, they won't be able to know your password. And that means that the other derivations of your password (for example, the one used to protect the encryption keys for your data) are not disclosed as well. Therefore, even the people managing the FileRock servers will not know them, and they will not be able to access your encrypted data.
I hope this will solve your doubts.
PS: I see now that evv and notimetorelax also replied and they are correct.
I can't speak on behalf of FileRock, but I suspect the following, based off of the blog post you linked:
While the PBKDF2'd password CAN theoretically be snooped (if this wasn't wrapped in TLS, it would be trivial), the actual password cannot be calculated from the derivation.
So yes, an attacker who listened to your transmitted PBKDF2'd password can theoretically access your encrypted files from the server. However, if they could snoop, they could have just watched those encrypted files as they came across the wire.
The client-side encryption is still just as effective. As far as I can tell, your data would still be safe.
You'd probably want to bump 1000 iterations of PBKDF2 to something like 100000 in the next version. Better: include cost parameter in key format, and calculate the number of iterations on-the-fly by estimating how many iterations it takes for a certain amount of time.
good point. For different things we kept it quite simple, but soon we are certainly going towards these refinements and your suggestion sounds pretty good imho
It's not quite the same, but I've grown very fond of git-annex[1], which is also free software under the same license (GPL 3).
With git-annex, it's very simple to create your own self-hosted Dropbox. Unlike Dropbox, though, git-annex allows you to make your filesystem completely decentralized.
A rather rudimentary analogy: Dropbox:gitannex :: SVN:git.
I haven't looked, but assuming they do TLS like everyone else and they haven't provided perfect forward security, then sending the PBKDF2 hash over the wire is still a weakness.
Granted this is the same weakness that exists in most implementations of SSL where one sends their clear text password over a SSL channel.
As far as concerns the usage of TLS, your guess is correct, right now we allow the usage of the most common cipher suites, with some of them not providing PFS.
However, the negotiation of cipher suite is just a matter of configuration, and we might take a closer look pretty soon on which ones we want to allow or not.
I saw that. I guess the problem is that for authentication I hope that the PBKDF2 hash is further hashed before sticking it in the DB to protect against DB compromises.
If you absolutely need server stuff, Tahoe-LAFS [0] looks good. The mailing list is great[1-2]. An interesting service uses it, Least Authority[3] offers Tahoe-LAFS-on-S3[4]. It runs for free on Dropbox, too[5].
"Tahoe-LAFS is a Free and Open cloud storage system. It distributes your data across multiple servers. Even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to function correctly, including preservation of your privacy and security."[0]
TL,DR: Storage nodes can't decrypt your data, so you don't have to trust them.
I would not feel good about my data on random people's servers. I don't trust the encryption. not today and definitely not 10 or 30 years from now when they could still have the data.
That's why its being open source is relevant. Paranoid folks like us set up a private network locally or on any number of our own physically secure servers.
It's also an interesting question:
How comfortable do we feel relying upon the "principle of least authority" long-term in a mixed-trust environment? i.e., a p2p-style Tahoe-LAFS grid, or deploying it privately using a commercial vendor like Amazon S3 (either directly or through Dropbox for free), on our own servers, and everything in between.
You might not trust companies from certain countries with your data, and you shouldn't be forced to in order to store it* in the cloud*.
"[…] You might not trust Companies with your data either, and you shouldn't be forced to in order to store it in the cloud". That is exactly our goal: we don't like to be forced to trust companies for the security of data, so we are developing a service where users actually don't have to trust even us… although some trust in the encryption algorithms used will be required, given that you can see the implementation of course.
As a user of a service the client is the only piece that I really care about wrt data security. If I can verify that the client isn't secretly uploading encryption keys to the server while claiming to encrypt my data, it's a massive win for transparency.
The server is a just an abstracted hard disk. Why would I care how it is implemented?
Because some people want to run their own DropBox clone, and titling the post "...goes Open Source" usually (correct me if I'm wrong) implies that the ENTIRE product goes open-source, not just half of it in order to prove that its security is "for real".
Apologies if the title of the post is not clear, I should have specified that it was only about the client. You are right, one of our main goals is to prove that our security is "for real". However, we also hope that our open source client might be useful to other projects, as well as for developers to fork it and implement themselves what is out of our scope.
Basically, yes, that's the point. Publishing the source code of the client allows the users to be sure that FileRock (Client) isn't "secretly uploading encryption keys to the servers". But please note that the server is not just an abstracted hard disk: it has a role in efficiently checking the integrity of your data, which goes beyond the encryption. For instance, FileRock is able to efficiently detect whether the data has been tampered by deleting a file. Although some of the work is done on the server, the client can counter-check its answers.
By that reasoning alone, tarsnap would also be something skip - but it's not. I haven't looked at FileRock (yet) and don't know any of the technical details, but there's still possibility to do interesting things without trusting the server (though I don't know if FR have succeeded at this).
I can't. Tried owncloud, as an alternative to my paid Dropbox account. It's incredibly slow to sync anything moderately large. I handed it 30GB of my 70GB home directory, and filesystem traversal on startup was taking 15min. On an ssd. Where Dropbox would take 15-30s.
I am currently using Dropbox with an EncFS folder on top, so your solution is interesting to me. One question:
Does (will) it sync as well as Dropbox?
Dropbox consumes almost no system resources, syncs right away with inotify, transmits files on the LAN and is generally very good at what it does. If your client is as good, I will switch to it for sure.
We are doing our best. So far, the performance and usage-of-resources are not the fields where we put the most of our effort. Additionally, there are two main issues to consider:
The first is about our security features: encryption and integrity check require some computation, hence our clients will have an higher load compared to Dropbox. Moreover, some of the magic performed by Dropbox to improve performance, cannot be combined with some of the security measures that we enforce.
The second is about the firepower of and age of the products you are comparing. Dropbox has a quite large and amazing team ( https://www.dropbox.com/about ) as well as few years of product development and testing on a large and impressively growing user base. The comparison with our team ( http://blog.filerock.com/founders/ and http://blog.filerock.com/dev-team/ ) and our time on this project so far, would be like throwing a cobble to the Ayers Rock and see who moves.
We are aware of the feature you mentioned: for instance, we already went for the filesystem monitoring using the API provided by the different platforms, but it turned out that they didn't behave as we expected on all platforms, in particular they made hard to get correct results needed by our integrity check technology. So we had to choose where to concentrate our effort and decided to put it on our distinctive features. So we switched to a simpler (and inefficient) approach that currently guarantees the correctness we need on each supported platform. As soon as possible, we plan to mix our current approach with the aforementioned usage of the different platform APIs to increase performance but still keeping our integrity check mechanism working properly.
Of course in the long term we aim to be as efficient as possible, and Dropbox is definitely the one to run after on this perspective. However, this will need time and resources. The good news is that having an open source client, anyone can contribute suggesting an improvement, or even implementing features that are not yet in our short-time roadmap (e.g., on-LAN files sync).
SpiderOak looks great. The only issue is that, since the client is not Open Source (or is it?), you have to trust what it does and you cannot verify it in the code.
To my knowledge it is not. For this reason, I stopped using it, despite their otherwise very nice approach generally. I have been doing without cloud storage for my most important files (financial documents, etc.), so I'm pretty interested in Filerock, having found this thread.
I naively attempted to roll my own mash-up for this purpose (https://github.com/clebio/duplicitySync) and was not successful. The combination of local encryption, incremental backup, and _synchronization across multiple computers_ was the breaking point.
1) We're still in private beta, we hope to publish commercial offers soon. You will get 3G free, and there will be different plans if you want more space. If you take part in the private beta, you will get a discount when our commercial offers go live.
they say that they don't send the password over the net, but send instead the result from PBKDF2. but how does that make things more secure? couldn't someone simply snoop the PBKDF2 output and send that themselves? (if they could eavesdrop at all - my point is not that eavesdropping is possible, but that a transformed password is equivalent to the password itself).
i thought perhaps they provided a different random seed for PBKDF2, but then they would get a different answer each time and wouldn't be able to check it.
i get why PBKDF2 is better than just using a "simple" password. but i don't get why they make a point of saying your password is not transmitted. i mean, HTTP basic auth uses a hash, but that's considered just as insecure as the password for exactly this reason. and PBKDF2 is just a a glorified hash.
it just seems confused. claiming something is an advantage when it's not, as far as i can tell (although i suspect the confused party is me - it just reminded me so much of http basic auth...).