Cleanup of sensitive filesystem data

Peter TB Brett peter.brett at
Sun Feb 8 01:20:36 CET 2015

On 2015-02-07 03:18, Andrew Kluthe wrote:
> I get that there might be threading issues with the messages in this
> series, but lawdy lawdy the signal to noise ratio is insane around here
> these days.

Hi Andrew,

In general, there's no way to have your cake (store unencrypted data in 
the filesystem) and eat it (prevent people from looking at it).  
Unfortunately this restriction applies no matter which programming 
language or environment you are developing in.  Please don't be upset 
with the other list members who have been explaining this.

Security is a priority for me, and thus I feel that I should contribute 
to this discussion.

The only way to be *sure* of the cleanup that you are requesting -- and 
of the simultaneous security of your unencrypted data -- is to store it 
*only* in memory and never allow it to be written to disk.

Another (inferior) option would be to use a wrapper process, where:

* The application the user launches is a very small shim that decrypts 
the data and launches your "real" application in a subprocess
* When the "real" application quits (for whatever reason) the shim 
deletes the data file.

Note that this can still be trivially circumvented by forcing the shim 
to quit, but at least by keeping the amount of code in the shim as small 
as possible you'll be able to minimize the risk of the shim itself 
crashing and leaving your data lying around.

You also mentioned cleaning up left-over files from previous 
instantiations of your program the next time it runs.  This is 
problematic.  Performing this operation requires a predictable naming 
scheme for your temporary files, but if you use a predictable naming 
scheme then there are a number of trivial attacks that can be made on 
your program to intercept its temporary files.

In summary, I recommend that you rethink your approach; avoid storing 
unencrypted, sensitive data in the filesystem.


Dr Peter Brett <peter.brett at>
LiveCode Engine Development Team

More information about the use-livecode mailing list