Improper security statements

[nmaier]

As I understand it, all that is required to obtain the "pseudo random, strong encryption key" is to authenticate with the FileRock servers via the password, retrieve a copy of the remotely stored and password-encrypted strong key, and decrypt it with (a derivation of) the password.

So the data security boils down to knowing the one password as the weakest link.
I see that there are several places where I'm supposed to enter said password on your website, e.g. the signup form and login form, therefore it is possible for FileRock and/or any attacker able to compromise your web frontend systems or MITM the traffic to obtain said password and access all the supposedly confidential data.
While the client software can be audited and it can be ensured that the plain text password is never transmitted, the website can not.

Hence, the statements that "you will be the only one able to view and modify your files." and "you don't have to trust anyone, not even FileRock itself!" are wrong and void.

One possible solutions would be implementing something like J-PAKE (see Firefox Sync).

[n0on3]

I will try to reply inline to this issue.
Apologies if I cut some parts for the sake of readability.

As I understand […] the data security boils down to knowing the one password as the weakest link

Correct.

I see that there are several places where I'm supposed to enter said password on your website, e.g. the signup form and login form

Correct again.

therefore it is possible for FileRock and/or any attacker able to compromise your web frontend systems or MITM the traffic to obtain said password and access all the supposedly confidential data

As you might have noticed, both the registration and the login form on the web perform the same PBKDF2 derivation of the password before sending the result to register/authenticate the user. Right now, this process is dove via javascript, so you can know that your password itself will not be sent by looking at the code fetched by your browser when the form is loaded.

While the client software can be audited and it can be ensured that the plain text password is never transmitted, the website can not.

That is partially correct.
While the javascript code can evolve or change without the user being notified about it, there are a bunch of creative solutions including e.g. installing a browser plugin client-side that checks the javascript code or using an applet signed by parts that are trusted not to collude with those you are sending data to. However, none of these solutions has been implemented yet and we are actually still thinking about the mechanism that we would like to enforce to solve this problem. Right now, the only way you can really trust the web interface is to check the javascript code to see that it does not send your password anywhere. I agree with you that this would be a crazy process to do all the time, but I would also like to point out that using the web interface itself is just a choice available for the sake of usability: the usage of the web interface, which is the "weak link" you are pointing to, is (or at least will be) completely optional. Soon it will be possible to register directly from the client, so you can avoid using the web interface at all, leaving it as an option for those who are just fine with checking the js.
We should probably write something about this on our blog, for the sake of dissemination.

Hence, the statements that you will be the only one able to view and modify your files and you don't have to trust anyone, not even FileRock itself! are wrong and void.

I hope that the comments above showed you that what is said in our statements is actually what we are trying to provide to our users. Using a service you don't need to trust through the web is a big deal for different reasons. We are trying to do our best and we are definitely open for suggestions.

One possible solutions would be implementing something like J-PAKE (see Firefox Sync).

I think that changing the password exchange protocol will not solve the problem you raised. As long as the requirement is that the user needs to authenticate himself on a web interface, even using J-PAKE, he will still need to type the password somewhere in the web page fetched by the browser, exposing it to javascript code which might be potentially malicious (my guess is that this is what you are concerned about).

You mentioned Firefox Sync, but (correct me if I am wrong) that relies on a piece of software which is actually installed on your device, and that therefore you can trust, not on some code fetched dynamically through the web from a potentially untrusted party.

I will leave this issue open for a while for comments and suggestions. If you have any tip or some mechanism in mind that you think could make our service more secure from the user perspective, please let us know.

Thank you again for initiating this discussion.

[nmaier]

First of all kudos for not trying to dismiss this under some marketing speech mumbo-jumbo, like some of your competitors did in the past when asked about the actual security properties of their offerings.

Yes, if the client registers the accounts, and the password is never transmitted in the process only a derivation and the strong key can only be obtained from another derivation of the password, then such a system can be secure (depending on the client code that is). ... at least I'd think it might be secure, but I wouldn't call myself a real expert on that topic.
What's still missing is forward secrecy in the register/auth process. An additional kind of proper key-exchange/HMAC also providing forward secrecy and not relying on the broken CA system to the rescue. ;)

A web interface would be a matter of convenience vs. security.
Compared to the dedicated client software, this has a vastly larger attack surface and trust implications.
If the user chooses to use a web login later, then she must be informed about the associated risks of doing so, namely anybody able obtain control over the clear data flow and/or server systems may gain immediate control over all her data. This then includes FileRock, hence she must know that she not only has to trust the open source client code, but also all the FileRock employees, systems and closed source - or at least not audit-able - server software and the CA system for the TLS connection should she use web login/web management facilities.
A browser extension, being just another client, might mitigate this as well, if done right.

The reason I mentioned J-PAKE is that this would enable the clients to generate and exchange strong keys not depending on the password, hence keeping files secure if the password gets compromised over the web. Even after you implement your plans to never (or only optionally) having to enter the password in the browser, it would still be a nice property to have.
Also, J-PAKE came to mind because, different than similar schemes, this one actually is widely deployed and researched for its security and performance properties because of the Firefox Sync implementation.

[n0on3]

First of all kudos for not trying to dismiss this under some marketing speech mumbo-jumbo, like some of your competitors did in the past when asked about the actual security properties of their offerings.

