I think I'll go snag something I can adapt from the Obfuscated Code page, stick it in a module, and hope for the best...

Just treat that second file as sacred. Don't let people get at it.

-- Randal L. Schwartz, Perl hacker

Sorry, I deserved that, for being a bit flip in my answer... Didn't mean to imply obfuscation was an acceptable security practice...

What I was getting at was just this: The best I can do is set permissions for my script as 0700. For my script to be able to read the secondary file, the permissions on the secondary file most likely would be 0600 with the same owner as my script. So if that user account is compromised, anyone who can read my script can read the secondary file too. At that point I'm basically hosed, so I might as well do what I can and hope the cracker isn't a Perl hacker...

For the Apache server, I will definitely look into DBIx::Password as suggested by chromatic.

No. Wrong. See my discussion of setgid/setuid programs a few sections below.

You don't have to set your code to 0700 to make it secure. Make the data 0060 and make your setgid code do a thorough authentication before it reads the data file.

You don't have to worry about the group being compromised, because you don't even need to have any members in this group. No one can read the data except your program. If you build sufficent security into the program, you're all set.

(This time I remembered to log in...)

buckaduck

Please take no offense, but there is a bit of fault in your logic.

If someone has access to that one account, why don't they have access to root as well? Most likely they do. Especially if the machine is set up well, so that root is the only user that can get access to that account. At that point don't worry about the perl script or the files that you're working on. Worry about the machine (rm -rf /).

Hoping that the cracker isn't a particular type is about the worst security you can carry, since crackers come in more flavors than unix.

Hope This Helps,
jynx

Make your program setgid and make it owned by a new group such as "wwwpass". Hide your database username/password combo in a separate file which can only be read by the group "wwwpass".

Now only your program can read the file. Before it does, have your program authenticate the user somehow. If this authentication fails, just terminate the program. If it passes, go ahead and read the sensitive data from that external file.

This way, even if a user finds out where the sensitive data is hidden, he can't read it unless he uses your program and passes your authentication test.

You can use setuid instead of setgid if you must, but I personally feel safer using setgid and using a new group name which is dedicated to this task alone.

The only drawback to all of this is that you must now ensure that your program will pass "taint" checks. But is that really a drawback?

Buckaduck

Excellent scheme, thanks! Sorry I overlooked it in the first round of replies! I think a combination of this method and DBIx::Password used in the appropriate spots will work very well.

why should they have access to the secondary file??
If you're on a server, you can easily set permissions for files, and you can put the file somewhere unreachable by others without proper permission.

As you can encrypt the passwords