I am not sure who thought that it was a good idea to leave the most important file you need to open you vault just lying there for anyone/anything to delete. Its quite baffling to me also that it given the generic name masterkey. Bad actors come in different forms, and one group falls into the access denial category. For them this creates the perfect opportunity to do harm.
I would like to suggest that if this file has to be lying around in plain sight then maybe give it the name of the specific vault it is for and remind users to store a copy somewhere safe in case it is lost
1 Like
The masterkey isn’t more valuable than the data. This is a common misconception, but unless you understand this important fact, it is pointless to argue.
It might surprise you that an attacker could still delete your data even if the masterkey was absent, but you have to face the reality: Encryption protects your privacy, it doesn’t make data indestructible.
1 Like
@afarikofi didn’t say that the masterkey is more valuable than the data. He said that the file is the most important to open your vault. In fact, it is not only the most important, it is essential, obviously.
The scenario he is concerned with is something like:
An attacker discovers your vault, steals the masterkey file (whose function is widely known) and deletes it. Then he send you an email: “if you want your masterkey back, transfer U$ to this bitcoin account”.
Congratulations, a different type of ramsonware is created.
He specifically gets het up over the “obvious” name of the file inviting attackers to delete it and thereby implicitly postulates that they wouldn’t do it otherwise. While in fact they can destroy as well as lock anything, once they gain access.
True, but again: It is impossible to make data indestructible by cryptographic measures. If you are concerned about availability, make backups. Cryptomator has its own recovery key feature and creates backups of this file itself. You’re also free to create as many additional backups of this file as you like. You can even store them publicly. After all, the filename makes you aware of the importance of this file (you’re welcome).
If it was called pineapple.json or stored somewhere “hidden” (as some people suggest it), what do you think, how many users would either loose or delete it because they don’t recognize it being an important file?
This is a matter of risk assessment and demanding ineffective solutions for problems that are not even in scope of the security target while introducing lots of potential for user-provoked data loss is not helping (even if his request wasn’t rude or off-topic in an unrelated thread).
1 Like
The point with the file names was that it is well known that what people see sometimes directs their train of thought. So an attacker looking for something valuable whilst trawling through a set of files will easily be drawn to this whereas if it were named a little more obscurely they might skip it. This in itself is a form of security. Also lets say i have 6 vaults…each of these have a file called masterkey. Maybe its just me but wouldnt it make a bit more sense to be able to name the file after the name of the vault if just for ease of use?
The aim of this is to reduce the attack surface. We all know the vault itself can be deleted and so encryption doesnt guard against that. But losing data is different from data being held for ransom which is what @TowerBR referred to. Anyway i didnt expect any angst from my comment. Being new to crytomator i was just wondering because with all the others i checked (veracrypt, onedrive vault, boxcryptor) i didnt see any masterkey or something similar. But whichever way you look at it, that masterkey file presents a risk.
Is not even encrypted btw.
Yes, I understood your intend. But as explained before, this would not be effective. Let’s ignore everything I wrote before about the negative impacts this would have in regards of users not understanding the importance of this file:
If you think that attackers were just wandering around on your disk until they stumble upon something that “looks interesting”: This is not how it works. Maybe script kiddies that seek to do some damage act this way, but you are talking about a hypothetical ransomware that specifically targets Cryptomator and “steals” the masterkey file while leaving all other files untouched despite apparently having write access and therefore being able to deploy a “generic” ransomware (which isn’t worth it from a financial perspective to beginn with).
Even if said file had a non-deterministic name, such targeted attacks would still be able to distinguish it from other files by its metadata and structure unless applying steganography to all files (which again is a different field of applications).
All this effort while there is a simple solution to it all: Backups.
Just for the sake of completeness: There are other rationales for having a “non-obvious” name, such as plausible deniability.
Okay, I agree with your arguments. Each type of software has its function.
The solution to fix (not prevent) a ramsonware attack (or loss/corruption of the masterkey file) is backup.
However I have seen some requests here and on Github about the possibility of choosing the location of the masterkey file, some people even labeling it as a two-factor authentication (the second factor being the fact that you “have” the masterkey file). I understand the difficulties with mobile/sync.
Perhaps what solves all this is the possibility for advanced users to change this setting (the location), which would not affect basic users who would not even change it.
BTW, gocryptfs/cppcryptfs have this option.
About plausible deniability, I think it is an important feature to be implemented. I saw the topics here and issues on Github, and it seems that a conclusion has not yet been reached. It’s so important that it has always been on Truecrypt/Veracrypt, just as an example. It has its use cases … but I think this is a subject for another topic.
Giving users this flexibility is certainly the best option to satisfy most use cases. I guess you refer to discussions like this:
We are in the process of refactoring some code related to key entry, which will also allow external key management solutions. Once rolled out, this will also enable things like FIDO. That said, we need a new vault format which supports storing required metadata.