Is there a way to pass sensitive data in bash using a prompt, for any command?

Question

Suppose that I were using sha1pass to generate a hash of some sensitive password on the command line. I can use sha1pass mysecret to generate a hash of mysecret but this has the disadvantage that mysecret is now in the bash history. Is there a way to accomplish the end goal of this command while avoiding revealing mysecret in plain text, perhaps by using a passwd-style prompt?

I'm also interested in a generalized way to do this for passing sensitive data to any command. The method would change when the sensitive data is passed as an argument (such as in sha1pass) or on STDIN to some command.

Is there a way to accomplish this?

---

Edit: This question attracted a lot of attention and there have been several good answers offered below. A summary is:

• As per @Kusalananda's answer, ideally one would never have to give a password or secret as a command-line argument to a utility. This is vulnerable in several ways as described by him, and one should use a better-designed utility that is capable of taking the secret input on STDIN
• @vfbsilva's answer describes how to prevent things from being stored in bash history
• @Jonathan's answer describes a perfectly good method for accomplishing this as long as the program can take its secret data on STDIN. As such, I've decided to accept this answer. sha1pass in my OP was just an example, but the discussion has established that better tools exist that do take data on STDIN.
• as @R.. notes in his answer, use of command expansion on a variable is not safe.

So, in summary, I've accepted @Jonathan's answer since it's the best solution given that you have a well-designed and well-behaved program to work with. Though passing a password or secret as a command-line argument is fundamentally unsafe, the other answers provide ways of mitigating the simple security concerns.

Answer 1

Ideally, you never type a clear-text password on the command line as an argument to a command. Doing so makes the password an argument to the command, and command line arguments may be seen in the process table by using simple tools like ps or logged into some audit logs.

Having said that, there are certainly ways of hiding the actual password from the shell's command history.

sha1pass "$( head -n 1 )"

Then type in the password and press Enter. The head command used here accept exactly one line of input and the last newline that you type will not be part of the data that is passed to sha1pass.

To prevent the characters from echoing:

sha1pass "$( stty -echo; head -n 1; stty echo )"

The stty -echo command turns off echoing of the typed characters on the terminal. The echoing is then restored with stty echo.

To pass on standard input, that last command could be altered (you would have done this if sha1pass accepted data on standard input, but appears as if this particular utility is ignoring its standard input):

{ stty -echo; head -n 1; stty echo; } | somecommand

If you need multi-line input (the above assumes a single line should be passed, with no newline character at the end), then replace the whole head command with cat and terminate the input (assuming somecommand itself reads until end-of-file) with Ctrl+D (following Return if you want to include a newline character in the input, or twice if not).

This would work regardless of what shell you were using (as long as it was a Bourne-like or rc-like shell).

Some shells may be made to not save the typed-in commands in their history files if the command is preceded by a space. This usually involves having to set HISTCONTROL to the value ignorespace. This is supported by at least bash and ksh on OpenBSD, but not by e.g. ksh93 or dash. zsh users may use the histignorespace option or their HISTORY_IGNORE variable to define a pattern to ignore.

In shells that support reading with read without echoing characters to the terminal, you may also use

IFS= read -rs password     # -s turns off echoing in bash or zsh
                           # -r for reading backslashes as-is,
                           # IFS= to preserve leading and trailing blanks
sha1pass "$password"

but this obviously still has the same issue with potentially revealing the password in the process table.

If the utility reads from standard input, and if the shell supports "here-strings", the above could be changed to

IFS= read -rs password
somecommand <<<"$password"

---

Summary of comments below:

• Executing a command with a password given on the command line, which all of the commands above does, except the one that pipes the data to the command, will potentially make the password visible to anyone running ps at the same time. None of the commands above will however save the typed-in password in the shell's history file if executed from an interactive shell.

• Well behaved programs that reads clear-text passwords do so by reading from their standard input, from a file, or directly from the terminal.

• sha1pass does requires the password on the command line, either typed in directly or using some form of command substitution.

• If at all possible, use another tool.

Answer 2

If using the zsh or bash shell, use the -s option to the read shell builtin to read a line from the terminal device without it echoing it.

IFS= read -rs VARIABLE < /dev/tty

Then you can use some fancy redirection to use the variable as stdin.

sha1pass <<<"$VARIABLE"

If anyone runs ps, all they'll see is "sha1pass".

That assumes that sha1pass reads the password from stdin (on one line, ignoring the line delimiter) when not given any argument.

