it-swarm-eu.dev

Standard per la crittografia delle password nei file di configurazione?

Il mio posto di lavoro ha uno standard secondo il quale le password in chiaro non sono consentite nei file di configurazione dell'applicazione. Questo ha abbastanza senso sul suo volto, nel caso in cui qualcuno ottenga l'accesso ai file di configurazione non ha automaticamente accesso a tutti i privilegi di quell'applicazione. In alcuni casi è possibile e ovviamente preferibile avere accesso associato all'accesso o evitare in altro modo di avere una password, come ad esempio nell'autenticazione di Sicurezza di Windows per SQL Server, oppure averlo configurato in una posizione di terze parti, come la configurazione JDBC in un ambiente J2EE , ma questo non è sempre possibile.

  • Quando devo avere una password in un file di configurazione, quale livello di crittografia dovrebbe avere?
  • Come gestisci il fatto che la chiave di crittografia per la password deve essere codificata o archiviata in un altro file di configurazione?
  • Le chiavi di crittografia per la password devono essere leggibili?
57
C. Ross

Quindi il seguente è stato un po 'troppo lungo per un commento ...

Forse fare un passo indietro e confrontare i benefici dei controlli preventivi e investigativi potrebbe aiutare. I controlli preventivi includono la crittografia, ma potresti anche codificare la password per renderla meno ovvia. Questo approccio ha lo scopo di proteggere la password dalla condivisione accidentale (una codifica b32 produrrebbe caratteri meno significativi (b32 produce una stringa più lunga di b64). Tale approccio aumenta semplicemente la difficoltà di memorizzare la sequenza casuale di numeri e il metodo che dovrebbe viene utilizzato per decodificare la stringa. La codifica Base32/64 è un modo semplice per proteggere le password che non richiedono logica aggiuntiva da costruire/mantenere.

Gli altri approcci ai controlli preventivi utilizzerebbero probabilmente la crittografia. Esistono molti modi diversi per proteggere la chiave. Senza entrare nei dettagli o ripetere ciò che D.W. già pubblicato, è possibile sovrapporre controlli detective per migliorare la posizione di sicurezza. Ad esempio, è possibile controllare l'accesso a un file che contiene la chiave. È possibile correlare eventi (come il riavvio del server/servizio) con l'accesso al file chiave. Qualsiasi altra richiesta di accesso (corretta o meno) al file chiave potrebbe indicare un'attività anomala.

Per arrivare alle tue domande, ecco la mia opinione:

se devi archiviare la password in un file di configurazione, ti consiglierei almeno di codificare la password ove possibile. La codifica della password ridurrebbe la possibilità che sia trapelata nel caso in cui qualcuno scorri il file, ad esempio con un rappresentante del supporto del fornitore che guarda. La crittografia della password è molto più sicura, ma richiede ulteriore complessità.

Come gestire il fatto che una chiave deve essere codificata o archiviata in un altro file. Bene, separare la chiave di crittografia in un altro file aumenta la difficoltà per qualcuno di visualizzare la chiave. Ad esempio, è possibile utilizzare il controllo dell'accesso per limitare l'accesso al file chiave ma mantenere comunque un ACL più aperto per il file di configurazione. Allo stesso modo, è possibile implementare il controllo per l'accesso al file chiave, che è possibile utilizzare per ricollegare ad eventi che richiedono l'uso della chiave. La codifica effettiva della chiave potrebbe andare bene se si limita l'accesso al file binario. La codifica attenta della password può essere facilmente rilevata eseguendo una "stringa" sul binario. È possibile codificare/crittografare la password codificata (ovvero richiedere una funzione separata (forse con il controllo) quando decodificare la password, ma ciò aumenta la complessità per lo sviluppatore e l'amministratore (ovvero come si cambia la chiave senza ricostruire/ricompilare il file binario ?).

Le chiavi di crittografia per la password devono essere leggibili? Dipende. C'è solo un numero limitato di modi per proteggere la chiave. Una chiave di crittografia viene generalmente vista come una stringa alfanumerica difficile da memorizzare nella memoria. Puoi sempre codificare/crittografare la chiave, ma tali metodi non scoraggiano qualcuno che sia abbastanza intelligente da fare uno screenshot. Tuttavia, è possibile utilizzare semplici "tasti" (più simili alle password) come input per una funzione di espansione dei tasti. In quei casi, forse misure aggiuntive come la codifica aggiungono un valore aggiuntivo rispetto al costo della complessità.

Semmai, un buon approccio è quello di implementare più livelli di controlli. I controlli preventivi sono più difficili mentre i controlli investigativi sono generalmente più facili da implementare. La separazione dei file chiave potrebbe semplificare l'architettura generale e l'implementazione dei controlli. Indipendentemente dal fatto che vengano utilizzati controlli preventivi o investigativi, è necessario abilitare alcune funzioni di controllo insieme alla revisione dei registri di controllo. In questo modo, se dovesse accadere l'improbabile (accesso alla chiave), puoi intraprendere azioni correttive.

25
bangdang

Se stai eseguendo un server che necessita di una password per accedere ad alcuni servizi remoti, non esiste una buona soluzione. Memorizzare la password in un file di configurazione memorizzato in una posizione adatta probabilmente sta facendo il meglio di una serie di scelte sbagliate.

Le scelte sono: chiedi a un utente di inserire la password al momento dell'avvio (questo è un problema, perché se il tuo server viene riavviato, ora il server è irraggiungibile fino a quando una persona non può camminare fisicamente sul server e inserire la password); hardcode la password nel codice sorgente del codice del server (è molto peggio che inserirla in un file di configurazione); o memorizzare la password in un file di configurazione (la meno cattiva di tutte le opzioni). La cosa principale a cui prestare attenzione con il file di configurazione è assicurarsi che sia archiviato al di fuori della radice Web e che le autorizzazioni per i file siano bloccate in modo appropriato.

Crittografare la password memorizzata nel file di configurazione non aiuta, perché ora dove si memorizza la chiave di decrittografia? Hai appena spostato il problema. "Sono le tartarughe fino in fondo" non è una risposta accettabile.

Su Windows, un'altra opzione che potresti guardare è la memorizzazione della password in DPAPI. Questo aiuta un po 'per le applicazioni desktop, ma non è molto utile per i server non presidiati.

Per ulteriori informazioni, leggi le seguenti domande su questo sito: Memorizza una password per evitare l'interazione dell'utente , dove archiviare una chiave per la crittografia , Come funzionano i progetti open source gestire artefatti sicuri? , Come posso decrittografare i dati con Java, senza codificare la chiave? , Password nel file .php , Dove si trovano Conservo in modo sicuro la chiave per un sistema in cui l'origine è visibile? .

Post scriptum In linea di principio, è possibile utilizzare un TPM per archiviare la password, ma in pratica questo ti dà problemi di Edge Bleeding, quindi probabilmente non è praticabile per la maggior parte delle persone.

37
D.W.

Memorizzare la password in una variabile di ambiente utente O/S (non di sessione) ed eseguire il programma come tale utente.

Vantaggi:

  1. Non controllerai mai accidentalmente la password nel controllo del codice sorgente perché non ci sono file da archiviare.

  2. Se rovini i permessi dei file sul tuo file di configurazione (cosa che non succede mai?), Le tue password non vengono compromesse

  3. Può essere letto solo dall'utente o dalla radice (uguale a un file di configurazione, uguale a una chiave privata che protegge un file crittografato)

  4. Se stai crittografando il file, come stai proteggendo la tua chiave?

  5. Cancella i tuoi envvar prima di avviare nuovi processi, poiché potrebbero essere passati

Un vantaggio di un HSM è che mentre l'utente o il root possono sare l'HSM per decrittografare un valore, non possono mai ottenere la chiave al suo interno.

5
Neil McGuigan

L'archiviazione della password locale è un problema lungo di cui mi occupavo. poiché la crittografia non sarà a prova di proiettile, ma potrebbe aiutare, ci sono poche altre opzioni:

  1. archiviare le password sul computer locale in un nuovo file (che sarà anche meglio crittografare) e limitare l'accesso al file
  2. memorizzare le password in un altro server, che eseguirà l'autenticazione tramite OAUTH o altri servizi di autenticazione - controlla tahoe-lafs: https://tahoe-lafs.org/trac/tahoe- LAFS
  3. utilizzando un servizio locale crittografato che archivia le password e accedervi utilizzando Certificato
  4. alcune organizzazioni memorizzano le password come chiavi di registro o con DPAPI - http://msdn.Microsoft.com/en-us/library/ms995355.aspx
  5. utilizzando OTP utilizzando il servizio di gestione degli account
  6. utilizzo del server proxy per accedere ai dati riservati e limitare l'accesso al proxy

.

e per le tue domande:

Quando devo avere una password in un file di configurazione, quale livello di crittografia dovrebbe avere?

non devi mai avere password nel tuo codice, ma è il modo più semplice e il più insicuro.

Come gestisci il fatto che la chiave di crittografia per la password deve essere codificata o archiviata in un altro file di configurazione?

utilizzando le restrizioni di accesso e monitorando il file

Le chiavi di crittografia per la password devono essere leggibili? se intendete password leggibili e sicure, non vi è alcun problema

4
Sergey Malych

I miei 2 centesimi qui sono che, per una perfetta sicurezza, vorresti che l'applicazione fosse in grado di fare qualcosa (leggi una password) che un attaccante sulla macchina fisica con gli stessi privilegi non dovrebbe essere in grado di fare, il che sembra una contraddizione .

Nella migliore delle ipotesi potresti offuscare la password nella configurazione ( Base64 , chiave da qualche parte sul computer, ecc ...)

0
Nicolas C