The Cryptomator vault is protected with two 256 bit encryption keys which are generated when creating a new vault. These keys are not under control of the user. This is all very nice.
To provide a usable system, the encryption keys are further encrypted based on the user supplied password (with a salt etc) and stored in the cleartext file masterkey.cryptomator as the key encryption key, KEK. Also, due to this multi-step process, is it possible to change the user password/KEK without changing the 256 bit encryption keys.
The security of the system now depends on the user password, which must be “human-rememberable” or managed by a password manager, or stored somewhere safe. I assume that this password (often) will be less safe than the 256 bit encryption keys. Currently the KEK is stored together with the encrypted data, so that could be a nice attack vector. After gaining access to the encrypted vault, the key encryption keys come with it for free, including the KEK’s based on previous user passwords.
There is no strict need to store masterkey.cryptomator in the vault. If stored locally, the 256 bit encryption keys cannot be “degraded” with weaker user passwords/KEK’s, al least not until the locally kept KEK is also obtained.
Feature request: Optionally store masterkey.cryptomator locally.
Also mentioned in: Using masterkey.cryptomator for 2-factor authentication