Reading about the way the masterkey.cryptomator file works, I thought it could be used to implement some sort of 2-factor authentication mechanism.
Basically, if one didn’t sync the masterkey file on the cloud space where the rest of the files are, an attacker gaining access to the cloud storage would both have to KNOW the password and OWN the masterkey file through other means.
The masterkey file could even be kept in sync with another storage space using another app which in turn only keeps track of the masterkey file itself.
Of course this only covers the “threat model” of a remote attacker gaining access to the cloud space, because the masterkey and the files would still be on the same machine locally.
I am wondering, though:
How useful would this really be? For example, how much more complex it becomes to “crack” the vault in these circumstances?
And which implications does this have given the way cryptomator works? I seem to understand that the master key can change under some conditions, so one should be really careful to always ensure they are keeping the most up-to-date one.
Yes, this might satisfy some paranoid users. In theory there is no problem with storing the masterkey somewhere else and somehow configuring Cryptomator to load it from a user-defined path.
We would sacrifice convenience, though. I assume that the average user wants as few manual configuration steps as possible.
Therefore this would only make it as an optional configuration with no guarantee of compatibility with third party applications able to decrypt vaults.
The masterkey changes either when the password changes or when the vault is migrated to a newer version.
Even now, one could just setup the two clients to watch the same directory (the vault one), and setup filters on them to have them track mutually exclusive files. Probably not all services’ clients would allow that, so yes, a (very) optional setting in cryptomator for custom masterkey location would still be helpful.
I fully support the proposal of the possibility of separate storage of the masterkey file and encrypted data. The path to encrypted data can be stored in the masterkey file. This will make the product much safer.
As an alternative of password to sharing encrypted data, I would like to be able to encrypt the masterkey file using public OpenPGP keys for each user instead of the password. The algorithm is this: a random password is generated, which used to encrypt the masterkey file, and this random password is encrypted with users public keys. The users can use their private keys for access to encrypted data.
I am coming from Boxcryptor Classic, which is since some time no more useful due to replacement by subscription license. Not acceptable for me! With Boxcyptor it was possible to define a separate location for the key file. For me Cryptomator is not only a replacement, but much better!
With Cryptomator the keyfiles have to be located in the root encrypted vault directory. However I managed with Windows symbolic links to place the keyfile “masterkey.cryptomator” somewhere else. To be precise, this masterkey file is placed in my personal Veracrypt drive. A hardlink would be only possible, if the keyfiles are on the same physical harddisk, that is why symbolic links are the solution.
But you have to pay attention, the backup file “*.bkup” is created automatically from Cryptomator during mounting in the vault directory. The file name of this file seems to be constant, so a symbolic link is also possible. So I am synchronizing the vault to my cloud storage just without the two keyfiles. Access and syncronization from other PCs is possible with the same method (exclusion of keyfiles when uploading). A couple of good cloud synchronization tools allow such filtering.
Hard, junction and symbolic links are good to know and beneficial to use.
Best regards from Rudy
P.S.: On smartphones this method is probably not possible (I do not know and never tried hard, symbolic and junction links on Android). And please note, that symbolic links are NOT possible for the normal encrypted files in the Cryptomator directory. Seems to be a limitation/bug reported in [Github-Cryptomator](https://github.com/cryptomator/cryptomator/issues/879). I do not care for the masterkey files, because this is a totally different topic.
We’re planning to decouple vault configuration and key material with the next vault format, which will eventually allow official support for externally-stored masterkeys.
Hello. I wonder, would you mention the names of those cloud synchronisation tools? I’m aware of Syncthing, and am interested to know which tools you like.
Hello Rotam,
if possible I prefer opensource and donation tools, but sometimes payware does make sense or is really necessary and worth the money. Syncthing is ok, simple and convenient, but I prefer more options for various sync jobs. That is why I use free FileZilla, WinSCP and FreeFileSync. But for the most advanced requirements I use Syncovery. Syncovery is not free, but offers a lot of very usefull options, when you have learned how to control and use them.
This has been implemented with Cryptomator 1.6.0, see
The way this works is that you can simply store the masterkey.cryptomator somewhere else, such as on an external device. Cryptomator will then ask you for it during unlock.