Since you probably want others to be able to run the program (either via web or command line), what you have to do is make one program be a front end to a daemon process which runs continuously and holds the key in memory (in a variable). This is quite non-trivial since you then have to make (and authenticate) connections to the daemon.

Although people (on slashdot, especially) like to point out the possible DRM abuses of TCPA and Microsoft's Palladium, it does have legitimate uses like solving this difficult problem.

This is a cool idea. Each time you start up the daemon process you must type in the key. The Daemon then acts as an API to the files in the filesystem. If you wanted to get tricky, you could then start caching the encrypted/plain text files (depending on your security requirement) in memory for faster access...

I like this idea for a few reasons:

1. The key is not stored anywhere except in memory
2. The api then becomes extensible such that you can add extra functions such as change_key.
3. All the logging can be done implicitly by a framework that is in place.

On the downside tho' there must be a human nearby who can enter the password each time the daemon process is stopped, crashes, the machine goes down etc, etc... Also the key may get paged out at some point...

For access, you could combine SSL (https:) and Basic Authorization. That, coupled with logs, can give you a record of who changes what. You're still relying on your end users to not leak (or share) passwords.

On the server side, if you want the system to have unencrypted access to the data, you have to decide how to handle your keys. A worst-practice is to embed keys into scripts. This can be bad because every so often an exploit appears that lets users see script source.

A somewhat better practice is to place keys in a configuration file that isn't visible to the web server (i.e., in a file that can't be reached via a URL).

A worst-practice is to embed keys into scripts. This can be bad because every so often an exploit appears that lets users see script source.

I think a bigger concern than an exploit would be the possibility that another employee within the organization, who has access to view the source code, might take advantage of the keys to do something unwanted.

In every company I've worked for, there's been much less stringent security applied to viewing scripts than to other activities like logging in to databases, launching scripts to live websites, etc. In the corporate world, lazy server administrators often give temps and low-level employees access to much more information than they need or should be able to see.

Before you even worry about some hypothetical software flaw whereby a user might view your script over the Internet, think carefully about restricting the set of people in your company who might have unfettered access to whatever keys or other sensitive information you're hoping to conceal.

--Kevin