Standard per la crittografia delle password nei file di configurazione?

52

Il mio posto di lavoro ha uno standard che le password in chiaro non sono consentite nei file di configurazione dell'applicazione. Ciò ha abbastanza senso sul suo volto, nel caso in cui qualcuno acceda ai file di configurazione non abbia automaticamente accesso a tutti i privilegi di tale applicazione. In alcuni casi è possibile e ovviamente preferibile avere accesso associato al login o altrimenti evitare di avere una password, come in Windows Security per l'autenticazione di SQL Server, o averlo configurato in un luogo 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 contenere?
  • Come gestisci il fatto che la chiave di crittografia per la password debba essere codificata o memorizzata in un altro file di configurazione?
  • Le chiavi di crittografia per la password devono essere leggibili dall'uomo?
posta C. Ross 16.05.2012 - 17:40
fonte

5 risposte

24

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

Forse fare un passo indietro e confrontare i benefici dei controlli preventivi e detective 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). Un simile approccio aumenta la difficoltà di memorizzare la sequenza casuale di numeri e il metodo che dovrebbe essere utilizzato per decodificare la stringa. La codifica Base32 / 64 è un modo semplice per proteggere le password che non richiedono l'aggiunta o la manutenzione di una logica aggiuntiva.

Gli altri approcci ai controlli preventivi probabilmente utilizzerebbero la crittografia. Esistono molti modi diversi per proteggere la chiave. Senza entrare nei dettagli o ribadire ciò che D.W. già pubblicato, è possibile sovrapporre i controlli detective per migliorare la postura 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 (andata a buon fine o meno) al file chiave potrebbe indicare attività anomale.

Per rispondere alle tue domande, ecco la mia opinione:

se devi memorizzare la password in un file di configurazione, ti consiglio di codificare almeno la password laddove possibile. La codifica della password ridurrebbe la possibilità che sia trapelata nel caso in cui qualcuno scorresse il file, ad esempio con un rappresentante del supporto del venditore che guardava. La crittografia della password è molto più sicura, ma richiede una complessità aggiuntiva.

Come gestire il fatto che una chiave deve essere codificata o memorizzata 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 accessi per limitare l'accesso al file chiave, mantenendo 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 correlare gli eventi che richiedono l'uso della chiave. La codifica hard della chiave può andare bene se si limita l'accesso al binario. Un'accurata codifica della password può essere facilmente rilevata eseguendo una "stringa" contro il binario. È possibile codificare / crittografare la password codificata (ovvero richiedere una funzione separata (magari con 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 binario ?).

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

Se possibile, un buon approccio è 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 detective, è necessario abilitare alcune funzioni di controllo insieme alla revisione dei registri di controllo. In questo modo, se accade l'improbabile (accesso alla chiave), è possibile intraprendere azioni correttive.

    
risposta data 17.05.2012 - 01:14
fonte
35

Se si sta eseguendo un server che richiede una password per l'accesso ad alcuni servizi remoti, allora non c'è una buona soluzione. Memorizzare la password in un file di configurazione memorizzato in una posizione adatta probabilmente sta facendo il meglio da un insieme di scelte sbagliate.

Le scelte sono: avere un utente che inserisca la password al momento dell'avvio (questo è male, perché se il tuo server viene riavviato, ora il server è irraggiungibile fino a quando una persona non può fisicamente salire sul server e inserire la password); hardcode la password nel codice sorgente del codice server (questo è molto peggio che metterlo in un file di configurazione); o memorizzare la password in un file di configurazione (la meno pessima di tutte le opzioni). La cosa principale da tenere d'occhio con il file di configurazione, è assicurarsi che sia memorizzato al di fuori della tua web root e che i suoi permessi sui file siano bloccati in modo appropriato.

La crittografia della password memorizzata nel file di configurazione non aiuta, perché ora dove memorizzi la chiave di decodifica? Hai appena spostato il problema. "Le tartarughe arrivano fino in fondo" non è una risposta accettabile.

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

Per ulteriori informazioni, leggi le seguenti domande su questo sito: Archivia una password per evitare l'interazione dell'utente , dove memorizzare una chiave per la crittografia , In che modo i progetti open source gestiscono artefatti sicuri? , Come posso decrittografare i dati con Java, senza hard-coding della chiave? , Password nel file .php , Dove memorizzo in modo sicuro la chiave per un sistema in cui la sorgente è visibile? .

P.S. In linea di principio, puoi utilizzare un TPM per memorizzare la password, ma in pratica ti porta a problemi di sanguinamento, quindi probabilmente non è fattibile per la maggior parte della gente.

    
risposta data 16.05.2012 - 18:52
fonte
4

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

I vantaggi:

  1. Non verificheresti mai accidentalmente la password nel controllo sorgente perché non ci sono file da controllare.

  2. Se incasini i permessi sui file sul tuo file di configurazione (cosa che non succede mai?), le tue password non sono compromesse

  3. Può essere letto solo dall'utente o root (come un file di configurazione, come 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 iniziare nuovi processi, poiché potrebbero essere passati attraverso

Un vantaggio per un HSM è che mentre l'utente o il root possono usare l'HSM per decodificare un valore, non possono mai avere la chiave al suo interno.

    
risposta data 19.11.2013 - 20:32
fonte
2

L'archiviazione delle password locali è un problema a lungo con il quale mi stavo occupando. poiché la crittografia non sarà a prova di proiettile, ma potrebbe aiutare, ci sono poche altre opzioni:

  1. memorizza le password sul computer locale in un nuovo file (che sarà anche meglio crittografato) e limita l'accesso al file
  2. memorizza le password in un altro server, che eseguirà l'autenticazione tramite OAUTH o un altro servizio di autenticazione: controlla tahoe-lafs: link
  3. utilizzando il servizio locale crittografato che memorizza le password e accedendo utilizzando il certificato
  4. alcune organizzazioni memorizzano le proprie password come chiavi di registro o con DPAPI - link
  5. utilizzando OTP utilizzando il servizio di gestione degli account
  6. utilizzando il server proxy per accedere ai dati riservati e limitare l'accesso al proxy

.

e per le tue domande:

When I must have a password in a configuration file, what level of encryption should it carry?

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

How do you deal with the fact that the encryption key for the password has to be either hard coded or stored in yet another config file?

utilizzando le restrizioni di accesso e il monitoraggio del file

Should the encryption keys for password be human readable? if you mean strong and human readable passwords, there is no problem at all

    
risposta data 08.02.2014 - 16:41
fonte
0

I miei 2 centesimi sono che, per una sicurezza perfetta, si vorrebbe che l'applicazione sia in grado di fare qualcosa (leggere una password) che un utente malintenzionato sulla macchina fisica con gli stessi privilegi non dovrebbe essere in grado di fare, sembra una contraddizione.

Al massimo potresti offuscare la password nella configurazione ( Base64 , la chiave da qualche parte sul computer, ecc ...)

    
risposta data 21.02.2017 - 15:19
fonte

Leggi altre domande sui tag