Best practices for holding passwords in shell / Pe

Question

I've recently had to dust off my Perl and shell script skills to help out some colleagues. The colleagues in question have been tasked with providing some reports from an internal application with a large Oracle database backend, and they simply don't have the skills to do this. While some might question whether I have those skills either (grin), apparently enough people think I do to mean I can't weasel out of it.

So to my question - in order to extract the reports from the database, my script is obviously having to connect and run queries. I haven't thus far managed to come up with a good solution for where to store the username and password for the database so it is currently being stored as plaintext in the script.

Is there a good solution for this that someone else has already written, perhaps as a CPAN module? Or is there something else that's better to do - like keep the user / password combo in a completely separate file that's hidden away somewhere else on the filesystem? Or should I be keeping them trivially encrypted to just avoid them being pulled out of my scripts with a system-wide grep?

Edit: The Oracle database sits on an HP-UX server.
The Application server (running the shell scripts) is Solaris.
Setting the scripts to be owned by just me is a no-go, they have to be owned by a service account that multiple support personnel have access to.
The scripts are intended to be run as cron jobs.
I'd love to go with public-key authentication, but am unaware of methods to make that work with Oracle - if there is such a method - enlighten me!

Answer 1

Best practice, IMHO, would be to NOT hold any passwords in a shell / Perl script. That is what public key authentication is for.

Answer 2

If the script is running remotely from the server.

1. Make your reports views
2. Give the user you are logging into ONLY access to select on the report views
3. Just store the password.

That way, all that the user can do, is select the data for its report. Even if someone happened to get the password, they would be limited as to what they could do with it.

Answer 3

Personally I hold passwords in configuration files which are then distributed independently of the application, and can be changed to the specific machine/environment. In shell scripts you can source these within the main script.

However, in Perl there are a variety of approaches. You may wish to investigate Getopt::Long for command line options (and additionally Getopt::ArgvFile to store those in a simple configuration file), or look at something like Config::IniFiles for something with a little more power behind it. These are the two types I generally use, but there are other configuration file modules available.

Answer 4

In UNIX, I always make these scripts setuid and store the user and password info in a file that's heavily protected (the entire directory tree is non-readable/searchable by regular users and the file itself is readable only by the owner of the script).

Answer 5

On windows create a Folder and a File within it containing the passwords in clear text. Set the user who would run the scheduled job(script or batch) as the only person with read/write access to this folder and file. (remove even administrator). To all other scripts, add code to read the clear text password from this restricted file.

This should suffice for few.

Keywords: Password HardCoding

Answer 6

I'm not sure what version of Oracle you are running. On older version of Oracle (pre 9i Advanced Security) some DBA's would CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY and set REMOTE_OS_AUTHENT to true.

This would mean that your remote sun machine could authenticate you as SCOTT and then your Oracle DB would accept that authentication.

This is a bad idea.

As you could image any Windows XP with a local user of SCOTT could then log into your DB without a password.

Unfortunately it's the only option that i know of Oracle 9i DBs to not store username/passwords in your script or somewhere else accessible by the client machine.

What ever your solution it's worthwhile having a look through Oracle's Project Lockdown before committing.