Sorry for the long post. Some ideas require a background explanation to fully convey the reason for the request and I try to offer solutions that you can modify or reject as you see fit. This issue started from the TrueCrypt documentation recommendations for using third-party extensions for Keyfiles which users then expanded to use on File Containers file extensions.
Background Regarding Request
Users tend to not read the documentation and rely solely on the application to warn them of any potential issues.
There are many posts on the forum of users losing access and/or loss of data to their VeraCrypt volumes due to third-party applications updating the metadata of a VeraCrypt file container or to a keyfile that is using the third party's file extension.
Sometimes the metadata is automatically updated without user intervention by the third-party application accessing the files based on its file type extension.
Other users reported incidents occurring when the user accidentally double clicks their file container or their keyfiles that is using a third-party extension which then launches the third-party application. This sometimes causes the file modification even if the user did not save any changes to the file.
Request for Change
I would like to purpose adding a topic to the documentation and add a pop-up warning message boxes in the application about the dangers of using a third-party file or third-party file extension whenever the user creates a file container, creates a keyfile, the selection of keyfiles when creating a volume and the selection of keyfiles during the password change process.
Application Change
For your consideration, three different warning pop-up message boxes when creating a file container, creating a keyfile or selecting keyfiles are shown below.
When Creating the File Container Pop-up Warning Message Box:
Avoid using a third-party file extension on a File Container which can cause one or more of the following issues:
The third-party application updating their metadata which overwrites part of the File Container.
Accidentally double clicking on a File Container that launches the third-party application which may update the metadata even if the user did not save any changes to the file.
Unable to mount the File Container due to damaged container.
May cause data loss after mounting volume due to damaged container.
When Creating a Keyfile Pop-up Warning Message Box:
Avoid using a third-party file extension on a Keyfile which can cause one or more of the following issues:
Impossible to mount the volume with a damaged Keyfile unless you have an exact backup of the unchanged Keyfile.
The third-party application updating the metadata which overwrites the first 1024 kilobytes used by VeraCrypt.
The user accidentally double clicking on a KeyFile that launches the third-party application which may update the metadata even if the user did not save any changes to the file.
When Selecting the Keyfiles During Volume Creation or Password Change Pop-up Warning Message Box:
Avoid using third-party files or files with a third-party file extension as a Keyfile which can cause one or more of the following issues:
Impossible to mount the volume with a damaged Keyfile unless you have an exact backup of the unchanged Keyfile.
The third-party application updating the metadata which overwrites the first 1024 kilobytes used by VeraCrypt.
The user accidentally double clicking on a KeyFile that launches the third-party application which may update the metadata even if the user did not save any changes to the file.
Documentation Changes
Keyfiles Topic Changes
I suggest removing from the documentation inherited from TrueCrypt, which is shown below, the recommendation for using third-party files and their extensions for Keyfiles and instead reference the new topic “Avoid Third-Party Files & File Extensions for File Containers and Keyfiles”.
Any kind of file (for example, .txt, .exe, mp3**, .avi) can be used as a VeraCrypt keyfile (however, we recommend that you prefer compressed files, such as .mp3, .jpg, .zip, etc).
New Documentation Topic: Avoid Third-Party Files & File Extensions for File Containers and Keyfiles
The new documentation topic title could be called “Avoid Third-Party Files & File Extensions for File Containers and Keyfiles” placed below the topic regarding Normal Dismount vs Force Dismount.
The new topic would contain the information shown below:
File Containers
Avoid using a third-party file extension on a File Container which can cause one or more of the following issues:
The third-party application updating their metadata which overwrites part of the File Container.
Accidentally double clicking on a File Container that launches the third-party application which may update the metadata even if the user did not save any changes to the file.
Unable to mount the File Container due to damaged container.
May cause data loss after mounting volume due to damaged container.
Keyfiles
When creating a Keyfile, avoid using a third-party file extension. When selecting Keyfiles during volume creation or when selecting Keyfiles during a password change, avoid using third-party files or files with a third-party file extension.
This can cause one or more of the following issues:
Impossible to mount the volume with a damaged Keyfile unless you have an exact backup of the unchanged Keyfile.
The third-party application updating the metadata which overwrites the first 1024 kilobytes used by VeraCrypt.
The user accidentally double clicking on a KeyFile that launches the third-party application which may update the metadata even if the user did not save any changes to the file.
Some examples of third-party files or file extensions to avoid for File Container and Keyfiles:
All media formats for picture, audio and video due to metadata getting changed by the third-party applications without user intervention.
Zip files due to easily modified.
Executable files due to patching or upgrading of vendors software.
Productivity software and their file extensions of products like Adobe, Microsoft Office, etc.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great suggestion to include in both the documentation and the pop-up warning message box for the VeraCrypt created Keyfile to set the attribute to read-only.
However, I have apprehension of recommending the changing of the VeraCrypt created Keyfile(s) to read-only since this could act as a marker that the file is used by VeraCrypt since other files in the same directory are not read-only. Or due to VeraCrypt created Keyfile being read-only, the user feels it is safe to change the Keyfile to use a third-party file extension which fails to open in third-party application which could act as a marker.
Last edit: Enigma2Illusion 2023-08-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are the concerns that always prevented me from using keyfiles since to me, they seemed too fragile to rely on.
Is it realistic to be cautious of using the read only attribute? If someone has sufficient access to your system to forensically check the attributes of files, you have a potentially serious issue. Yes they may not have admin access but they could likely find a way to do so e.g. unpatched software or displaying a UAC prompt that a user just clicks “Yes” to or enters their credentials.
Out of curiosity, what type of files should be used for keyfiles if 3rd party files aren’t recommended? Could the new EMV feature assist with this?
Thank you (feel free to ignore this post if its too off topic).
Last edit: AJ B 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The purpose of my request is to inform the users of the problems they can encounter by using third-party files and/or third-party file extensions for File Containers and Keyfiles.
Anything beyond that warning is the user's decision and the VeraCrypt software does not need, nor should be creating options which will be confusing to the user based on the warning to not use third-party files nor third-party file extensions.
Last edit: Enigma2Illusion 2023-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you @enigma2illusion for the detailed post and the time you took to elaborate on the concerns regarding third-party file extensions for File Containers and Keyfiles in VeraCrypt. I acknowledge the importance of the issues you've raised, especially in the context of potential data loss and complications arising from third-party software interventions.
Thank you also @fzxx for bringing up ReadOnly and recommended formats ideas.
Concerning pop-up warnings: Introducing warning pop-ups during certain processes in the application can be an effective reminder. However, over-alerting can cause users to ignore or get annoyed by these warnings. We need to find good balance.
Concerning documentation changes: I agree with your proposal on updating the documentation. I will work on this part.
Concerning read-only attribute: I agree with @enigma2illusion take on this. It's a double-edged sword, and we need to tread carefully. @fzxx suggestion of converting the attribute into an option might be a middle-ground solution, but again, this introduces additional complexities and potential areas for mistakes.
Concerning the recommended formats: Iit might serve as a guideline for those who insist on using them but I align more with @enigma2illusion's perspective, we should prioritize informing and educating our users.
I will update you about the progress of the changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your kind comments regarding my detailed request and pointing-out the issue of users ignoring the pop-up message box if displayed too frequently.
Your feedback had me review the three types of Keyfiles screens that are attached to this post and I discovered two of three types of Keyfiles screens were advocating using third-party files and third-party file extensions which likely inherited from TrueCrypt.
I propose the following changes to the Keyfiles screens to remove the bad advise and to hopefully improve user knowledge during usage of the various Keyfiles screens.
Remove the following sentence:
Any kind of file (for example, .mp3, .jpg, .zip, .avi) may be used as a VeraCrypt keyfile.
Improvements to the Keyfiles screens
The word "WARNING:" should be in the color red to draw the user's attention.
In an effort to prevent pop-up message annoyance, add the link to the documentation for "Avoid Third-Party Files & File Extensions for File Containers and Keyfiles" on the all three types of Keyfiles screens shown in this post to educate the users of the problems they can encounter by using third-party files and/or third-party file extensions for File Containers and Keyfiles.
Knowing the original topic title may be too long for including on the three types of Keyfile screens, you could use a short title "Avoid Third-Party Files & File Extensions" on the Keyfile's screens to the longer title "Avoid Third-Party Files & File Extensions for File Containers and Keyfiles" in the documentation.
EDIT:
Another shorter title to use in the three types of Keyfile screens:
Avoid Third-Party Files & Extensions
Last edit: Enigma2Illusion 2023-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think making the keyfile read-only is a bad idea from security point of view (as Enigma has suggested it will point to it as being used as a keyfile).
I thikn myself that the user should ALWAYS make backup, even multiple backups, of the keyfile. Keyfiles are small in size and the backups can be easily stored or even uploaded online and if used wisely, nobody will ever suspect these are keyfiles.
There is another point that is not really worrying me, but I am curious to know. If a keyfile is used from a HD and is obviously accessed many many times for many years, suppose the file is never moved by defragmentation process or anything, will it be possible through forensic analysis to find out that the particular sectors are really worn due to the access to the file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you @idrassi for your implementation of my request starting with 1.26.6 version.
Hopefully, less users will lose access and/or loss of data to their VeraCrypt volumes due to third-party applications updating the metadata of a VeraCrypt file container or to a keyfile that is using the third party's file extension.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi @idrassi
Sorry for the long post. Some ideas require a background explanation to fully convey the reason for the request and I try to offer solutions that you can modify or reject as you see fit. This issue started from the TrueCrypt documentation recommendations for using third-party extensions for Keyfiles which users then expanded to use on File Containers file extensions.
Background Regarding Request
Users tend to not read the documentation and rely solely on the application to warn them of any potential issues.
There are many posts on the forum of users losing access and/or loss of data to their VeraCrypt volumes due to third-party applications updating the metadata of a VeraCrypt file container or to a keyfile that is using the third party's file extension.
Sometimes the metadata is automatically updated without user intervention by the third-party application accessing the files based on its file type extension.
Other users reported incidents occurring when the user accidentally double clicks their file container or their keyfiles that is using a third-party extension which then launches the third-party application. This sometimes causes the file modification even if the user did not save any changes to the file.
Request for Change
I would like to purpose adding a topic to the documentation and add a pop-up warning message boxes in the application about the dangers of using a third-party file or third-party file extension whenever the user creates a file container, creates a keyfile, the selection of keyfiles when creating a volume and the selection of keyfiles during the password change process.
Application Change
For your consideration, three different warning pop-up message boxes when creating a file container, creating a keyfile or selecting keyfiles are shown below.
When Creating the File Container Pop-up Warning Message Box:
Avoid using a third-party file extension on a File Container which can cause one or more of the following issues:
When Creating a Keyfile Pop-up Warning Message Box:
Avoid using a third-party file extension on a Keyfile which can cause one or more of the following issues:
When Selecting the Keyfiles During Volume Creation or Password Change Pop-up Warning Message Box:
Avoid using third-party files or files with a third-party file extension as a Keyfile which can cause one or more of the following issues:
Documentation Changes
Keyfiles Topic Changes
I suggest removing from the documentation inherited from TrueCrypt, which is shown below, the recommendation for using third-party files and their extensions for Keyfiles and instead reference the new topic “Avoid Third-Party Files & File Extensions for File Containers and Keyfiles”.
https://www.veracrypt.fr/en/Keyfiles%20in%20VeraCrypt.html
New Documentation Topic: Avoid Third-Party Files & File Extensions for File Containers and Keyfiles
The new documentation topic title could be called “Avoid Third-Party Files & File Extensions for File Containers and Keyfiles” placed below the topic regarding Normal Dismount vs Force Dismount.
The new topic would contain the information shown below:
File Containers
Avoid using a third-party file extension on a File Container which can cause one or more of the following issues:
Keyfiles
When creating a Keyfile, avoid using a third-party file extension. When selecting Keyfiles during volume creation or when selecting Keyfiles during a password change, avoid using third-party files or files with a third-party file extension.
This can cause one or more of the following issues:
Some examples of third-party files or file extensions to avoid for File Container and Keyfiles:
Creating a key file,Add read-only attribute.
Great suggestion to include in both the documentation and the pop-up warning message box for the VeraCrypt created Keyfile to set the attribute to read-only.
However, I have apprehension of recommending the changing of the VeraCrypt created Keyfile(s) to read-only since this could act as a marker that the file is used by VeraCrypt since other files in the same directory are not read-only. Or due to VeraCrypt created Keyfile being read-only, the user feels it is safe to change the Keyfile to use a third-party file extension which fails to open in third-party application which could act as a marker.
Last edit: Enigma2Illusion 2023-08-22
Hi Enigma2Illusion,
These are the concerns that always prevented me from using keyfiles since to me, they seemed too fragile to rely on.
Is it realistic to be cautious of using the read only attribute? If someone has sufficient access to your system to forensically check the attributes of files, you have a potentially serious issue. Yes they may not have admin access but they could likely find a way to do so e.g. unpatched software or displaying a UAC prompt that a user just clicks “Yes” to or enters their credentials.
Out of curiosity, what type of files should be used for keyfiles if 3rd party files aren’t recommended? Could the new EMV feature assist with this?
Thank you (feel free to ignore this post if its too off topic).
Last edit: AJ B 2023-08-25
The purpose of my request is to inform the users of the problems they can encounter by using third-party files and/or third-party file extensions for File Containers and Keyfiles.
Anything beyond that warning is the user's decision and the VeraCrypt software does not need, nor should be creating options which will be confusing to the user based on the warning to not use third-party files nor third-party file extensions.
Last edit: Enigma2Illusion 2023-08-23
Thank you @enigma2illusion for the detailed post and the time you took to elaborate on the concerns regarding third-party file extensions for File Containers and Keyfiles in VeraCrypt. I acknowledge the importance of the issues you've raised, especially in the context of potential data loss and complications arising from third-party software interventions.
Thank you also @fzxx for bringing up ReadOnly and recommended formats ideas.
Concerning pop-up warnings: Introducing warning pop-ups during certain processes in the application can be an effective reminder. However, over-alerting can cause users to ignore or get annoyed by these warnings. We need to find good balance.
Concerning documentation changes: I agree with your proposal on updating the documentation. I will work on this part.
Concerning read-only attribute: I agree with @enigma2illusion take on this. It's a double-edged sword, and we need to tread carefully. @fzxx suggestion of converting the attribute into an option might be a middle-ground solution, but again, this introduces additional complexities and potential areas for mistakes.
Concerning the recommended formats: Iit might serve as a guideline for those who insist on using them but I align more with @enigma2illusion's perspective, we should prioritize informing and educating our users.
I will update you about the progress of the changes.
Hi @idrassi
Thank you for your kind comments regarding my detailed request and pointing-out the issue of users ignoring the pop-up message box if displayed too frequently.
Your feedback had me review the three types of Keyfiles screens that are attached to this post and I discovered two of three types of Keyfiles screens were advocating using third-party files and third-party file extensions which likely inherited from TrueCrypt.
I propose the following changes to the Keyfiles screens to remove the bad advise and to hopefully improve user knowledge during usage of the various Keyfiles screens.
Remove the following sentence:
Improvements to the Keyfiles screens
Knowing the original topic title may be too long for including on the three types of Keyfile screens, you could use a short title "Avoid Third-Party Files & File Extensions" on the Keyfile's screens to the longer title "Avoid Third-Party Files & File Extensions for File Containers and Keyfiles" in the documentation.
EDIT:
Another shorter title to use in the three types of Keyfile screens:
Last edit: Enigma2Illusion 2023-08-25
I think making the keyfile read-only is a bad idea from security point of view (as Enigma has suggested it will point to it as being used as a keyfile).
I thikn myself that the user should ALWAYS make backup, even multiple backups, of the keyfile. Keyfiles are small in size and the backups can be easily stored or even uploaded online and if used wisely, nobody will ever suspect these are keyfiles.
There is another point that is not really worrying me, but I am curious to know. If a keyfile is used from a HD and is obviously accessed many many times for many years, suppose the file is never moved by defragmentation process or anything, will it be possible through forensic analysis to find out that the particular sectors are really worn due to the access to the file?
By setting other file attributes,
Obfuscate the location of the key file.
@enigma2illusion: I have update the documentation as you proposed (with some changes) and I set the keyfiles warning text in red as you can see in the attached screeshot (I cannot display only a work of the sentence in red).
Here is the commit: https://sourceforge.net/p/veracrypt/code/ci/7f3a6cb978cd53bbf144b79ce04fd4d5b2091e2b/
And here is the new documentation page: https://veracrypt.fr/en/Avoid%20Third-Party%20File%20Extensions.html
I still need to add link to the new documentation entry to the keyfiles dialog. I will implement this in the coming days.
@idrassi
I appreciate your remarkable mastery of condensing, clarifying and improving the ideas from my proposal.
Outstanding work on the documentation and screen changes!
I look forward to your inclusion of the new "Avoid Third-Party File Extensions" documentation link on the various screens.
Thank you @idrassi for your implementation of my request starting with 1.26.6 version.
Hopefully, less users will lose access and/or loss of data to their VeraCrypt volumes due to third-party applications updating the metadata of a VeraCrypt file container or to a keyfile that is using the third party's file extension.