Come separare la memorizzazione di dati sensibili e password di hash?

8

Scenario: ho un'applicazione web con un sistema di autenticazione (classico). L'applicazione è fondamentalmente un'interfaccia per un DB (MongoDB) che contiene dati sensibili. Ho cancellato correttamente le password memorizzate.

Supponendo che l'hashing impedisca all'utente malintenzionato di conoscere le password quando ha già ottenuto l'accesso al DB:

Domanda 1: esiste un punto per le password di hashing quando si archiviano tutti i dati in un DB?

Domanda 2: qual è il modo giusto per separare dati sensibili e credenziali? Database separati? È possibile utilizzare il sistema di autenticazione integrato di Mongo per l'autenticazione dell'utente?

    
posta Icki 22.09.2017 - 16:29
fonte

2 risposte

1

Riguardo a Domanda 1 :

In generale, si, lo è. Non conosci i dettagli di un potenziale attacco futuro, quindi il tuo compito è quello di rendere effettivo lo sfruttamento di qualsiasi vulnerabilità quanto più possibile.

Come sapete, la missione di sicurezza delle informazioni è fornire tre valori: riservatezza , integrità e disponibilità . Supponiamo che un hacker abbia ottenuto una copia completa del DB (che influisce sulla riservatezza ). Essendo in grado di accedere come utente, può assumere integrità (modificando i dati dell'utente e eseguendo azioni a suo nome) e disponibilità (ad es. Modificando l'e-mail che può essere usato per riottenere l'accesso.

Prima di passare alla domanda 2 . Per quanto ne so, MongoDB ha anche il controllo degli accessi a livello di raccolta, quindi potrebbe aiutare a limitare la propagazione degli attacchi. Puoi anche considerare di crittografare le voci sensibili in un DB in modo tale che l'accesso non autorizzato alla sola lettura non sarà così critico.

Riguardo alla domanda 2: Non esiste un modo giusto perché le decisioni in materia di sicurezza devono essere prese sulla base di numerosi fattori che possono essere ricavati dall'analisi del rischio. È possibile memorizzare credenziali utente in un DB diverso o creare un server di autenticazione separato oppure utilizzare servizi di autenticazione di terze parti (OAuth).

L'obiettivo principale qui è mantenere un equilibrio tra il prezzo dell'attuazione, il supporto di quei controlli di sicurezza e una potenziale perdita che potresti avere in caso di violazione dei dati. La mia intuizione è di mantenerla semplice e seguire i consigli di sicurezza di base (come hashing delle password e segregazione degli accessi usando gli strumenti di controllo degli accessi MongoDB) combinati con altri controlli di sicurezza del sistema (come la rigida validazione dell'input dell'utente) che puoi trovare, ad esempio, in OWASP ASVS checklist .

    
risposta data 18.07.2018 - 00:48
fonte
0

Domanda 1: il punto delle password di hashing è che se l'autore dell'attacco ha una copia del tuo DB non dovrebbe craccare facilmente le credenziali per impedire che impersonino i tuoi utenti.

Tenendo conto del fatto che molti utenti riutilizzano le password o semplicemente le cambiano in modo molto sottile, può aiuta anche a rallentare la diffusione del compromesso ad altri componenti dell'infrastruttura.

Anche l'hashing impedisce il rischio di addetti ai lavori / dipendenti sleali, poiché i dipendenti che potrebbero avere pieno accesso al DB non saranno in grado di utilizzare le informazioni per impersonare altri utenti per l'app, anche se hanno ottenuto una copia degli hash.

Domanda 2: questa è completamente un'altra domanda, che potrebbe dover essere richiesta separatamente e fornire maggiori dettagli, per poter dare una risposta più specifica o meno vaga

    
risposta data 22.09.2017 - 23:31
fonte

Leggi altre domande sui tag