La crittografia dell'hash della password nel database è più sicura rispetto all'archiviazione dell'hash?
Supponiamo di archiviare direttamente il risultato SHA-256 crittografato con AES anziché con hash. È una buona protezione da una situazione futura quando qualcuno interromperà uno degli algoritmi?
Prima di tutto, ogni password memorizzata dovrebbe essere sottoposta a hash con un diverso sale pseudo-casuale. Secondo, SHA-256 non è appropriato per la memorizzazione di password; al contrario, si desidera utilizzare un algoritmo key stretching , come già menzionato. Ci sono molti più dettagli su Crackstation .
Un hash crittografato viene anche chiamato hash con chiave e la chiave viene talvolta chiamata "pepe". Non è necessario un passo di crittografia separato. Invece, la chiave segreta fa parte dell'input della funzione hash. Che può migliorare la sicurezza. Ci sono due modi in cui gli attaccanti possono ottenere una copia degli hash delle password. Uno è quello di compromettere il meccanismo di archiviazione, come con SQL injection. In tal caso, un hash con chiave può rendere effettivamente impossibile recuperare le password in chiaro dagli hash perché la chiave può essere compilata in un programma o mantenuta al di fuori del meccanismo di memorizzazione della password. L'altro modo è di compromettere il sistema operativo stesso. In tal caso, la chiave è compromessa e non rappresenta più un ostacolo ai tentativi di attacco delle password.
Quindi, la risposta breve è sì, ma devi prima eseguire il lavoro sottostante.
A condizione che intendi prima Hash ( BCrypt ) e quindi crittografare l'hash, la sicurezza non dovrebbe essere indebolita, eppure non si sta migliorando la sicurezza .
La crittografia è, per definizione, uno schema reversibile. Poiché in questo caso non esiste un caso d'uso per il quale si richiede la decrittografia, la crittografia è lo strumento sbagliato per il lavoro.
Se stai cercando di utilizzare una "chiave segreta" in combinazione con l'hashing della password, dovresti utilizzare un HMAC (comunemente indicato come "uso di sale e pepe"). Per ulteriori informazioni su HMAC e Hash, consultare: Aggiunta password hash sale + pepe o sale abbastanza? . Per una discussione su come implementare questo, vedere: Come applicare correttamente un pepe a bcrypt? .
Bob Brown ha coperto la maggior parte dei punti salienti di la sua risposta ma volevo far notare che è uno svantaggio significativo: la complessità. Stai aumentando la complessità della tua applicazione in una certa misura, minore (nel caso di aggiungere un pepe all'hash in cui è necessario pensare alla gestione delle chiavi e alla memorizzazione degli hash e dei salti delle password) o maggiore (nel caso di implementazione qualcosa di più sofisticato come AES e la necessità di memorizzare IV o Nonce e possibilmente tag / MAC così come l'output, il sale e la gestione della / e chiave / i.)
Quindi, il valore che aggiungerai sarà sufficiente a giustificare il costo aggiuntivo della complessità? Dovrai rispondere a questa domanda per la tua applicazione. Direi che in genere non lo è, mentre ci sono certamente casi là fuori dove lo fa.
In ogni caso, come ha detto Bob, è necessario iniziare con una base solida e passare a un algoritmo di hashing migliore come Bcrypt, indipendentemente dal fatto che decidi di crittografare o meno.
Leggi altre domande sui tag storage encryption passwords password-management hash