alanf@bruce.OZ (Alan Grant Finlay) (04/12/90)
I have written and distributed a public domain file encryption program for an MS-DOS/IBM-PC which asks for a password each time a file is processed. Since the password is kept only in memory and only in the space transiently assigned to the program (its not a TSR) I think it is reasonably safe. It is possible that a very small program could if run immediately after the encryption program capture the password and save it on disk either intentionally or for some obscure reason. In any case this is easily prevented (in the next version) by rubbing out the password before exiting. I understand that 80386 operating systems may take a copy of the "system area" to allow multiple workspaces to coexist (I'm not concerned why). This alerted me to the possibility that it may not be safe to keep a password memory resident as an environment variable. It was my intention to make the next version of the encryption program easier to use by providing the (default) option to run as a filter with the password kept in the environment of the current command interpreter. I had also considered the alternative of using a small and little used segment of RAM in the system area which is set aside for such a purpose. If copies of the system area proliferate all over the address space then neither scheme would not be safe. Even worse would be a virtual memory type operating system than keeps images of physical memory on secondary storage. Can anyone advise me of what the risks of password disclosure are with any common operating environments and any particulary risky combinations of systems and applications software. For example, are there any programs notorious for allocating a block of memory and copying it to secondary storage in its old state? Is it possible to get command.com to zero the memory occupied by its local copy of the environment, when it is exited?