È sicuro digitare dati sensibili in script bash / shell

Introduzione

1. Non reinventare la ruota

   Potrebbero esistere già alcuni strumenti per fare ciò di cui hai bisogno.

2. Controlla i tuoi file di cronologia

   grep mycommand .*history
   

3. Non utilizzare argomenti della riga di comando o variabili di ambiente per memorizzare dati sensibili (come le password)!

   Usa sempre file o fd (descrittori di file)! Prova

   ps axefwww
   

   per leggere tutte le righe di comando e l'ambiente, attualmente in esecuzione sul tuo host

Dalla pagina man openssl :

(dove i dati sensibili come argomento della riga di comando o variabili di ambiente si consiglia di utilizzare dove la sicurezza non è importante e con cautela )

   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.

Piccolo campione

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

La cache di cui sei preoccupato sarebbe la cronologia della shell. Solitamente uso bash e posso vederne la cronologia digitando "history" nella riga di comando:

history

Posso cancellarlo con il seguente:

history -c

Ogni utente ha una propria storia. Se non lo hai cancellato, è plausibile che un utente malintenzionato lo veda se in qualche modo accede al tuo account.

La tua domanda riguardante la decodifica richiede molti più dettagli su come funziona esattamente lo script per eseguire la crittografia: una semplice risposta è se l'utente malintenzionato ha la chiave di crittografia, quindi può decrittografarla. La chiave di crittografia è la password a cui ti stai riferendo? Se è così, assicurarsi che la password non sia stata catturata nella cronologia della shell è davvero una buona precauzione da prendere.

Tuttavia, c'è una preoccupazione per la sceneggiatura per cominciare. Per gli utenti umani interattivi, non dovrebbe accettare la password come parametro di script - invece, quando il programma viene eseguito, dovrebbe richiedere la password. In questo modo la password non verrà mai lasciata accidentalmente come parte della cronologia della shell.

Avendo detto che potrebbero esserci degli scenari quando uno script di crittografia viene utilizzato da altri script, nel qual caso lo script di crittografia dovrebbe essere in grado di accettare la password / chiave come parametro di script. La questione della sicurezza sarebbe quella di garantire che questi altri script avessero le autorizzazioni file appropriate per garantire che la password / chiave incorporata non venisse rivelata ad altre parti.