Re: DBI & CGI Security

[jayrom]

What I do for the DB auth info is put the login and password in a text file outside the web server realm.
You can open the file from your DB login script and parse it to retrieve the login and password.
Something like this:

my $file = '/path/db.txt';
open FILE, '<', $file or die $!;
chomp(my ($auth) =  <FILE>);
my ($dbuser, $dbpasswd) = split('\t', $auth);
close FILE;

Hope this helps.

jayrom

[bradcathey]

I have followed this exact scenario, though I encrypt it with Crypt::CBC. Here's how my code looks:

my ($username, $keyfile, $domain) = @_;

open (PASS, "</home/$username/$keyfile") or die "Error: $!\n";
   flock (PASS, 2);
   my @keypass = <PASS>;
close (PASS);    

foreach (@keypass) {
   chomp $_;
}

my $cipher = Crypt::CBC->new($keypass[0], 'Blowfish');
my $dbpass = $cipher->decrypt($keypass[1]);

use DBI qw(:sql_types); 

my $userdatabaseName = "DBI:mysql:$domain";
my $userdatabaseUser = $username;
my $userdatabasePw = $dbpass;

$dbh = DBI->connect($userdatabaseName, $userdatabaseUser,
$userdatabasePw, { RaiseError => 1},) or die "Connect failed: $DBI::er
+rstr\n";

I also recommend the aforementioned O'Reilly's "CGI Progamming with Perl." And take a look at this node on CGI and passwords.

[jayrom]

I like the way you used encryption. I also often forget to lock the file when I only read it ;-)

This may be a silly question, and it doesn't mean to be ironic, but does encryption make a difference?
Indeed having a text file with the db auth on the server is only slightly better than having it in a script within the web server realm.
But, if you bear with me, if someone gets access to that file couldn't we assume that they also had access to the script? Also given that the key has to be included somewhere, how hard would it be to figure out the whole thing?
Should we encrypt the auth by default for the sake of good security practice?

jayrom

[bradcathey]

Points well taken jayroom. I agree, it's not a perfect set-up. The bottom line is that I doubt one can develop a completely ironclad system, as many discussions here at the Monastery will attest to. I think of security as a layered affair. I used to hard code my DB passwords right into the script, so, I'm doing one better here. I don't think there is any one silver bullet. The more barriers you put up, the harder you make it for the nefarious crackers to get in. Hopefully that is not too naive.

I was thinking about my e-commerce sites, and combination of the secure certificate, the remote keys, and wondering if scenerios like that are workable. It's a good discussion to keep going—I'd love to see a definitive answer so I don't feel like the little boy sticking my fingers in the latest leak in the dike.

[fizbin]

One note with that code is that you may want to structure it something like this:

use vars qw[$dbuser $dbpass $dbsecret_time];

my $secretfile = '/path/db.txt';
my $secretfile_modtime = stat($secretfile)[9];
if (!$dbsecret_time or $dbsecret_time < $secretfile_modtime)
{
  open FILE, '<', $file or die $!;
  chomp(my ($auth) =  <FILE>);
  ($dbuser, $dbpasswd) = split('\t', $auth);
  close FILE;
  $dbsecret_time = $secretfile_modtime;
}

The reason is that if you ever want to run this code under mod_perl or something similar, you probably won't want to hit the dbpass/secret file more often than necessary.