¿Es seguro escribir datos confidenciales en los scripts de bash / shell?

Introducción

1. No reinventes la rueda

   Ya podría existir alguna herramienta para hacer lo que necesitas.

2. Comprueba tus archivos de historial

   grep mycommand .*history
   

3. ¡No utilice argumentos de línea de comando o variables de entorno para almacenar datos confidenciales (como contraseñas)!

   Siempre use archivos o fd (descriptores de archivos)! Intenta

   ps axefwww
   

   para leer todas las líneas de comando y el entorno, actualmente en ejecución en su host

De la página de manual de openssl :

(donde se recomienda utilizar datos sensibles como argumento de línea de comando o variables de entorno donde la seguridad no es importante y con precaución )

   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.

pequeña muestra

#!/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

El caché que te preocupa sería tu historial de shell. Normalmente uso bash y puedo ver su historial escribiendo "historial" en la línea de comandos:

history

Puedo borrarlo con lo siguiente:

history -c

Cada usuario tiene su propia historia. Si no lo borraste, es probable que un atacante lo vea si de alguna manera obtiene acceso a tu cuenta.

Su pregunta con respecto al descifrado requiere muchos más detalles sobre cómo funciona exactamente el script para realizar el cifrado: una respuesta simple es si el atacante tenía la clave de cifrado, sí, puede descifrarlo. ¿Es la clave de cifrado la contraseña a la que te refieres? Si es así, asegurarte de que la contraseña no esté capturada en tu historial de shell es una buena precaución para tomar.

Sin embargo, hay una preocupación acerca de la secuencia de comandos para empezar. Para usuarios humanos interactivos, no debe aceptar la contraseña como un parámetro de script; en lugar de eso, cuando se ejecuta el programa, debería solicitarle la contraseña. De esta manera, la contraseña nunca se dejará accidentalmente como parte del historial del shell.

Habiendo dicho que puede haber escenarios cuando otros scripts usan un script de cifrado, en cuyo caso el script de cifrado debería ser capaz de aceptar la contraseña / clave como un parámetro de script. La cuestión de la seguridad sería garantizar que estos otros scripts tengan los permisos de archivo adecuados para garantizar que la contraseña / clave incrustada no se revele a otras partes.