Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
Hi, I have a perl script which, using DBI:odbc, logs onto a database. My MD is not very happy about having the password sitting around and I dont blame him. How can I obfuscate the password? Is there a hash or encryption method people use? Most of these scripts are compiles into .exe using active state dev kit then called on machine start up by windows server 2003 scheduler. I could pass an encrypted password, but i have no idea what module to use or where/how to store the key or how the perl script will look it up. Does anyone have any ideas on this?
Re: hiding database passwords
by moritz (Cardinal) on Dec 13, 2007 at 19:41 UTC
|
The short answer is: There's no secure way.
You can store it encrypted, but then you'd have to store the key as well - which is pointless.
You can't have a secret in your executable that nobody can retrieve if he can read the executable. The same holds true for Perl scripts.
The only thing you can do is to fiddle with your operating systems file permissions, but that depends on your use case. | [reply] [Watch: Dir/Any] |
Re: hiding database passwords
by naChoZ (Curate) on Dec 13, 2007 at 20:20 UTC
|
moritz gave you the right answer. But if you're just looking for a simple way not to have to hard code a password into your script, I usually do something like this. I keep a file in my home directory, in this example ~/.ldap.secret, protect with file permissions so that only I (or root / administrator) can access the file, then run a snippet like this (which is probably more complicated than necessary):
my $ldap_password = fetch_ldap_password({ filename => $ENV{HOME} . '/.
+ldap.secret' });
# ...
# {{{ sub fetch_ldap_password
#
sub fetch_ldap_password {
my $args = shift;
die "No password file specified\n" unless defined $args->{filename
+};
my $filename = $args->{filename};
my $password;
open( PW, "<$filename" )
or die "Error opening bindpw file $filename: $!\n\n";
foreach ( <PW> ) {
chomp;
$password = $_;
}
return $password;
}
This doesn't negate anything moritz said, the password is still essentially just sitting around to anyone with permission. But at least you don't have to hard code it. For a script that will be run by multiple people, the script should be using a database username that has been configured with adequate granted permissions on the database side itself to meet the needs of the script accessing the db.
--
naChoZ
Therapy is expensive. Popping bubble wrap is cheap. You choose.
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: hiding database passwords
by kyle (Abbot) on Dec 13, 2007 at 20:53 UTC
|
| [reply] [Watch: Dir/Any] |
Re: hiding database passwords
by olus (Curate) on Dec 13, 2007 at 20:07 UTC
|
Is it possible to create one user on the database that has permissions to see only one specific table?
Maybe playing with db roles and grants would let your MD more comfortable. | [reply] [Watch: Dir/Any] |
|
Oh boy, I was really tired yesterday when I replied to your question. I had spent the day looking a logs that when you said your script logged onto a database, I just took it as if what you needed was to write log info, hence the insert permissions on a single table.
Having DB credentials spread around is a natural concern, and as others already said, there is no absolute truth about hidding them on your scripts.
To that concern, I'm still of the opinion that part of the solution is on the DB side.
Depending on the work that the script is supposed to do, the user it uses to log into the DB should have strict access policies.
So, if it has to read information, it should have access only to views to the information. If it needs to write, it should talk to some stored procedures that actually work on the affected tables.
This would make things safer, as that user has limited possibilities of messing around with the DB.
This will not be possible on all databases, but where possible, you have an alternative or second level of protection if used together with the other solutions.
| [reply] [Watch: Dir/Any] |
Re: hiding database passwords
by CountZero (Bishop) on Dec 13, 2007 at 21:54 UTC
|
Everything depends of course ...If the compiled scripts are on an unsecured machine, meaning anyone can have access to it, then nothing you do is secure. Anyone with a little perseverance will be able to retrieve your passwords. On the other hand if the compiled scripts are on a computer to which only trusted people have access, what is there to fear? Even the suggestion to keep the log-in IDs and passwords in a config file, stored away in a secure location gives only a false sense of security. Once you know the name and location of the config file (and one can retrieve that info from any file which accesses the database through the "config" trick) you can write your own script which uses the same access method. The only secure way is to prevent access to any script or program which makes a connection to the database. So, put your computers away in a safe server room and isolate them from the network, so neither physical access nor network access is possible but for trusted people.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] [Watch: Dir/Any] |
Re: hiding database passwords
by SuicideJunkie (Vicar) on Dec 14, 2007 at 16:17 UTC
|
How about storing the password in a file and having your script read that file to connect...
Then, keep the password file on a floppy or USB key that is stored in a locked safe when not in use. Paint it neon red and/or glue bells to it if you like.
| [reply] [Watch: Dir/Any] |
|
|