You can obscure the information in the Perl code in various ways, but anyone who can read the code can execute the same operations to translate it back. For example, if the password consists of only lowercase alphabetic characters (as, sadly, too many do) a simple rot13:
$ perl -lwe '
use strict;
my $password = "abcdefg";
$password =~ y/a-z/n-za-n/;
print $password;
'
nopqrst
(You can extend that to include uppercase, digits 0-9 with rot5 y/0-9/5-90-4/, and other characters similarly y/!@#$%^&*(){}[];:<>,./{}[];:<>,.!@#$%^&*()/)
Other possibilities include using pack/unpack, Data::Serializer, etc. You can store the obscured data in a separate file and read it in before de-obscuring it.
To keep the password off the command-line and thus out of ps -ef and equivalents, many commands have an option to prompt for the password. For those, something like echo $password | command -p may work. Other commands - mysql is one - will not accept the password that way. For some of those, Expect can be used.
None of these will keep a determined person from getting the information; they merely make him work a little bit more. They are, however, slightly better than plaintext passwords in the code. | [reply]
[d/l]
[select] |
In the case of mysql: mysql can read a password (and other command line options) from a configuration file. No need to pass mysql passwords on the command line.
| [reply] |
The best answer is, of course, "don't pass passwords on the command line!". However...
You can change how your process appears in ps output by assigning to $0, like so:
#!/usr/bin/perl
use strict;
use warnings;
$0 = 'renamed';
sleep 600;
Run this and you will have 10 minutes to look at ps and see that the process appears as renamed, not as whatever you saved the program as.
If you meant that your Perl code is calling other ftp/database scripts and passing username/password on the command line, then it's those other scripts that would need to do this (or something similar) to mask their command lines. The only way you'd be able to hide that information from the caller's side would be for your Perl to invoke them in interactive mode and use something like Expect to log in as if it were a human user running the (other) script. | [reply]
[d/l]
[select] |
If I remember correctly, not every OS supports assigning to argv[0] a.k.a. $0. Some OSes have limitations for assigning to it. See $0 in perlvar. Simply emptying @ARGV could also work on some OSes.
The best way is not to have passwords at all, but use public keys instead. Second best solution is to have passwords in a file readable only for the owner. Third best solution is to have passwords in configuration files.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
| [reply] |