Hi,
as pointed out in this previous post , 2FA at the unlock level may not help if the end-point is compromised.
What I am suggesting is that the password is required to unlock the folder structure and filenames (as is already the case now), but in order to decrypt a file, a smart card (with an OpenPGP key for instance) is needed. Some smart cards, like the Yubikey, require the user to touch the key in order to approve a decryption request. This means that every time you decrypt a file, you need to touch the smart card. So even if your system is compromised, you will not expose more than one file, instead of exposing the entire vault.
In the case of users for whom the exposure of any of their encrypted files might cause them to lose their life savings, be executed, or imprisoned this might be an acceptable workflow.
For everyone else, I think this would pose an intolerable usability burden. File decryption in the virtual file system is probably happening much more often than you realize. Take the Windows Explorer, for example. There is an option to preview the file contents as you navigate through the list of files.
Obviously this requires file decryption. Would you want to have to do something manually to approve each previewed file as you move through the file list?
For any edge cases where such extreme protection is needed, I think some form of manual, independent encryption on a file-by-file basis is more suitable. Here, I assume only a few files would demand such extreme treatment. The extra workflow would be unrelated to Cryptomator.
I’m suggesting it as an option that users can enable, so no one has to use it. It allows you to get access to a file even when you don’t have access to an end-point you trust 100%.
On any endpoint you trust 100%, for instance one that you are currently using to unlock your vault, you can always install the master key, and therefore not require the smart card nor the associated physical touch (or you could disable the “require touch” option on your smart card for the time you’re using that endpoint).
Losing a collection of files can have a bad outcome even when losing a single one wouldn’t matter much. Take identity theft for instance: if you have a copy of your IDs, some utility bills, payslips and bank statements in your Cryptomator vault, losing your utility bill is no big deal. However with the sum of these files, someone has a good chance of opening an online bank account in your name and launder money.
Keep in my I am not a developer here, just engaging in a discussion on this topic.
A couple things:
-
If your data store is compromised (e.g. people are somehow tampering with the files or deleting them) your only protection is to have a back-up. Cryptomator will detect when a file has been tampered with but does not give you the authentic file back (again back-ups).
-
You talk about installing the master key on an endpoint you trust. If the endpoint houses a Cryptomator vault, that master key is already there. Here I am speaking about the Cryptomator master key, not an external master key in some new protocol you might be proposing. Ideas have been proposed to house the Cryptomator master key in locations separate from the data but that has not been done. FWIW I agree with keeping it with the data; if a long, secure password is used (as it should be), this should pose no risk to the security of the data.
So to conclude, when you speak about the risks of losing your data, the only safeguard is a secure alternate back-up of your data. If you instead are talking about the risks of your data being exposed, the best protection is a very secure password. 2FA and similar schemes do not help, as has been discussed in the threads you referenced. The reason they don’t help is that they only can help when the absence of valid 2FA authorization blocks access to the data. But here, you have made the assumption that the attacker already has your data, albeit in encrypted form.
Sorry, I should have said exposed rather than losing. I am not referring to any files getting deleted. When I spoke about the master key I was talking about of the PGP certificate (or similar - there surely is better than PGP, but I’m no expert in that). As initially said, I’m considering the case where the endpoint is compromised.
You can have the strongest password in the world but if your endpoint is compromised then ALL your data is exposed the moment you unlock your vault. Having 2FA at the time of unlocking the vault doesn’t help (as already mentioned).
That’s why I suggest to have the second factor authentication when an individual file gets unlocked. This can be achieved, for instance, by a smart card, as it can be set to require a physical touch. An attacker can’t extract the master key from a smartcard, so he won’t be able to decrypt more files. The worst he can do is to make you decrypt file B while you wanted to decrypt file A, but he will still only get one file, and you would notice that immediately. This is because the user has to approve the decryption of each file individually on the smartcard. Therefore, even on a compromised endpoint, you will not expose all of your vault, but only the number of files you confirmed via the smart card. With such a setup, the master password could simply act as a filename and folder structure scrambler, as the files are already encrypted by the smart card.
Let me summarize the suggested setup to get files A and B from your vault:
- Type in your masterpassword (as is the case at the moment)
- decrypt file A: tap your smartcard to confirm
- decrypt file B: tap your smartcard to confirm again
Hence, files A, B will be exposed on the system, but none of the other files (C, D, …) will (except for their names).
Why is it better than now? Because files C, D, etc. stay encrypted.
I see (I think). It seems as if you are referring to a compromised end-user computer, i.e. the one the user is working on where and while the vault is unlocked.
Interestingly, I have written a decryptor program which seems to fit the need you describe. You can look it over, though you’ll have to be a .Net developer with Visual Studio to do so: Cryptomator Access Demo
It does not prompt for each decryption but each decryption is a manual step; there is no behind the scenes decryption taking place as would be the case in a file system.
To me, what you describe might be a useful tool but my personal opinion is it is a different usage scenario than what Cryptomator provides, since the whole objective in Cryptomator is to provide a mounted file system on top of the encrypted file structure. But I do understand now the use case you were describing; perhaps some other observers may want to respond.