We value your feedback and please allow me to inform you that we have discuss this issue with the engineers and it is not a vulnerability, we have confirmed with the engineers that the software works as programmed. I followed up on their response outlining this, and that the application should at least give a warning or ideally refuse to exit if it is unable to remove any temporary files it creates, but was met with the following response: They also state that the user would receive a pop-up telling them that the file could not be deleted, however this was not the case in any of my testing. I wasn’t satisfied with that response, while I understand their stance that they do need to store plain-text copies of files on disk temporarily so that user applications can interact with them, the software should at least warn the user if there is the possibility that these plain text copies might be left on the disk. Please feel free to reply to this email if you have any other concerns. When this happens, the user gets a popup warning telling him that the file could not be deleted. When the file is locked, there is no way we can remove it or shred it. When the application closes, the file should be removed. This implies that they are unencrypted and accessible at that specific moment, otherwise Word and Excel cannot work on then.
We need to write a clean copy of the file to some temp space where applications like Word and Excel can access them, and where they can be checked by a virus scanner before they are opened. Please be informed the application is ‘as designed’.
We sincerely appreciate you sharing your feedback and pointing this out for us to know. Thank you for contacting SanDisk® Global Customer Care. I received the initial response from the vendor in just six days which stated the following: Communication with vendorĪfter discovering this issue I reported it to the vendor, SanDisk, on the 5th of November and waited for a response. Thus a user who uses SecureAccess fairly regularly is much more likely to end up with some plain-text copies of their files sat on their disk. In standard operation this directory is not emptied unless the user explicitly empties it, either by deleting the content manually or using some other utility. This is exacerbated by the way that Windows handles the “%TEMP%” directory. As SecureAccess creates a plain-text copy of the encrypted file on disk, if the program exits unexpectedly (program crash, power failure, or the user ends the process) the routine to delete the temporary files does not run, so any files you’ve opened during that session remain on disk in plain-text. Contents of the temp dir after closing the appĪ similar issue exists if the application crashes when the user has a file open.
0 kommentar(er)
