Memorizzazione delle credenziali utente nel file locale o nel database

Question

Memorizzazione delle credenziali utente nel file locale o nel database

#1 da (1 voti)
#2 da (1 voti)

1

Sto progettando una webapp da zero.

Da un punto di vista della sicurezza, supponendo che in entrambi i casi eseguirò un hashing con un salt, un peper e un algoritmo di hashing appropriato.

È meglio memorizzare le credenziali dell'utente in una tabella di database insieme al resto dei dati o nel proprio file locale?

Più specificamente, sarebbe un disegno separato dove la tabella utente del database contiene userID, nome, email, ecc. E l'userID, password, salt sono memorizzati in un file locale sul sistema. Vale la pena di progettare separatamente dal punto di vista della sicurezza, per quanto riguarda i possibili vettori di attacco in generale e, in caso di successo, per rendere il sistema più resiliente.

credentials

posta Wadih M. 31.01.2017 - 02:13

fonte

2 risposte

Leggi altre domande sui tag credentials

I pacchetti Sniff ripetono quindi queste richieste? Opzioni di configurazione del server OpenSSH

score 1 · Answer 1

Sembra che tu stia facendo tutte le cose giuste riguardo alla cripto (sale, pepe, algo giusto). La sicurezza aggiuntiva che si potrebbe ottenere andando sul file system locale o memorizzandola in un DB in esecuzione su un altro computer potrebbe non essere significativa.

Se vai al file system locale

Se possibile, attiva la crittografia a livello di file system.
Imposta il permesso di accesso appropriato sul file.

Se segui la rotta DB

Assicurati che la macchina che esegue il server DB sia correttamente indurita.
Se possibile, attiva la crittografia DB.
Garantire l'autenticazione utente richiesta per accedere al DB.
Se possibile, assicurati che la comunicazione tra Application Server e DB sia su un canale sicuro

score 1 · Answer 2

Dovresti utilizzare un database, per i seguenti motivi.

Il tuo server web è nella DMZ. La DMZ è meno sicura della zona protetta (dove inseriresti il tuo database), quindi ogni file che hai messo lì sarà più vulnerabile dei file di dati che contengono il tuo database.
Affinché le password offrano la massima sicurezza, deve essere possibile per un utente modificarle. Se li si archivia nel database, è più semplice da modificare. L'utilizzo di un file flat per l'archiviazione e l'aggiornamento frequente può causare problemi di blocco in un ambiente con volumi elevati; i database sono progettati per far fronte a volumi elevati in modo più efficace.
Se si utilizza un file flat locale, la soluzione non verrà ridimensionata a più di un server Web. Potresti usare una SAN suppongo, ma non sono sicuro che sia una buona idea dare al tuo filesystem dell'account di servizio del server web l'accesso alla rete; questa è solo un'altra risorsa che un hacker potrebbe voler sfruttare.
Una soluzione di database è più suscettibile a non-ripudio poiché ci sono tran logs, backup, ed è possibile creare tabelle cronologiche. Se utilizzi un file flat, un processo dannoso potrebbe scimmiottarlo e non lasciare traccia.
Molte piattaforme di database offrono crittografia . Anche se questa non è una panacea (hai ancora bisogno di usare hash, sali e altre attenuazioni), essa costituisce la difesa in profondità. Crittografare un file richiede un po 'più di lavoro e un po' più di rischio che tu abbia sbagliato l'implementazione.