Cleanup of sensitive filesystem data
Peter TB Brett
peter.brett at livecode.com
Sat Feb 7 19:20:36 EST 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.
Peter
--
Dr Peter Brett <peter.brett at livecode.com>
LiveCode Engine Development Team
More information about the use-livecode
mailing list