Using masterkey.cryptomator for 2-factor authentication

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.

1 Like

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.

© 2020 Skymatic GmbH • Privacy PolicyImpressum