in reply to Obscuring sensitive data in Perl code?

You could also use environment variables. That way, it wouldn't matter who saw your script:

my $user   = $ENV{ORACLE_USER};
my $passwd = $ENV{ORACLE_PASS};
my $SID    = $ENV{ORACLE_SID};
my $dbh = DBI->connect($SID,$user,$passwd,{PrintError=>0, AutoCommit=>
+0})
  or die "Could not connect to $SID: $DBI::errstr\n";

[download]

This also allows you to change the instances, usernames, passwords, etc. without having to edit your script.

Replies are listed 'Best First'.
Re: Re: Obscuring sensitive data in Perl code?
by Madams (Pilgrim) on Mar 10, 2001 at 07:34 UTC
    Eeek.......! Using environment variables for sensitive data is bad, bad, bad!!!!!!!
    type env at a prompt and wala...out pops the data!!!!!
    _________________
    madams@scc.net 
                  (__)
              (\/)
       /-------\/
      / | 666 ||
     *  ||----||

    [download]
[reply]
[d/l]
[select]

      Yes, but if you someone already has shell access to *that* account, then there is already a bigger problem. If I create a script like the above, and make it chmod 755, nobody is going to get the sensitive data unless they are logged in as me, althought anyone can read (and run) the script themselves. You can even use very restricted accounts (e.g. no shell access) for more security. The point is, you completely separate the sensitive data from the script. I like this particular way because I can do something like this in .bashrc: 

      alias oradev='export ORACLE_SID=dev; export ORACLE_PASS=foo; \
  export ORACLE_PASS=bar; echo Set instance to development'

      [download]

      ...which allows easy interchange of instances, passwords, and other parameters from the command line. Nothing wrong with setting good permissions on an included file, either, but if you can run/read the script, you can track down and read the passwords.

[reply]
[d/l]

In Section Seekers of Perl Wisdom