in reply to making perl more forgetting

Only Ambrus has come close to what I see as the obvious solution to your problem. With an encrypted filesystem , even if another process can get disk access nothing will make the slightest sense. You can page encrypt RAM so that even if they break into your page they see gobbledegook. It slows the system down a bit. Maybe the best thing to do is encrypt the CC numbers at source with a public key (so it doesn't matter that the key is in plain view). The only code that can ever see the real data is the terminal process in the chain. (this assumes you do no intermediate processing on the data). BSD and a little known Tinfoil Hat linux both sport examples of encrypted fs.

As other posters have said, the issue of security is kind of subsumed into whether your server is secure. It's encouraging that you don't consider even local processes friendly, this is healthy paranoia. At the end of the day you have to store your private key somewhere, and if you cant extend your trust to that machine its no game.
Andy

Replies are listed 'Best First'.
Re: Re: making perl more forgetting
by diotalevi (Canon) on May 17, 2004 at 19:33 UTC

    With an encrypted file system, why is one process able to see it but another cannot? Did you mean to imply that this other process only ran at times that the other program wasn't in memory and the file system wasn't mounted?

    The question seemed to assume that the rogue process would run concurrently with the process with the secrets and with the ability to peek at the memory of the process with the secrets. Wouldn't a process with that sort of rights also have access to any file system the other process did?

    What of getting the secret from the program that has the unencrypted data before it goes encrypted?