>When you have automated tasks ... say a program that connects to an SMTP server to send an automated email ... where do you hide the passwords and keys used for this?
>
>In other words, the scenario above would require a user name and password that we would most likely store in a dbf. However, we would want to encrypt the password so that users couldn't grab the dbf and open it with some other program to get the password.
>
>BUT, to encrypt the password requires some sort of key. The key can't be stored unencrypted in a table or you defeat the purpose of encrypting the password. If you hardcode the key in the program, a simple text editor viewing the .exe can yield the key.
>
>We could hide the key in the registry, but it should still be encrypted (which means we'd need another key ... endless loop). Also, I haven't done much work with registries so I'm not sure if one computer can pull values from another computer's registry (if they're both part of the same domain)? (Our app resides on a file server (Novell at this point but moving to MS) and all the users run the app from there. So it would make sense to store the key on the server but can the user's machine access the registry of the server?)
>
>It just seems like eventually, you come down to the point where you have to have one key that is not encrypted. Surely there's something better/more secure than this?

You might be able to encrypt your entire app using a key only you know, using some product like KonXise or ReFox from Xitech.

It might be possible to store credentials on a hardware "dongle". One example is http://www.safenet-inc.com/products/sentinel/superpro.asp

Another approach is to ask for the credentials when your program starts. Rather than storing the user name and password themselves, you can store an MD5 hash of those values. It is almost impossible to reconstruct a string from its MD5 hash so it's fairly safe to store those hashes in your app.

When the user enters the user name and password, you MD5Hash() them, and compare the results to the stored values. If correct, you store the entered values to app object properties, memvars, etc. (but not to disk).

There are two downsides to this approach:

1. It requires user intervention each time the program starts. Not good for something that is to run as a service that starts automatically at machine boot.

2. There are programs that can "spy" on the contents of memory of other programs running on the same machine. Using one, it may be possible to extract the user name and password. However, this would probably defeat most casual hack attempts.