Il modo ideale per archiviare password unhashed

Question

Il modo ideale per archiviare password unhashed

#1 da (5 voti)
#2 da (0 voti)

8

Ho a che fare con un fornitore di terze parti che chiaramente non capisce la sicurezza: per accedere alla loro API dal mio back-end devo fornire l'ID / utente / password dell'utente finale per il servizio di terze parti con ogni serie di richieste .

Sto combattendo con loro per implementare almeno una sorta di autenticazione basata su token revocabile, ma nel frattempo devo occuparmene (almeno usano HTTPS ... sheesh).

Devo autenticarmi abbastanza regolarmente per sincronizzare i dati, e la sincronizzazione deve avvenire senza l'intervento dell'utente finale, quindi fondamentalmente significa che BE deve memorizzare le credenziali in un formato reversibile. Non sono abbastanza ingenuo da archiviarlo in testo in chiaro, ma anche se lo cripto nel database, la chiave non sarà molto lontana dal lucchetto, per così dire.

Se non avessero una quantità di dati riservati memorizzati lì sarei meno preoccupato, ma questo è sicuramente un dato che vale la pena proteggere. Qualche consiglio?

Note:

Le password verrebbero archiviate in un database distribuito. Il database stesso è ragionevolmente sicuro. L'unica vera possibilità di una violazione sarebbe una perdita di credenziali di uno degli sviluppatori per accedere direttamente ai dati, o un errore di programmazione grave .
L'API del fornitore non consente di modificare la password in modo programmatico, pertanto la rotazione delle password non è un'opzione.

L'accesso al codice sorgente del back-end potrebbe essere bloccato abbastanza stretto. Sarebbe ragionevole memorizzare una chiave privata nell'origine e chiamarla un giorno?

encryption passwords

posta jdiaz5513 30.08.2013 - 16:10

fonte

2 risposte

Leggi altre domande sui tag encryption passwords

SpiderOak è veramente "zero-conoscenza"? È un collegamento simbolico una vulnerabilità molto comune nei sistemi UNIX

score 5 · Answer 1

Il meglio che si possa realisticamente sperare è quello di utilizzare qualsiasi funzionalità fornita dal sistema operativo locale per la memorizzazione di "segreti". Ciò significa DPAPI su Windows, Keychain su MacOS X ... usa questo per memorizzare la password dell'utente, o qualche chiave di decrittazione per un file crittografato che contiene la password dell'utente. Le funzionalità a livello di sistema operativo possono avere un accesso più diretto all'hardware rispetto a quello che si può fare a livello di applicazione e, come tale, offrono una protezione possibilmente più strong (meno debole) contro gli aggressori. Inoltre, non puoi essere incolpato di aver usato il metodo "OS raccomandato" di memorizzare i segreti.

Se la macchina client viene rubata del tutto, è comunque necessario presumere che l'autore dell'attacco sarà in grado di recuperare la password dell'utente. Possibili soluzioni includono l'uso di una funzione di blocco automatico sul computer client unita alla crittografia del disco rigido (ma questo è fuori dalla tua portata come autore di applicazioni e l'utente umano potrebbe non apprezzare l'idea). L'autolock significa che l'attaccante troverà difficile (non impossibile, ma difficile) fare confusione con la macchina mentre è ancora attiva e la crittografia del disco rigido significa che riavviare la macchina blocca in modo permanente l'attaccante dai segreti memorizzati (la crittografia del disco la password deve essere digitata ogni volta che si avvia la macchina).

score 0 · Answer 2

Questo non è raro quando si tratta di API di terze parti. Anche se ti forniscono un "token" invece di una password, quei token danno effettivamente accesso all'account (anche se in molti casi sono limitati in qualche modo), quindi devono essere protetti con attenzione. Soluzioni di cui sono a conoscenza:

Salva nome utente / password nel codice sorgente. Dato che è così facile, le persone lo fanno sempre. Tuttavia, mi rende nervoso: idealmente il tuo codice è nel controllo del codice sorgente, quindi chiunque abbia accesso a questo avrà le credenziali.
Archivialo in un file di configurazione (idealmente con autorizzazioni limitate, quindi non può essere letto da utenti non autenticati, ecc.). Personalmente ritengo che sia leggermente migliore di # 1, poiché idealmente ci dovrebbero essere solo poche copie di questo.
Archivialo nella RAM e ottieni la password dall'utente o dalla rete quando viene avviata o è necessaria. Questo è probabilmente il più sicuro, ma o disturba l'utente, o richiede un servizio di "credenziali crittografate".

Penso che per la maggior parte delle applicazioni la soluzione del file di configurazione (n. 2) sia ragionevole, supponendo che generi una password casuale per questo account che non viene riutilizzata da nessun'altra parte e il sistema stesso è ragionevolmente sicuro. Per cose davvero importanti, potresti voler seguire il percorso di memorizzazione delle credenziali solo in memoria.

Recentemente ho usato questo approccio per fornire a un server una chiave di crittografia per i dati critici in un database. Significa che se il server viene riavviato, qualcuno deve digitare manualmente una passphrase, ma significa anche che se qualcuno esce con i dischi, non ottiene i dati.