search

cryptomator / cryptofs

Java Filesystem Provider with integrated encryption
GNU Affero General Public License v3.0
94 stars 35 forks source link

Backup: Make the key file more robust to modifications #61

Closed infeo closed 5 years ago

infeo commented 5 years ago

Version: 1.8.6

Short Description

If the masterkey file is replaced, the backup file should not be overwritten at the next unlock and rather a new one should be created. It is suggested to add a truncated SHA256 value of the corresponding masterkey file to the backup filename.

Description

cryptofs is creating a backup of the masterkey file in the case the original gets corrupted. This backup is written every time the vault is successfully unlocked. If now the masterkey file gets accidently overwritten (creating a new vault in the existing one), the content of the vault cannot be read anymore and due to the successful unlock also the backup will get overwritten.

The idea is now to link the backup fail directly to a specific masterkey file by adding a truncated SHA 256 value of the masterkey file to the backup name.

The affected code would be : https://github.com/cryptomator/cryptofs/blob/3ce8537eb84f887d608c3e2d9396308898bccb71/src/main/java/org/cryptomator/cryptofs/CryptoFileSystemModule.java#L28-L34

infeo commented 5 years ago

There is a security issue regarding the suggested change:

If the user changes its password of the vault, a new masterkey file will be generated and therefore a new backup file. In the end there would be two backup files in the vault and overall two valid passwords opening the same vault.

@overheadhunter What are your thoughts about this problem?

overheadhunter commented 5 years ago

If the user changes its password of the vault, a new masterkey file will be generated and therefore a new backup file. In the end there would be two backup files in the vault and overall two valid passwords opening the same vault.

This holds true even before the change, since in most scenarios some kind of backup is involved that allows restoration of the old file.

Our assumption here has to be that if a user wants to upgrade the password strength, he/she decides for re-encryption with a completely new key. At least this is what we always tell people who ask about this topic in support mails or in the forum.

tl;dr: Proceed. Benefits outweigh concerns.