Handling passwords and sensitive data

zzspectrez has asked for the wisdom of the Perl Monks concerning the following question:

The otherday, I discovered a security issue that is pretty obvious but which I had not considered before. I was running a perl script on my linux box as a privelaged user while also logged on as an unprivelaged user. I needed to kill a process. So I did ps aux to discover the pid. Well I noticed that in this output I was looking at the command line of the script running under my other login which was happy to share its password for all to see.

Got me to thinking of how many scripts I have wrote that used something like the following code:

#!/usr/bin/perl -w
use strict;

my $username = shift;
my $password = shift;


do_something($username,$password);

sub do_something {
  my ($user,$pass) = @_;
  print "USER: $user\nPASS: $pass\n\n";
}
[download]

I cant think of how many simple scripts I have written that use this simple method of getting a username and password. It's hard to not write something like this because its easy to write and easy to use. Almost all of my web scripts I use to download my current bank statements, or download mail, etc use this method. 98% of these scripts I run on my home machine which for all purposes is a single user machine so it is not a big issues that the password from the command line is displayed. But on a multi-user system would be something to be concerned about and possibly overlooked.

So this gets me to thinking.. What is the best way to handle passwords or semi-secure data like this. The following are my ideas.

Read the data from <STDIN> and disable the screen echo for the password. This works effectively but has the side effect that it requires someone to type in the password making unusable for automated scripts run by cron or from other scripts.

#!/usr/bin/perl -w
use strict;

my ($user, $pass) = get_password ();

do_something ($user,$pass);

sub do_something {
  my ($user,$pass) = @_;
  print "\nUSER: $user\nPASS: $pass\n";
}

sub get_password {
  $ENV{'PATH'} = "/bin:/usr/bin";
  print "Username: ";
  my $username = <STDIN>;
  chomp $username;
  print "Password: ";
  system ('stty -echo');
  my $password = <STDIN>;
  system ('stty echo');
  print "\n\n";
  return ($username,$password);
}
[download]

Another solution would be to have a config file containing the username and password in the users home directory which is only readable by the user. This would enable the script to be run safely and automated. However this requires an additional config file for each user who runs the program.

#!/usr/bin/perl -w
use strict;

my ($user,$pass) = get_secret();

do_something($user,$pass) if ($user) && ($pass);

sub do_something {
  my ($user,$pass) = @_;
  print "USER: $user\nPASS: $pass\n\n";
}

sub get_secret {
  my $config = $ENV{'HOME'} . '/.passwd3';
  
  if (-e $config) {
    my ($pass,$user);
    my $perms = (stat ($config))[2] & 07777;
    die "ERROR: File permissions not 700.\n" unless $perms == 0700;
    open INP, $config or die "ERROR: Couldn't open file: $!\n";
    chomp ($user = <INP>);
    chomp ($pass = <INP>);
    close(INP);
    return($user,$pass);
  }else{
    die "ERROR: No config file.\n";
  }
}
[download]

What do you do!?

THANKS!
zzSPECTREz

Comment on Handling passwords and sensitive data Select or Download Code

