This is a frequently asked question. Developers of the Cryptomator state that keeping the masterkey.cryptomator file offline does not add to the security. They mention, for example, that the encrypted master key is not more important than the encrypted data.
This is false. Putting the encrypted masterkey next to the encrypted data lowers the security, sometimes substantially. One obvious case is when te password is not strong enough. However, there are other reasons too, depending on the situation.
Why not providing a custom path? It should be one line of code.
If its just “one line of code”, why not make a contribution? Doesn’t sound to difficult.
If the password is not strong enough, it was the deliberate choice of the user. Cryptomator can only motivate the user to use a strong password. An additional thought: If the user chooses a weak password, why should they care about the masterkey location?
Bizarre arguments on anything other than the issue itself!
A password is not a cryptographic key. For any password that contains less than 250 bits entropy, it’s better to keep the file offline. 250 bits is 38 diceware words. Most very good human-supplied passwords might include around 70 bits.
There are other important issues as well.
I could make a contribution, but you are already familiar with the code. The question was why not setting a $PATH.
Edit: If you are worried about a brute-force attempt, there are two ways to do that…
Either brute-force a X-bit password that has to run through scrypt though, which adds a lot of computation!
Or brute-force a 256-bit cryptographic key, which takes forever.
So yes, if the bit count of the password is too low, it’s bad. But it’s not true to say that a password has to be 256-bit in size in order to be as secure as a 256-bit cryptographic key.
I am familiar with these points. A key obtained from a password with X bits will have an entropy less than or equal to X bits, regardless of the key derivation function.
I mention another issue. Versioning on clouds. A vault on a cloud with versioning is secured by the security of the weakest master key (unless Cryptomator regenerates the final master key and re-encrypts data with that. I suppose it only re-encrypts the master key). So changing a password to something stronger is pointless.
Still other issues too.
There is really no reason to enforce this file on the cloud. That’s why GPG master keys are strongly gaurded, even though they are encrypted with users passwords. They are held offline, outside user’s computer. Masterkey.cryptomator should be treated as such.
A good practice in security i to assume users are not familiar with crypto, and do things properly on their behalf, rather than expecting them using 256 bits from password managers.
You have to consider that Cryptomator was designed to be “simple to use” and “without much configuration usable between many devices, including mobile devices”. It was a well-thought design choice to put the masterkey file inside the “vault folder” so that it’s instantly accessible from many devices.
Maybe my “edit” in my last post was too late but you don’t need a 256-bit password. I understand your suggestions and as you’ve seen, we had many discussions in the past and we’re making sure that we consider this issue from many angles.
You can’t just think about technical feasability. In that case, yes of course you could just define a custom path for the masterkey file and this could probably be “one line of code”.
But that’s not how designing and developing a product works. This would have many implications like:
How do I know which masterkey file belongs to which vault? Yes, you could solve it with an identifier or something like that but that’s not currently defined in the vault format. Yet another change.
How do I make sure that I have access on my mobile devices? You would probably need lengthy instructions on how to import the masterkey file from your Desktop computer to your mobile device (and vice versa). Yet another change.
How do I make sure that there are backups of the masterkey file? What if your computer/laptop breaks and the masterkey file is getting lost, even though your encrypted data is still in the cloud. That means they become useless? This is a hell of a big problem that can’t be just ignored, you have to think about usability as well.
There may be further points that I haven’t thought of spontaneously right now but I just wanted to say that it’s not “just one line of code”, which is an absurd statement for such a huge change.
With symbolic links I managed to place the keyfile somewhere else.
Cloud sync tools can filter the keyfiles, so they are not stored in the cloud.
Of course on other PCs the same methods (symbolic links and sync filtering) have to be used.
On smartphones this solution is probably not possible.
More details are in my posting of today in another forum topic: 2FA Authentication
TrueCrypt and VeraCrypt allow for alternate locations for configuration files, so I see no real downside in allowing advanced users to do this.
Yes, it adds a layer of complexity, but this would obviously be for advanced users who want to put in the extra effort to do this. You could even give them a warning.
To answer your questions:
You could implement this, but it’s not necessary, imho. The user could simply rename the masterkeys to something that helps them keep things organized. This should be the user’s responsibility.
If you want to add an identifier sometime down the road, that sounds like a good idea. But it’s not necessary in order to achieve the basic functionality.
Users can either import a copy of the masterkey file using native functions of the operating system, or copy and paste the text contents of the masterkey file into a text field.
I don’t believe either of these options would require lengthy instructions.
This is the user’s responsibility. Give them a warning to make sure they understand the consequences.
All in all, I think this would be a good feature to implement for people like me who want to keep the masterkey offline, and you could keep the implementation simple.
No, it’s not “one line of code”. But adding code to allow for a different path/filename for the masterkey shouldn’t be difficult, neither should adding code to allow users to import a masterkey or paste its contents into the mobile app.
The arguments here all assume substantial tech knowledge on the part of the user. I don’t know how typical I am but as an elderly grandma growing up in the era of pen and paper, I would appreciate a simple easy-to-use program where my only contribution is to ensure the password is secure and un-guessable. Now I see suggestions in the forum that even long complex passwords are not secure. Some of you suggest making the program more complex to ensure security. I see it as a matter of trade offs. A program can be so complex and secure that using it is more trouble than it is worth.
