Quote Originally Posted by JeenLeen View Post
I don't enough about how computers generally work to even understand what "set up a RAM disk for a logfile" means, but I know enough programming that I could envision a fairly easy program* that could scan a text file and delete information you don't want saved.
There are certain programs which can cordon off a section of the computer's RAM and then register it as a storage device with the operating system, allowing the computer to treat that section of memory like a hard drive. This virtual disk is called a RAMdisk. It's a useful trick for high-end gaming rigs with lots of memory, since you can preload the game onto the disk and run it from there.

Quote Originally Posted by JeenLeen View Post
If you set up the other work, perhaps you could have a subroutine in your keylogger that scans for things of a certain format and deletes them from the record. Examples could be numbers that are as long as a credit card number, numbers in 555-55-5555 format for Social Security Numbers, and you could probably set up something like "if I type <my username here>, delete it and the next 15 characters" to delete usernames and passwords. You could of course hard-code for it for delete the passwords themselves, but that means having your passwords saved in a program, which seems a bad security idea; with the aforementioned, only your usernames are hard-coded.

*well, easy conceptionally. Actually programming the code to scan a text file, remembering where you are, deleting text, etc., then recombining it would probably take me a couple hours to write and debug. From the languages I know, it would be quite a pain to get the initial scan function written and acting as desired, but once it's figured out for one 'format for something you want deleted', should be easy to add additional targets. And, if you're lucky, the language you use's SCAN function (or equivalent) might be built to easily allow you to use it without much augmentation.

EDIT: after re-reading the post, I figured I'd note that I realize this doesn't make it 'reject' the sensitive info, but rather it saves the sensitive stuff then deletes it. Which probably has it somewhere in memory, at least until the equivalent to 'garbage is really recycled' happened. But at least it'd be harder to find. Maybe not worth the effort.
I do like the way you're thinking, but the technical problems you mention are all solvable by selecting a language which doesn't rely on garbage collection and by utilizing regex expressions in place of the scan function. You could also employ buffering and a finite state automata to examine data as it comes in and determine whether it constitutes sensitive data or not. In doing so, you could filter it out and prevent it from ever being written to the hard disk in the first place.

More problematic is the reliance on humans behaving in a predictable manner. A simple example might be if I misspell my username but correctly spell my password. According to our rules, it would save that information to the log file. Or what if I misspell my password, realize my mistake, hit backspace, and re-enter my password, resulting in a full or partial password being written to the disk. Or what if the user enters some sensitive information not known to the program to be sensitive (such as a routing and account numbers)? Or what if the user just fails to configure the program correctly?

Stuff like that. I think there's an adage, something along the lines of "No program survives contact with the user". Consequently, the higher art of programming is ensuring the program works the way you intend it to, not just the way you write it to.

Personally, I've just gotten into the habit of pressing Ctrl-A and Ctrl-C before submitting something.