If you want to have a password that is unavailable to the user running your script, you can make the script setuid and the configuration file only readable to a specific user and group. Whether that makes sense strongly depends upon the specifics of your situation. It does not for me but there are cases where it would be appropriate.

I have a lesser known, but very interesting way of hiding a username and password from prying eyes, using only DBI, MySQL and Apache.

There are a few short steps to the process, but it is well worth it.

1. Configure your httpd.conf

   Go into your Apache httpd.conf, add the following lines, and restart the web server:

   SetEnv DBI_DSN DBI:mysql:db_name;mysql_read_default_file=/etc/my.cnf

   This will set the DBI_DSN environment variable for all your CGI scripts, globally. The value inside the DBI_DSN variable is used if you do not pass in the first argument to DBI::connect. Any code where you create a DBI handle can now become:

   my $dbh = DBI->connect;

2. Set your DBI handle attributes

   Before we move on, we will need to make sure of one thing: How do we set any of DBI's attributes? A common method of doing this is:

   my $dbh = DBI->connect(
     $dsn,
     $username,
     $password,
     { RaiseError => 1, ChopBlanks => 1, Taint => 1 }
   );
   [download]

   It is actually possible to include your database handle attributes inside the DBI_DSN, like so:

   DBI:mysql(RaiseError=>1,ChopBlanks=>1,Taint=>1):db_name;mysql_read_default_file=/etc/my.cnf

   Before we go on, you may want to go back and tweak your DBI_DSN inside the httpd.conf using this knowledge.

3. mysql_read_default_file

   You'll notice that in the DBI_DSN there is an attribute called mysql_read_default_file. This instructs MySQL where the location of the my.cnf configuration is that you'd like to use. The standard name for a MySQL configuration file is my.cnf.

4. Make your own my.cnf

   Here is a sample /etc/my.cnf MySQL configuration file:

   [client]
   username=my_username
   password=my_password
   [download]

   Inside this file you simply specify the username and password to connect to the database. Make sure you chmod 400 this file, preferably as root, to ensure that no one else can read it.

That's it, that's all there is to it. In all future CGI scripts don't supply any arguments to DBI::connect, and MySQL will use the defaults you have configured. By utilizing several interesting features of DBI, MySQL and Apache you have now centralized your database and user management, as well as providing a secure storage method for your usernames and passwords.

Also, some db, (mysql included) use a user's config file that can store the username and password to connect to. A bit more secure particularly if you make sure that the http server's user's home directory is outside the location of the pages to be served.

subclass DBI::MySQL to handle the connection phase for you. that way, other developers wouldn't necessarily need to know the password, if that's the concern.

this solution also makes it easier to handle any encryption you'll probably want to do later on, and requires one change in one place, not tons of changes all over.

developer code would look more like this:

#!/usr/bin/perl

use MyDBI;

my $dbh = MyDBI->db_logon();       # defined in MyDBI, obviously
my $sth = $dbh->prepare( 'SELECT * FROM foo ');
[download]

$uname = "asdf332112312adfasdf";
$pass = "wurtqeriotu1231211"; #assume these are encryped, not gibberis
+h :)
[download]

my $dbh = DBI->connect('DBI:mysql:database=audic;host=localhost', 
unencrypt_routine ($uname, $key),
unencrypt_routine ($pass, $key))
[download]

Bad idea. Anybody smart enough to look in the code to try and find the password will be smart enough to decrypt it.

Deletia
update I seem to have misunderstood what was happening, or misrepresented what my original thought on the matter was, or maybe just didn't explain well enough. Your --s have spoken loudly enough, and I will drop the subject...

updated

Sometimes it's unavoidable. You can move the password to a configuration file, but you still have to worry about the security of that file.

What you should have is a special login with read-only rights, and only to tables and views used by that script. So if a 'hacker' gets the username and password, there should be nothing compromised except the information that can normally be gotten from running the script. (Depending on what the script does, there may still be too much information to divulge to just anyone in the database.)