Securely using password as bash argument

Question

Hi, I'm extracting a part of a web application that handles the signup, the other part will be rewritten.

The idea is the signup part can exist as a separate application, interface with the rest of the application for creating and setting up the account. Obviously there are a ton of ways to do this, most of them network based solutions like SOAP, but I'd like to use a simpler solution: a setup script.

The concern is that certain sensitive data, specifically the admin password of the new account, would be passed through bash.

I was thinking of sharing a small class between the applications, so that the password can be passed already hashed, but I would also have to pass the salt, so it still seems like a (small) security risk. One of the concerns is bash logging (can I disable that for a single command?) but I'm sure there are other concerns as well?

This would be on the same private server, so the risk seems minimal, but I don't want to take any chances whatsoever.

Thanks.

Answer 1

Use the $HISTFILE environment variable, unset it (this is for all users):

echo "unset HISTFILE" >> /etc/profile

Then set it back again.

More info on $HISTFILE variable here: http://linux.about.com/cs/linux101/g/histfileenviron.htm

Hope this helps!

Answer 2

From the man page of bash:

HISTIGNORE A colon-separated list of patterns used to decide which command lines should be saved on the history list. Each pattern is anchored at the beginning of the line and must match the com- plete line (no implicit ‘*’ is appended). Each pattern is tested against the line after the checks specified by HISTCONTROL are applied. In addition to the normal shell pattern matching characters, ‘&’ matches the previous history line. ‘&’ may be escaped using a backslash; the backslash is removed before attempting a match. The second and subsequent lines of a multi-line compound command are not tested, and are added to the history regardless of the value of HISTIGNORE.

Or, based on your comment, you could store the password in a protected file, then read from it.

Answer 3

Passing the salt in clear is no problem (the salt is usually stored in clear), the purpose of the salt is avoiding the same password hashing to the same hash always (so users with the same password would have the same hash, and rainbow tables would only need a single hash for each possible password).

What is more problematic is passing sensitive data through command line arguments, an eavesdropper on the same box can see the arguments to any command (on Linux they appear on /proc//cmdline, and on most Unixes can be seen using ps; some systems restrict permissions on /proc// to only the owner of the process for security).

What you could do is pass the sensitive information through a file, don't forget to set the umask to a very restrictive setting before creating the file.

Answer 4

Bash doesn't normally log commands executed in scripts, but only in interactive sessions (depending on appropriate settings). To show this, use the following script:

#!/bin/bash
echo "-- shopt --"
    shopt | grep -i hist
echo "-- set --"
    set -o | grep -i hist
echo "--vars --"
    for v in ${!HIST*}
    do
        echo "$v=${!v}"
    done

Run it like this:

$ ./histshow

and compare the output to that from sourcing it like this:

$ . ./histshow

In the first case take note that HISTFILE is not set and that the set option history is off. In the second case, sourcing the script runs it in your interactive session and shows what your settings are for it.

I was only able to make a script keep an in-memory history by doing set -o history within the script and to log its history to a file by also setting HISTFILE and then doing an explicit history -w.