Replies are listed 'Best First'.
Re: Handling passwords and sensitive data by eg (Friar) on Jan 27, 2001 at 13:25 UTC
I always try to prompt for passwords (like your second example) but I usually also leave in a command line option to specify the password, in spite of the risk. One thing I do to minimize my exposure is to assign to `$0` as soon as possible. It's not at all secure, but depending on your application, the added convenience might be worth it. `#!/usr/local/bin/perl -w BEGIN { my $filename = $0; $0 = $filename; }` [download]	[reply] [d/l]
Re: Handling passwords and sensitive data by wardk (Deacon) on Jan 27, 2001 at 14:00 UTC
I like the config file in $HOME directory scenario. chmod it 640 or 600. seems the problem here is the passing of passwords on a command line. don't do this. recently at work I executed the w command to see who was logged on, and found out the system password for our oracle database. aparently one of the dba's didn't want to suffer through being prompted for the password during a SQL*Plus session. just shows that all the security in the world can't protect you from a reckless user.	[reply]
Re: Re: Handling passwords and sensitive data by zzspectrez (Hermit) on Jan 27, 2001 at 19:28 UTC
Yeah.. I discovered command line bad!! :) Its so convenient that you dont think about the security risk.. Thanks for pointing out that err in my code. Obviously I meant 640 not 700. Config files dont need to be executed! zzspectrez	[reply]
Re: Re: Re: Handling passwords and sensitive data by wardk (Deacon) on Jan 27, 2001 at 22:59 UTC
for managing config files, check out: AppConfig Config::IniFiles have fun!	[reply]
Re: Handling passwords and sensitive data by jepri (Parson) on Jan 27, 2001 at 14:01 UTC
Read the data from STDIN and disable the screen echo for the password. This works effectively but has the side effect that it requires someone to type in the password making unusable for automated scripts run by cron or from other scripts. Not so. In any reasonable shell: `perl my_prog.pl < password.txt` [download] works fine. But it breaks cross-platform scripts, so your config file example is much better. ____________________ Jeremy I didn't believe in evil until I dated it.	[reply] [d/l]
Re: Handling passwords and sensitive data by clemburg (Curate) on Jan 27, 2001 at 22:42 UTC
For really sensitive scripts, IMHO your best bet as the script author is: always ask for the password. No config files, no commandline parameters, no environment variables. In a really sensitive environment, someday somebody will try it. If he succeeds because your code was careless, people will be angry at you. And they will be right. With tools like Expect running around for free, your users can always automate interaction with your script, even if it gets complicated and the simple solution jepri gave won't work anymore. Just make it the user's choice/responsibility. Christian Lemburg Brainbench MVP for Perl http://www.brainbench.com	[reply]
Re: Handling passwords and sensitive data by Fastolfe (Vicar) on Jan 27, 2001 at 23:45 UTC
I've come across this very behavior in other applications. Not Perl scripts written by average-quality developers, but non-Perl enterprise-quality web content management systems, costing tens of thousands of dollars. I threw a fit when their command-line maintenance utilities required usernames and passwords be passed via command-line switches. I quickly re-wrote a lot of the maintenance scripts to prompt for the password interactively, but there are still lesser-used stuff that we'll still need to do it with. Thankfully no developers or anyone outside my small operations group has shell access to these machines. As far as prompting the user for a password, check out `perldoc -q password` for ideas the FAQ has.	[reply] [d/l]
Re: Handling passwords and sensitive data by AgentM (Curate) on Jan 28, 2001 at 01:14 UTC
The mysql client docs describe an ad hoc way to get rid of this (of course, this client does not force you to use the command line option for the password either). It simply deletes @ARGV right after initialization! `@ARGV=();` [download] after you've extracted the relevant information of course- or just copy it to a different array. (I give no personal guarantees that this works with Perl, though, since I only know this to work under C.) Of course, this still may leave a millisecond or too where Bob Schnob can still execute ps aux and get your passwd, but the chances that he'll be able to synchronize are slim. FYI, FIPS (1989) explicitly prohibits unprivileged users to see ANY other users' ps table- but we all know that a ps aux is all it takes to see that Bob Schnob is downloading porn again. In fact, I see this as a security risk (obviously, others don't) and I would love to see a kernel with at least an option to hide the process tables from prying eyes. Unfortunately, Linux kernel code hacking would turn my head inside out, so I'll leave it to the folks who know what's going on. If I've missed yet another kernel update in which this is implemented, I'd be much obliged to be informed. Thanx. AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.	[reply] [d/l]
Re: Re: Handling passwords and sensitive data by Fastolfe (Vicar) on Jan 28, 2001 at 02:22 UTC
I would love to see a kernel with at least an option to hide the process tables from prying eyes. Unfortunately, Linux kernel code hacking would turn my head inside out, so I'll leave it to the folks who know what's going on. Sorry, this isn't very Perl-ish, but to offer an answer to this, it may be as simple as this: `--- linux/fs/proc/base.c.orig Sat Jan 27 15:18:24 2001 +++ linux/fs/proc/base.c Sat Jan 27 15:19:19 2001 @@ -497,3 +497,3 @@ E(PROC_PID_STATUS, "status", S_IFREG\|S_IRUGO), - E(PROC_PID_CMDLINE, "cmdline", S_IFREG\|S_IRUGO), + E(PROC_PID_CMDLINE, "cmdline", S_IFREG\|S_IRUSR), E(PROC_PID_STAT, "stat", S_IFREG\|S_IRUGO),` [download] Of course, I don't have a Linux system I'm willing to test this with, and I don't know if it will break any other /proc-based tools or 'ps' itself if it can't read the command line for processes the user doesn't owns. I'd be interested in seeing if that works though. An interesting variation would be to use `S_IFREG\|S_IRUSR\|S_IRGRP`, which would give users in the same group the ability to see the command line as well, but nobody else.	[reply] [d/l] [select]
Re (tilly) 2: Handling passwords and sensitive data by tilly (Archbishop) on Jan 28, 2001 at 02:05 UTC
A brief test shows that this does not work in Perl. But eg's suggestion of assigning to $0 does.	[reply]


Don't ask to ask, just ask
	PerlMonks

Handling passwords and sensitive data

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.