Answer 3

If you set HISTCONTROL like so:

HISTCONTROL=ignorespace

and start the command with a space:

~$  mycommand

it won't be stored in the history.

Answer 4

Pass sensitive data via a pipe or here-doc:

command_with_secret_output | command_with_secret_input

or:

command_with_secret_input <<EOF
$secret
EOF

It's fine for secrets to be in (non-exported) shell variables, but you can never use those variables on command lines, only in here-documents and shell internals.

As noted by Kusalananda in a comment, if you're entering commands in an interactive shell, the lines you enter for a here document will be stored in the shell history, so it's not safe to type a password there, but it should still be safe to use shell variables containing secrets; the history will contain the text $secret rather than whatever $secret expanded to.

Use of command expansions is not safe:

command_with_secret_input "$(command_with_secret_output)"

because the output will be included on the command line and visible in ps output (or manually reading from /proc) except on systems with hardened /proc.

Assignment to a variable is okay too:

secret=$(command_with_secret_output)

Answer 5

Just write the value into a file and pass the file:

$ cat > mysecret
Big seecreeeet!
$ cat mysecret | sha1pass 

I'm not sure how sha1pass works, if it can take a file as input, you can use sha1pass < mysecret. If not, using cat might be a problem since it includes the final newline. If that's the case, use (if your head supports -c):

head -c-1 mysecret | sha1pass 

Answer 6

If what terdon did is possible, then that's the best solution, passing through standard input. The only problem left is he wrote the password to disk. We can do this instead:

stty -echo
echo -n "password: "
head -1 | sha1pass
stty echo

Like Kusalananda said, stty -echo ensures what you type is not seen until you do stty echo again. head -1 will get one line from standard input and pass it on to sha1pass.

Answer 7

I would use

sha1pass "$(cat)"

cat would read from stdin until EOF, which can be caused by pressing Ctrl+D. Then, the result would be passed as argument to sha1pass

Answer 8

If you are passing sensitive information around and use it regularly you are probably best encrypting it.

Putting something like

#create key as follows - will prompt for password
#echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64
export MY_SECRET='VTJGc2RHVmtYMTlzVnBGWXNYUitLWlpYT3BWdStaQXJXeUVwc1JORnFsNWswZXJKT1dkRWpsWkxLWVFnK1hONQo='

Into your .bashrc will give you an encrypted environment variable that you can access where ever you need a secret, and you will be prompted for you passphrase/password that you used when creating the environment variable.

In the example above it is 'secret'

You access it is a command as follows

`echo $MY_SECRET|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2 `

e.g.

xfreerpd /parameters.... /p:`echo $MY_SECRET|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2` 

For your query using sha1pass. You can create and passin as follows

MY_SECRET=`echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64`

Then use it as follows

sha1pass `echo $MY_SECRET|base64 --decode|openssl enc -aes-256-cbc -a -d -salt -pbkdf2 `

The base64 part is so that you can set the variable

MY_SECRET='VTJGc2RHVmtYMTlzVnBGWXNYUitLWlpYT3BWdStaQXJXeUVwc1JORnFsNWswZXJKT1dkRWpsWkxLWVFnK1hONQo='

And not have your secret stuck in the command history etc etc.

When you generate the secret sometimes the base64 output will have multiple lines so you need to take the line breaks out for your variable.

echo -n 'secret you want encrypted' | openssl enc -aes-256-cbc  -a -salt -pbkdf2|base64
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
VTJGc2RHVmtYMTlzVnBGWXNYUitLWlpYT3BWdStaQXJXeUVwc1JORnFsNWswZXJKT1dkRWpsWkxL
WVFnK1hONQo=
#take the above line break out 
MY_SECRET='VTJGc2RHVmtYMTlzVnBGWXNYUitLWlpYT3BWdStaQXJXeUVwc1JORnFsNWswZXJKT1dkRWpsWkxLWVFnK1hONQo='

openssh will prompt you for a password to encrypt and decrypt each time, you can supply one as part of the command, but then you are just hiding things from the history etc. Have a look at https://www.tecmint.com/generate-encrypt-decrypt-random-passwords-in-linux/ for some info on using openssh for this. https://www.serverlab.ca/tutorials/linux/administration-linux/how-to-base64-encode-and-decode-from-command-line/ for base64 and https://stackoverflow.com/questions/16072351/how-to-assign-an-output-to-a-shellscript-variable for different options on command substitution I have used back-tick ` above