È buono memorizzare le password in una tabella / database separata e gestirle in un processo separato?

Question

È buono memorizzare le password in una tabella / database separata e gestirle in un processo separato?

#1 da (4 voti)
#2 da (3 voti)

6

Sono piuttosto un principiante dell'architettura e della sicurezza dei sistemi, quindi voglio solo verificare che questo piano abbia senso. Sto creando un'app Web e ho bisogno di memorizzare una password per ogni utente. Ho già letto molto su algoritmi di hashing, sale e così via. Userò Argon2 poiché sembra essere la raccomandazione corrente. La mia domanda riguarda il modo in cui gli hash vengono archiviati e controllati in termini di architettura generale.

Poiché hashing con Argon2 è intenzionalmente piuttosto costoso, voglio creare un servizio in un modulo / processo separato in modo che possa essere facilmente spostato su una o più macchine separate, se necessario. Anche se vivesse sulla stessa macchina del server principale delle app, sarebbe banale monitorare l'utilizzo della CPU e della memoria per ottimizzare i fattori di costo dell'algoritmo di hashing.

La mia app invierà al servizio richieste HTTPS POST per creare, aggiornare, eliminare o verificare una password. Tutti i dettagli saranno nel corpo della richiesta, inclusa la password in testo normale. La connessione verrà crittografata. La risposta sarà semplicemente un'indicazione di successo o fallimento.

Il servizio gestirà la logica delle operazioni del database, le password di hashing e il confronto degli hash per l'uguaglianza. Le password vivranno in un database separato dagli utenti, in modo che anche se un utente malintenzionato scarica l'intero database delle password, non conosce ancora la password di nessuno e viceversa. Inoltre, se dovessi migrare a una diversa soluzione di archiviazione per i miei altri dati, c'è meno migrazione da fare poiché le password possono rimanere come sono.

Suona bene? O in qualche modo apre più punti deboli di cui non sono a conoscenza?

architecture passwords hash databases

posta Alex Hall 25.03.2016 - 23:31

fonte

2 risposte

Leggi altre domande sui tag architecture passwords hash databases

Quali considerazioni sulla sicurezza ci sono quando si sviluppa un generatore di password casuali? Quando cambiare uno smartphone con SO fuori dal supporto?

score 4 · Answer 1

L'hashing troppo lento significa che devi usare un hash più veloce, non un secondo processo. Prova a modificare i parametri su Argon2 o passa a bcrypt (che è ancora molto sicuro). Regola i parametri per ottenere l'hash a un tempo ragionevole (~ 0,2-0,4 secondi) e mantieni tutto in un unico processo.

Se lo desideri, puoi comunque mantenere le password in un secondo database per ridurre la perdita di dati in caso di furto del contenuto del database principale, ma non sono sicuro che sia necessario. La saggezza convenzionale dice che bcrypt è sicuro anche se tutti i dati vengono rubati. Ora non è una garanzia, ma se non hai l'NSA che ti insegue, o stai memorizzando qualcosa di abbastanza valido da motivare grandi porzioni della rete Bitcoin a smettere di mimare e iniziare a scansionare le tue password, mi sentirei molto bene con un ragionevole eseguendo bcrypt.

score 3 · Answer 2

Questa è una domanda di sicurezza, vorrei farti conoscere un'altra considerazione:

Considerazioni sulle prestazioni

Creare un servizio web micro per gestire l'autenticazione potrebbe essere una buona idea in alcuni casi, questo dipende dai casi d'uso.

Tuttavia, potresti voler considerare che stabilire molte connessioni https (per molte richieste) ha anche un costo. Potrebbe essere utile in termini di minimizzazione del carico (poiché sembra preoccupante) che i due servizi stabiliscano un tunnel longevo utilizzato da più connessioni.

Per quanto riguarda le considerazioni sulla sicurezza

L'attuale servizio web dell'utente agirà come un client TLS in questo szenario.

È estremamente importante che il truststore funzioni come previsto (ad esempio fidandosi solo del certificato del servizio password) e che la chiave privata dei servizi di password e i servizi web rimangano privati .

Altro,
- il servizio potrebbe diventare vulnerabile agli attacchi MITM (specialmente quando è in esecuzione su macchine diverse)
- gli utenti malintenzionati potrebbero interagire direttamente con il servizio di password, magari lo possono DOSare con payload estremamente grandi o essere in grado di utilizzare attacchi temporali per canale laterale indiretto.
Il servizio web e / o il servizio di password dovrebbero preferibilmente utilizzare alcune strategie per essere sicuri di mitigare possibili attacchi di timing e DOS.

Inoltre, l'aumento della scalabilità, la separazione delle preoccupazioni e in particolare la segmentazione della rete (che sono buone e importanti) ha un prezzo: l'implementazione della logica può diventare più complessa e si potrebbero introdurre problemi delicati di cui non si è a conoscenza . Questo è particolarmente vero se non sei abituato.

Un esempio di maggiore complessità potrebbe essere: sulle modifiche alla posta elettronica, chi gestisce l'effettivo commit della nuova email come verificata e in che modo, ad es. chi è autorevole per modificare i dati duplicati attraverso i database? Vuoi avviare l'I / O di rete all'interno di una transazione di database?

Riguardo alla funzione di hashing

Là è una domanda qui sulle password di hashing in modo sicuro che ha molto bene risposte.

Considera che non è necessario per te utilizzare funzioni di hashing di ricerca all'avanguardia. Gli altri (PBKDF2, bcrypt e scrypt) sono altrettanto validi per questo scopo e non è necessario aspettarsi di trovare un problema grave in qualsiasi momento, poiché hanno avuto il tempo di sottoporsi a peer review.