Best practices for holding passwords in shell / Perl scripts?

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 inter

Answer 1

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.

Answer 2

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

Answer 3

It's a shame I never saw this thread before -- it looks very interesting. I'll add my two cents for anyone coming upon the thread in the future.

I'd recommend using OS authentication on the db server itself -- REMOTE_OS_AUTHENT is still FALSE.

If you're invoking the script from another machine, setup a phrase-less SSH key and use SSH to get there. You can then pipe back the SQL results to the calling machine and it can process this information further.

Doing this avoids having to code a password anywhere. Of course, if a malicious administrator were to hijack the phrase-less key and use it, he or she could also access the user account on the DB host and could then do any operations the OS authenticated DB user could. To mitigate this you could reduce the database permissions for that OS user to the bare minimum -- let's say "read only".

Ingo

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

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 6

There is no good solution. You can obfuscate the passwords a bit, but you can't secure them.

If you have control over your DB setup, you could try to connect by a named pipe (at least mysql supports that) without a password and let the OS handle the permissions.

You could also store the credentials in a file with restrictive permissions.