|
Re: Obscuring sensitive data in Perl code?
by chromatic (Archbishop) on Mar 10, 2001 at 01:19 UTC
|
See DBIx::Password, which exists precisely for that purpose.
Have the system administrator restrict its access to the user under which Apache/mod_perl run, ie 'www' or 'nobody'. | [reply] |
Re: Obscuring sensitive data in Perl code?
by merlyn (Sage) on Mar 10, 2001 at 00:42 UTC
|
Don't put them in the source. Put them in a separate file, and pull in that file. Then be very careful whom you show that file to.
-- Randal L. Schwartz, Perl hacker | [reply] |
|
|
++, but still, what is to stop someone from doing this to the original script: (pseudo-code)...
my $db_password = get_password("filename");
print $db_password; # someone could insert this...
my $dbh = DBI->connect(.....);
I don't think there is any way around this is there? Security through obscurity (while obviously bad for other reasons) falls down on this issue too.
$ perldoc perldoc | [reply]
[d/l] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: Obscuring sensitive data in Perl code?
by Tuna (Friar) on Mar 10, 2001 at 00:42 UTC
|
would this help to point you in the right direction? | [reply] |
Re: Obscuring sensitive data in Perl code?
by reyjrar (Hermit) on Mar 10, 2001 at 01:14 UTC
|
You could also use Getopt::Std and have a -u username -p password option.
what I typically do, is while I'm developing I'll:
my $USERNAME = $OPTS{'u'} || "username";
my $PASSWORD = $OPTS{'p'} || "password";
then once I move it into production I'll take out the "|| 'username'"'s and add checks for the username/password in the code and die if they're not there. Unfortunately though, you have to have your passwords decrypted in plain text somewhere.
When I do things with DBI, I use the database privileges system to give JUST enough rights to the user that my scripts can do what they need from where ever. As an example, lets say I have a database "network" and a table "devices" and I just need my script to get information from that database. I know my script is running on 192.168.0.5 then I can (in MySQL)
GRANT SELECT ON network.devices TO script@192.168.0.5;
FLUSH PRIVILEGES;
and while you might not be administering this database, any good DBA will work with you to grant your script user _JUST_ the privileges it needs to do whatever it has to do.
This isn't possible with DBI but things like ssh have "publickey authenication" so you might want to sniff around for information on varying authentication methods.. If you're logging into a linux server, you might wanna read up on Pluggable Authentication Modules (PAM).
just a few ideas..
-brad.. | [reply]
[d/l]
[select] |
|
|
Eek! Bad idea. If you specify your password with -p, anyone on the system can probably see it with `ps`.
| [reply] |
|
|
not with a secured /proc filesystem ;) only root could see it..
| [reply] |
Re: Obscuring sensitive data in Perl code?
by turnstep (Parson) on Mar 10, 2001 at 03:00 UTC
|
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";
This also allows you to change the instances, usernames,
passwords, etc. without having to edit your script.
| [reply]
[d/l] |
|
|
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 ||
* ||----||
| [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'
...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] |
