I read in the password documents that changing an existing vault to a longer password doesn’t fully upgrade the security of the encrypted files. I don’t know the reasons (cryptomator is a black box to me), but in my simplistic view, it implies there remains a residual security disadvantage from the initial weaker password. I wonder if the logic can be flipped so that if we start with a strong password and go to a weaker, then we still have some residual security advantage from the initial strong password.
Hence my title question. I’ll say it another way with a more practical spin: If I intend for the long term to use a 15 character password, would there be any benefit to starting out with a 25 character password initially, just to get those residual benefits later after I changed to 15 characters for the long term?
Or maybe it applies on a per-file basis, files added/modified after the password change adopt the security level of the new password?
1 Like
To answer your specific question, there is not such a thing as “residual security advantage or disadvantage” in regards to the vault’s password. However, there is indeed something that you have to consider when setting/changing a password.
I’ll try to explain what happens so that Cryptomator is not a black box for you anymore. 
The following is also described in detail in the security architecture.
Every vault has a masterkey (two 256 bit keys that have been randomly generated in a cryptographically secure way). If an attacker tried to gain access to such a vault, they would need to brute force the 256 bit keys, which is basically impossible.
But that’s not the whole story. As you can imagine, nobody is able to remember a 256 bit key. That’s why the vault’s masterkey can be derived from a user-assigned password, which is much more user-friendly. This password is secured against brute-force attacks via a key derivation function, in this case called scrypt.
All the relevant information is stored inside the masterkey.cryptomator file. So for an attacker, it might make more sense to try to brute force the user-assigned password instead of the actual masterkey itself. Indeed, a 15 character password could be less secure than a 25 character password.
So what does this actually mean in your scenario? Let’s say you create a vault with a 15 character password. As I’ve mentioned, the information is then now stored in masterkey.cryptomator. After that, you change the password to something with 25 characters, believing that it’s more secure. Then the masterkey.cryptomator file will be replaced with the new information. (Edit: Keep in mind that the randomly generated masterkey stays the same. Only the password changes.)
In this case, you have to ask yourself the following questions:
- Are there any backup files of
masterkey.cryptomator? If yes, they can technically be used to unlock the vault.
- Are there older revisions of
masterkey.cryptomator in the cloud that could be restored? If yes, they can technically be used to unlock the vault.
So even though you’ve changed the password to a more secure one, you have to make sure that the old password can’t be used anymore (delete the backups and/or older revisions in the cloud).
5 Likes
Thanks for the thorough and understandable explanation.
Summarizing for my own benefit - in the case where we happen to have multiple masterkey.cryptomator files floating around (not cleaning up after a password change), our security level is weakened by the weakest link (the weaker of the files). There’s no way to leverage that to end up with stronger protection than the current password, because the masterkey.cryptomator for the current password needs to be there.
You can create a new vault with a strong password and then move all files from within your old vault to your new vault. This will cause a new encryption of your files, and obviously make all old masterkey files useless.
Thanks. Actually I think you misinterpretted my meaning. I was wondering if there was a way to get a “free lunch” of stronger protection than the password that I routinely enter when opening a vault (if I could initially set up a long password and then change it to a shorter and retain some benefits of the longer password, then than that would be a free lunch).
The answer that I’ve learned in this thread is there is no free lunch. That probably shouldn’t surprise me. I’m sure it was already obvious to others.