April 23, 2021 at 07:14 #20488
This post is related to this one: https://forum.axcrypt.net/forums/topic/is-it-possible-to-change-location-of-axcrypts-temporary-folder/
I have read that post and I know that right now it is not possible to change the location of the temporary directory where AxCrypt decrypts the file, but I would like to request that this possibility be implemented in a future version, I think it would not be very difficult to implement the change in the application (it would be a parameter in your configuration) and I think it would increase security a lot.
So that you understand the problem, I am going to show you an example:
Imagine that you are working on a shared computer. You are working with an important document that was encrypted with AxCrypt, for example a Word document, and suddenly the power goes out or a system crash occurs and it restarts.
As I understand that the application works right now, the document would have been decrypted in a directory within the C:\Users\User_Name\AppData\Local\AxCrypt folder. The AxCrypt application cannot delete the contents of that directory when Windows starts again, otherwise it would lose all the changes made by the user in the document before the power outage or system crash.
But then there is a security problem: the file has been decrypted in that directory, so an attacker (or the system administrator) could access it. The file would not be cleaned until the user reopened the encrypted file, AxCrypt would detect that the file was already decrypted, it would not overwrite it and would allow the user to save the changes and close the file for AxCrypt to encrypt it again and delete the file temporary.
But until the user does that, there is a security problem, the file is decrypted on the hard drive, in the temporary directory, so, as I said before, an attacker or the system administrator could access it.
To solve this problem I propose the following solution that I consider easy to implement: that it be allowed to change the temporary directory where AxCrypt decrypts the file, so that, for example, we could place it in a virtual volume encrypted for example with VeraCrypt (successor to TrueCrypt) or another similar application, in such a way that the temporary file was always created inside the encrypted virtual volume. In this way, if the power goes out or the system crash and the computer restarts, the virtual volume is automatically dismounted and no one can access the temporary file that AxCrypt has created. The user could log back in, mount the encrypted virtual volume again, and retrieve the document where he left it with AxCrypt.
Even though it obviously poses a risk and only makes sense for read-only files, if we wanted to increase security even more, we could mount a virtual RAM Disk unit and locate the temporary directory there, in such a way that, in the event of a crash from the system, the decrypted file would disappear instantly after restarting the computer and no one would be able to access it.
This example that I have just mentioned is also valid if, for example, for some reason the application with which we were editing the file does not close correctly and remains a zombie in the system. We close the application, the application disappears from the screen, but we do not find out that the application has not closed well and has been frozen in the system, so it does not get to unlock the file and AxCrypt does not encrypt the temporary file and deletes it, so again the temporary file remains in the directory without the user knowing. Yes, I know that in the AxCrypt application you can see the files that are locked, but normally we don’t look at it.
So in this case again the file has been decrypted in the temporary directory. The user shuts down the system believing that his document has been correctly encrypted but has remained in the temporary directory, so we have the same security problem as before.
Or imagine, for example, that for some strange reason an internal crash occurs in AxCrypt and it closes instantly, it will have left the decrypted files in the directory. The user shuts down the system thinking that everything is fine, but the files have remained there decrypted.
As I say, all these problems can be solved if it is allowed to change the path where the temporary directory with the decrypted file is created, in such a way that it can be located on an encrypted volume or on a virtual RAM Disk drive. In this way, when rebooting the system, the temporary files that have been decrypted by AxCrypt could not be recovered by an attacker in any way.
I think it is an easy option to implement in the application, a configuration parameter that can be changed from the application and that refreshes when starting it, so changing it would not have an effect until restarting the application, I do not think it would cost much to implement and as I say it would improve the security of the application.
It is also that if you are working with a volume or drive encrypted with VeraCrypt or a similar application, it does not make sense, from a computer security point of view, to place the decrypted temporary file on a decrypted volume or drive, the logical thing is that the decrypted temporary file is created on the encrypted volume or drive to protect it as well.
ChemaJune 25, 2021 at 15:07 #21516
I see what you’re saying, and I’ve created a task to look int adding an option of choosing temporary storage locations. There are also other reasons, such as limited space and similar, where this could be useful.
No promises when (or if) this will be implemented, but I can promise we’ll have a look at it.