Constructive critics will help us building a better product. Dismissing them will be counter-productive.
It might take time to process these and to come up with better solutions integrated into the product itself, but it's worth it.

Yes, if the client registers the accounts, and the password is never transmitted in the process only a derivation and the strong key can only be obtained from another derivation of the password, then such a system can be secure (depending on the client code that is). ... at least I'd think it might be secure, but I wouldn't call myself a real expert on that topic.

That is our opinion as well.
Implementation of the registration process from the software client is on the roadmap.
We will deal with the web interface issue later on.

What's still missing is forward secrecy in the register/auth process. An additional kind of proper key-exchange/HMAC also providing forward secrecy [...]

PFS is something we have already been asked for ( comments to our announce on HN: https://news.ycombinator.com/item?id=5032470 ).
Keep in mind that the more our users (or potential users) ask for something, the more it gains priority.
So thank you for mentioning this, we are taking notes.

[...] and not relying on the broken CA system to the rescue. ;)

I'm not a big fan of CAs myself.
However, on the one hand it will be out of our scope to teach users that the solution should be enforced on their side and that HTTPS everywhere ( https://www.eff.org/https-everywhere ) + Convergence ( http://convergence.io/ ) is the way.
On the other hand, in the perspective of building a product, we needed to start from a set of features and properties, focus our effort on them, and leaving other things for further development.
You know, Rome wasn't built in a day :-)
This being said, we keep these issues in mind, and eventually their priority will bring them to our short-term roadmap.

A web interface would be a matter of convenience vs. security.

Exactly.
Right now, the web interface is there for the sake of availability and, as you mentioned, convenience: if you cannot run a dedicated software client, you are still able to access your data from the web interface with the downside of the additional concerns mentioned above. Or it might be just a user choice: if she prefers to use a web interface, despite the additional concerns intrinsic in the standard mechanisms for security therein enforced, she is allowed to do that.

Compared to the dedicated client software, this has a vastly larger attack surface and trust implications.

I agree.

If the user chooses to use a web login later, then she must be informed about the associated risks of doing so, namely anybody able obtain control over the clear data flow and/or server systems may gain immediate control over all her data.

I agree.

However, it might be tricky to correctly communicate this message to the users: more specifically, it might be complicated to make clear that the mentioned risk is relevant only if someone is able to take over the control of supposed-to-be-secure (read: SSL/TLS protected) communications, which is by the way the most widely deployed (and often the only one) mechanism used by many services that claim to be secure.

Let me explain this better: most of the users will not perceive such message as something that affects almost all of the services out there while we are just saying it to increase their awareness. Instead, they will probably perceive this message as a warning that they don't get on other services, most likely inferring that our service is actually less secure than others, which is just the opposite of what we are trying to provide.

As I mentioned above, we should work on the communication for this point, because informing the user will be definitely desirable.

This then includes FileRock, hence she must know that she […] has to trust […] all the FileRock employees, systems and closed source […]

We would like to find a way to exclude ourselves (as well as any of our closed/managed systems) from the list of the entities the users need to trust. I think we already boiled it down to the usage of the web interface. If the usage of the web interface is avoided, this is already accomplished.

As I said before, currently the only way not to trust our servers, when it comes to the web interface, is to check the javascript code to behave as expected, which I agree is quite unhandy. We are looking for better solutions on this issue, any practical suggestion will be appreciated.

[…] and the CA system for the TLS connection

In this case, this is not relevant. As I mentioned before, I'm not a big fan of the CAs, but the trust in the CAs is something under the control of the user, by means of the installed root certificates/trust-anchors in their OSs/keychains/browsers.

There are different methods to avoid MITM attacks.
Verifying the identity of the server by checking the sign on its SSL certificate, and eventually matching it with a CA for which the root certificate is trusted by the user system is just one of them.
Since it is the most popular, we provide support for this mechanism (i.e., our SSL certificate is signed by a well known and usually trusted CA), but if the user wants to use any different mechanism, he's allowed to do it.
We don't require to trust a CA. It's a choice left for the user to take.
So I think we don't need to warn the user here.

A browser extension, being just another client, might mitigate this as well, if done right.

Actually a browser extension, as you mentioned being another client, will completely solve the problem.
The extension itself could be open source as well.

The problem is that such extension will be another piece of software requiring to be installed,
therefore the web interface will still not have the desired availability.

The reason I mentioned J-PAKE is that this would enable the clients to generate and exchange strong keys not depending on the password, hence keeping files secure if the password gets compromised over the web. Even after you implement your plans to never (or only optionally) having to enter the password in the browser, it would still be a nice property to have.

This is actually what we were trying to provide with using different pieces of information for authentication (i.e. DERIVATION(password)) and encryption of data-encryption keys (i.e., DIFFERENT_DERIVATION(password) ). Since your actual password is never sent, DIFFERENT_DERIVATION(password) will not be disclosed, even if someone manage to get DERIVATION(password), your data will still be secure. The problem, in this case, is the trust in the code that actually performs the operations as expected (or not).

And correct me if I'm wrong, but using J-PAKE will not solve the problem, or am I missing something?

Also, J-PAKE came to mind because, different than similar schemes, this one actually is widely deployed and researched for its security and performance properties because of the Firefox Sync implementation.

We will take a closer look into that soon, thank you for bringing it to our attention.

Again, thank you for taking part in the discussion.