Is it secure to type in sensitive data in bash / shell scripts

Question

So lets say I have a .sh script and I have to input a password in it , will there be some kind of cache where the bash inputs are stored ? And if yes please tell me whre so I can ersase it . Would the attacker be able to decrypt something which was encrypted with a shell / bash script passed through another program , if he had physical access to the machine ? If yes , how can I prevent that ?

I didnt find anything on the topic .

Thank you !

part of the script as example :

echo "please input your password to be hashed "
echo ""

stty -echo
read -p "Password :" x; echo
stty echo 

echo ""

echo "please repeat the password "

echo ""
stty -echo
read -p "Password :" x2; echo
stty echo

if [[ $x == $x2 ]] ;then 
    echo ""
    echo "Passwords match !"
    echo ""
    sleep 2
else 
    echo ""
    echo "passwords dont match :( "
    echo ""
    sleep 2
    echo "exiting"
    echo ""
    sleep 1
    exit 1 
fi 

Answer 1

Introduction

1. Don't reinvent the wheel

   There could already exist some tool for doing what you need.

2. Check your history files

   grep mycommand .*history
   

3. Don't use command line arguments or environment variables to store sensitive data (like passwords)!

   Always use files or fd (file descriptors)! Try

   ps axefwww
   

   to read all command lines and environment, currently running on your host

From openssl's man page:

(where sensible datas as command line argument or environment variables are recommended to be used where security is not important and with caution)

   Pass Phrase Options
       Several commands accept password arguments, typically using -passin and
       -passout for input and output passwords respectively. These allow the
       password to be obtained from a variety of sources. Both of these
       options take a single argument whose format is described below. If no
       password argument is given and a password is required then the user is
       prompted to enter one: this will typically be read from the current
       terminal with echoing turned off.

       pass:password
           The actual password is password. Since the password is visible to
           utilities (like 'ps' under Unix) this form should only be used
           where security is not important.

       env:var
           Obtain the password from the environment variable var. Since the
           environment of other processes is visible on certain platforms
           (e.g. ps under certain Unix OSes) this option should be used with
           caution.

       file:pathname
           The first line of pathname is the password. If the same pathname
           argument is supplied to -passin and -passout arguments then the
           first line will be used for the input password and the next line
           for the output password. pathname need not refer to a regular file:
           it could for example refer to a device or named pipe.

       fd:number
           Read the password from the file descriptor number. This can be used
           to send the data via a pipe for example.

       stdin
           Read the password from standard input.

Little sample

#!/bin/sh

umask 077
TEMPDIR=$(mktemp -d -p "$HOME" .secretXXXXXXXX)
trap "rm -fR '$TEMPDIR';exit" 0 1 2 3 6 9 15
[ "$TEMPDIR" ] || exit 1
cd "$TEMPDIR" || exit 1

ostty=$(stty -g)
stty -echo

printf "\nEnter password: "
head -n1 >pass1

printf "\nRe-enter password: "
head -n1 >pass2

stty $ostty
echo

chk1=$(sha1sum <pass1)
chk2=$(sha1sum <pass2)

[ "$chk1" = "$chk2" ] || {
    echo "password doesn't match"
    exit 1
}

openssl DoSomeThingWith -passin file:pass1

Answer 2

The cache you're worried about would be your shell history. I typically use bash, and can see its history by typing "history" in the command line:

history

I can clear it with the following:

history -c

Every user has their own history. If you didn't erase it, then it is plausible for an attacker to see it if they somehow gain access to your account.

Your question regarding decryption requires a lot more detail about exactly how the script works to do encryption: one simple answer is if the attacker had the encryption key then, yes he can decrypt it. Is the encryption key the password you're referring to? If so, then ensuring the password is not captured in your shell history is indeed a good precaution to take.

However, there is a concern about the script to begin with. For interactive human users, it should not accept the password as a script parameter - instead when the program runs, it should prompt you for the password. This way the password will never be accidentally left as part of the shell history.

Having said that there may be scenarios when an encryption script is used by other scripts, in which case then the encryption script would need to be able to accept the password/key as a script parameter. The issue of security would be to ensure that these other scripts to have the appropriate file permissions to ensure the embedded password/key is not revealed to other parties.