Prima di tutto, non dovrebbe crittografare le password . La crittografia è reversibile.
Invece, devi cancellare le password . Un hash è un po 'come la crittografia unidirezionale.
Quando l'utente effettua l'accesso, invece di decrittografare, codifica ha cancellato la password che hanno fornito e verifica se corrisponde all'hash che è già stato archiviato nel database. Se è la stessa password (e salt), l'hash risultante sarà coerente e puoi lasciarli entrare.
Quando le password di hashing devi considerare alcune cose:
-
È importante utilizzare il sale per prevenire gli attacchi del canale laterale in relazione al rilevamento dei duplicati.
-
Dovresti usare una routine ben controllata.
-
Dovresti usare un fattore di lavoro sufficientemente alto in modo che sia costoso per la forza bruta.
Ho spiegato tutte le considerazioni qui: Perché MD5 è considerato un algoritmo vulnerabile? .
-
In breve, dovresti usare BCrypt. (che ha avuto più tempo per essere controllato rispetto a Argon2)
-
Esegui un SHA-256 veloce sulla password prima di inviarlo a BCrypt. (per prevenire il troncamento)
-
Il BCrypt Work Factor dovrebbe prendere 50-500ms sul computer di destinazione.
-
Limita i tentativi di accesso per prevenire la forza bruta online e il DoS tramite calcoli hash.
-
BCrypt ha già Salt, ma è meglio includere anche un Pepper (~ 72 bit di entropy) che è una sorta di password aggiuntiva aggiunta alla password dell'utente. Il Pepper è uguale per tutti gli utenti, ma è unico per la tua applicazione. È memorizzato nel codice sorgente o, meglio ancora, in un file di testo separato, ma mai memorizzato in un database SQL.
-
Includere requisiti ragionevoli per la sicurezza delle password nell'applicazione, poiché nessuna quantità di hashing proteggerà un password
debole.
Would an unencrypted password database in a system be considered a vulnerability? (think yes)
Se non esegui l'hash o la crittografia, è sicuramente una vulnerabilità.
Would an unsalted hashed password database in a system be considered a vulnerability? (unsure)
Sì, principalmente a causa delle tabelle arcobaleno. Tuttavia, la preoccupazione più grande sarebbe la forza di una funzione di hash che si sta utilizzando. La maggior parte dei buoni algoritmi ha già sale, quindi se non hai sale, ci sono buone probabilità che tu stia usando un algoritmo debole.
Would a salted and hashed password database be considered a vulnerability? (tend to think no)
Hai ragione, questo è OK. È comune memorizzare Salt e Hash in un database SQL, ma è meglio includere anche Pepper che viene tenuto fuori dal database SQL.
And would an encrypted password database but with a same "secret" key be considered a vulnerability?
Sì. La crittografia reversibile delle password è sbagliata. Se la chiave viene rubata, le password vengono facilmente recuperate senza forza bruta. Hashing risolve questo problema.