Congratulations on working on the new version 1.5.0. Great job! I am a loyal supporter.
Question: The new version offers a “recovery key”. Doesn’t this feature raise security concerns? It’s as if we now have 2 passwords. And one is generated by Cryptomator. I am kind of concerned about the “recovery key” feature. Instead, users should use a reliable password manager and only use a 1 password feature on Cryptomator. Or, as a user I would like to have the option to not have a recovery key issued. I consider this “recovery key” feature unnecessary and causes some security concerns. I would opt-out if I was given the option.
Mhm, it’s quite a while since I switched to the alpha and migrated all my vaults, but due to this documentation, the recovery key generation already is an optional feature.
Ok, I have to correct myself.
The step of displaying the recovery key during vault creation/migration is optional, but the recovery key does always exist and can be shown in in the password options. (See here)
So this feature is basically not optional at the moment.
Not entirely true: It isn’t „generated“ upfront in any way. It is rather derived from the master key, when the user wants it.
So it only exists when one wants to see it. Kind of like the gods in the discworld only exist when you believe in them.
That said, you are correct in the assumption that you need to treat it like a second password. The key difference is, that it has full 512 bit entropy and doesn’t require key stretching.
Regardless of wether you chose to show the recovery key during vault creation or not, it always exists. Hence, you can view it at a later point in time.
The confusion comes from the fact, that I wrote this documentation but did not develop the recovery key generation method. (The specialist is @overheadhunter)
What I wanted to express is, that the recovery key is acutally just a representation of your master key. It is not stored somewhere, but can be easily computed from your decrypted masterkey. See it as an human-readable form of the master key.
@MichaelThis documentation appears to be giving the option to create or get access to the recovery key when we create a new vault under 1.5.0. However, this is not the case when we migrate a vault from the 1.4 version.
Regardless. I would feel more comfortable if I had the option to opt-out, and if my Vaults could be decrypted with only 1 password. This is just a suggestion. I am always using a reliable password manager, and this is my customer behavior/ preference.
Since nobody can remember 256 bit keys, you can choose a password. According to Cryptomator’s encryption scheme, the keys can then be derived from a user’s password using scrypt.
Important: The 256 bit keys never change for a vault. Even if you change the vault’s password, the new password still derives to the same keys. If we’d change the keys, we’d have to re-encrypt all files inside the vault.
A recovery key is just another way to derive the 256 bit keys. Okay, that’s not technically true, a recovery key is another representation of the 256 bit keys.
(If I’m not completely mistaken, the recovery key consists of two 256 bit keys, encryption + MAC, maybe we should document that somewhere as well, but that’s not the point.)
What does that mean? If you never show the recovery key, there is nothing to worry about. The 256 bit keys are still secret and can only be derived from the only password you’ve chosen. How should anyone decrypt your vault with a recovery key if it has never seen the light of day? Basically, you can’t opt-out of the 256 bit keys.
So the only way to “truly” change passwords is creating a new vault and copying the contents of the old vault there? Perhaps automating that could be a feature for a future release?
@Michael Thanks for this clarification to @amrods point. I would also like to see a feature for the future, where the Recovery Key could be changed and updated on a given Vault. If that’s not possible, and in order to avoid human mistake on protecting security, it would be better to never have access to the Recovery Key. Having access to a recovery key given that it can never change could lead to a security compromise due to human error by the user. Eliminating the possibility for such a human error would be best.
@olyroad You do understand, that there was no recovery key in past versions and that it was introduced to mitigate the possibility for human error?
I don’t think you quite get what the recovery key is, yet. It can not be changed. It is a representation of the masterkey that can be used for disaster recovery.
If you don’t opt in for using it, then it does not exist. Nobody can use it if you haven’t generated it. It isn’t pre-generated and lurking around somewhere on your system.
While bruteforcing a password is a hard job (German post), bruteforcing the recovery key is virtually impossible, since it has the full 512 bit entropy of the original key. It is not a KEK, it is the key itself. No stretching involved.
Of course, if you opt for saving/printing/etc the recovery key, you should treat it like a password. This is btw what the instructions already stress.
if you concerned about leaking the recovery key, just discard it and don’t write it down anywhere. That way you are exactly at the same point then you was before. Briefly showing the recovery Key isn’t anything less optional. Just ignore it and you are safe. That being said for many users the risk of forgetting the password is much higher then accidentally leaking the key.
Interesting discussion. Most of it -and the excellent documentation- is clear. A few remarks for better understanding and (suggestions for) clarification.
(1) About the recovery key is written that it is another representation of the 256 bit keys. So, this means that the recovery key never changes for a given vault.
Is this correct?
(2) The documentation currently states: “Additionally for each vault exists a unique recovery key.”
Suggestion: “[…] for each vault a "recovery key may be generated on your request”
After all, as is clear from this thread, the recovery key does not exist anywhere (on your/any) system, unless the user himself chooses to keep it there, which is only possible after the recovery key is calculated at the moment he asks for it.
(3) Also, this means that a misplaced recovery key compromises a vault and this cannot be mitigated except by changing the vault 256 bit keys, which in turn would lead to a new recovery key. And that is only possible by re-encrypting the vault. So, if a user is worried about this, he simply can/must choose not to generate his recovery key.
Is this correct?
As in some systems one can (re)create recovery codes, maybe this could be clarified in the documentation.
At least “generating” or “deriving” implies that it doesn’t exist before, which is better than “to show/display” a recovery key. I guess for the end-user it doesn’t matter what is technically the correct term as long as it leads to the right mental model of how it works.
