Nascosto password memorizzate in bash

Question

Ho uno script bash che ho bisogno di scrivere la mia password per eseguire un programma. Altre persone possono vederlo. C'è un modo per scrivere la password in modo non troppo ovvio? Anche se può eseguire lo stesso comando in bash e ottenere la password, non può leggerlo nel testo.

Oggi faccio questo:

PASSWORD="1234567" 
program --pass=$PASSWORD 

io voglio fare questo

PASSWORD="10101001001010010101010100101" #binary or other code 
NEW_PASS=`decrypt $PASSWORD` 
program --pass=$NEW_PASS 

Qualche idea?

Answer 1

Quello che stai chiedendo non è solo il male: semplicemente non funziona.

Tutto quello che un utente deve fare per vedere la password è quello di eseguire bash -x your_script e l'uscita includerà

+program '--pass=decrypted-password-here' 

... non importa quanto sia efficace l'offuscamento avrebbe potuto essere.

Qual è il programma che si sta tentando di chiamare e che richiede una password? Puoi nascondere la tua password dietro un wrapper setuid, in modo che il wrapper possa leggere il file della password anche se l'utente che lo esegue non può? Puoi (prendendo in prestito il suggerimento di DigitalRoss) configurare un account utente che ha una copia della password memorizzata (o, meglio, un certificato o una coppia di chiavi), configurarlo solo per essere in grado di eseguire il tuo script e nient'altro su SSH, e dare il utenti che dovrebbero essere in grado di eseguire le autorizzazioni di script per SSH come tale utente (o sudo per quell'utente solo per il singolo comando, o così via)?

Ecc

In breve: Obiettivo per la sicurezza reale, non offuscamento.

---

Ora, se si fatto desidera offuscamento - l'approccio tradizionale è ROT-16:

obfuscated_password="qrpelcgrq-cnffjbeq-urer" 
real_password="$(tr a-zA-Z n-za-mN-ZA-M <<<"$obfuscated_password")" 

... ma se si tratta di una password che realmente preoccupano di sorta, non lo fanno offuscare - utilizzare uno degli approcci sopra riportati per evitare di memorizzare una password in un modo leggibile dall'utente.

Answer 2

Un modo "non troppo difficile" è quello di utilizzare ROT13:

PASSWORD=cnffjbeq 
REAL_PASSWORD=`echo $PASSWORD | rot13` 

Se non si dispone di un programma rot13, utilizzando tr a-z n-za-m funziona altrettanto bene.

Ricordare che questo fornisce assolutamente nessuna sicurezza di sorta. Tuttavia, potrebbe essere sufficiente per i tuoi scopi di "visione casuale".

Answer 3

È possibile utilizzare uuencode and uudecode, che vengono spesso installati (e sempre facilmente disponibili tramite pacchetti) su sistemi Unix. Dal momento che la codifica non ha senso, potrebbe impedire a un osservatore di memorizzare facilmente la password, ad esempio stealing the password via shoulder-surfing.. Tuttavia, una password di testo chiaro scelta a caso otterrebbe la stessa cosa senza la falsa illusione della sicurezza.

Questo problema esatto è affrontato da everyone in DevOps in questi giorni in quanto la gestione automatica della configurazione diventa sempre più necessaria.

Ecco alcune soluzioni migliori:

• hanno un segreti file sul sistema lo script viene eseguito su. Lo script può leggere il suo segreto in fase di esecuzione fuori dal file. In questo modo puoi controllare lo script nel controllo del codice sorgente senza trasmettere la password e puoi utilizzare le autorizzazioni utente per proteggere il file dei segreti. È possibile riutilizzare lo script senza propagare una password.

• uso non-passphrase SSH autenticazione a chiave pubblica per arrivare al sistema remoto

• utilizzare una combinazione di approcci di cui sopra con un utente di ruolo limitato. Generalmente creo un utente sul sistema di destinazione che non può fare nulla se non ciò che lo script vuole fare. Le moderne versioni di ssh aiutano con questo, dato che possono ignorare il comando in entrata (vedi forcecommand in sshd_config o usare something like ssh-forcecommand) e fare sempre una cosa specifica.

• autenticare il client dell'agente di gestione tramite un certificato firmato dal server. Sistemi di gestione della configurazione reali come Puppet e Chef lo faranno per te.

• se ci si connette a una pagina Web, è ancora possibile creare un utente con restrizioni di ruolo o almeno uno che è sacrificabile. Forse è possibile accedere manualmente una volta e stabilire una sessione persistente. Curl può utilizzare i cookie e collaborare con questo approccio.

Answer 4

Mettere la chiave sotto il tappetino della porta non è sicurezza. Ma il fatto che "programma" deve richiedere --passare ..... significa che chiunque può fare "ps -ef" può vederlo. Se 'programma' ha un modulo che può leggere la password da una pipe, allora dovresti usarlo al suo posto. ad es. programma --pass = - ... < /home/me/.something e rendi il file leggibile solo da te.