

Show HN: FileRock, a Secure Dropbox Clone, goes Open Source - n0on3
http://blog.filerock.com/2012/12/were-going-open-source/

======
andrewcooke
i have a question about their authentication process as described at
<http://blog.filerock.com/2012/06/filerock-security-overview/>

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...).

~~~
n0on3
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.

~~~
andrewcooke
thanks; that makes more sense.

------
dchest
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.

~~~
n0on3
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

------
n0on3
Just in case the slashdot effect strikes, direct link to the source code on
GitHub is: <https://github.com/filerock/FileRock-Client>

------
darkarmani
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.

~~~
n0on3
you might want to look at this (
<https://news.ycombinator.com/item?id=5033540> ) comment on why the PBKDF2 is
sent for the authentication rather than the password.

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.

~~~
darkarmani
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.

------
dz0ny
Only client stuff, skip...

~~~
luser001
On the contrary.

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?

~~~
lectrick
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".

~~~
n0on3
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.

------
StavrosK
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.

~~~
n0on3
Good question, difficult answer.

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).

------
SODaniel
SpiderOak (<https://spideroak.com>) is a zero-knowledge focused and secure
backup service that you may want to take a look at.

~~~
jivemind
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.

~~~
clebio
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.

------
chimeracoder
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.

[1] <http://git-annex.branchable.com/>

------
shtylman
1) Where is your pricing info?

2) Do you have mobile clients?

3) What makes this better than encfs on top of dropbox?

~~~
FileRockDA
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.

2) Not yet, but we are planning to.

3) See this comment: <http://news.ycombinator.com/item?id=5036011>

