È utile proteggere la password con hash con la crittografia?

Qual è il modello di minaccia? potrebbe essere di beneficio per proteggere l'archiviazione della password con un segreto sul lato dell'applicazione, ma solo se pensi che sia uno scenario realistico che il tuo database sta per essere compromesso, senza il server delle applicazioni, che detiene il segreto, anche essendo stato compromesso.

Di solito, il livello dell'applicazione è considerato la parte più vulnerabile e il livello del database più protetto, e per questo motivo non è considerato utile proteggere i dati con un segreto sul lato dell'applicazione. Ma potrebbe non essere il caso di ogni app, e personalmente vorrei mettere in discussione questa ipotesi data la prevalenza dell'iniezione SQL.

Lo svantaggio di introdurre un segreto sul lato dell'app è che ora devi preoccuparti dei processi di gestione delle chiavi. Qual è il tuo meccanismo per sostituire la chiave se viene compromessa? Hai intenzione di ruotarlo come se fosse ovvio? Come viene memorizzata la chiave in modo da poter spostare i server e non perderli (rendendo potenzialmente inutilizzabili tutti i dati)? Per chiavi di breve durata (utilizzate ad esempio per firmare i token di sessione), potrebbe non interessarti, ma per l'archiviazione a lungo termine delle password diventa importante.

L'ulteriore svantaggio di cifrari simmetrici (in particolare cifrari a blocchi) li sta implementando correttamente. Dato che stai facendo l'hashing e non hai bisogno di ripristinabilità, potresti invece includere il segreto nell'hash (come un "pepe") ... ma non sarai in grado di ri-hash tutti i dati della password su un cambiamento di chiave , quindi dovresti avere un metodo a più chiavi per il rollover.

ETA re comment @Pacerier:

L'hashing non impedisce un attacco di induzione non in linea da parte di qualcuno che ha ottenuto il database delle password. Aumenta solo la quantità di tempo necessario per quell'attacco per dare frutti; con uno schema di hashing di difficoltà appropriata (ad esempio cicli di derivazione chiave piuttosto che lunghezza del sale grezzo di per sé), si spera che aumenti tale quantità di tempo abbastanza a lungo da farti notare che sei stato hackerato e modificare le password di tutti prima di troppe i loro account sono persi.

Proteggere il contenuto con una chiave segreta (utilizzando la crittografia o includendo la chiave segreta nel materiale con hash) impedisce l'attacco di induzione offline, ma solo fino a quando la chiave segreta non viene divulgata. Se la chiave segreta si trova sul server dell'app separata dal server database, le password sono attaccabili solo se entrambe le macchine sono compromesse.

Quanto di un vantaggio è discutibile, dato che molti tipi di attacco possono finire per comprometterli entrambi, specialmente se il server delle app e il server del database sono la stessa macchina. C'è anche un prezzo da pagare in gestibilità come discusso. Quindi, se c'è un beneficio netto deve essere valutato caso per caso con riferimento al modello di minaccia.

Sono un grande fan dell'aggiunta di livelli di protezione su un sistema sicuro come parte di una difesa in profondità politica. Tuttavia, in questo caso particolare, l'utilizzo della crittografia simmetrica per questa attività crea un altro problema nel sistema; dovrai occuparti della gestione delle chiavi. La chiave deve essere memorizzata da qualche parte e se l'applicazione ha accesso ad essa, un utente malintenzionato che ha compromesso il tuo sistema molto probabilmente avrà accesso alla chiave.

Tale procedura aggiunge ulteriore complessità al sistema. La complessità è uno dei nemici della sicurezza. Consiglio vivamente di non farlo.

La crittografia degli hash delle password può proteggere le password in una situazione molto specifica.

Ci sono scenari in cui un utente malintenzionato ottiene l'accesso in lettura al database, l'iniezione SQL è una possibilità, un backup che perde o un altro server dismesso. In questo caso, può eseguire la brute-force degli hash delle password. Con un algoritmo hash appropriato (funzione di derivazione della chiave), le password complesse saranno sicure, mentre le password deboli possono essere recuperate più o meno velocemente con un attacco dizionario (prova le 1000 password più utilizzate ...).

Con la crittografia degli hash delle password, aggiungi un segreto lato server agli hash. Ciò significa che, oltre al database, un utente malintenzionato necessita ora di privilegi sul server (per ottenere la chiave). Questo è lo stesso vantaggio che un peperoncino può darti, ma ha il vantaggio di poter scambiare la chiave ogni volta che ciò sembra necessario.

Se la chiave è archiviata in modo sicuro non è così importante, importanti sono i privilegi aggiuntivi di cui l'utente malintenzionato ha bisogno. Nel peggiore dei casi, l'attaccante otterrà gli hash delle password e avrai la stessa situazione senza encrytion.

Penso che ci sia un caso per la crittografia di un digest sicuro.

Sembra generalmente accettato che la pratica migliore oggi sia usare bcrypt, PBKDF2 o algoritmi simili a salare e applicare un fattore di lavoro per la generazione della password digerire. L'uso di un pepe è anche un ottimo modo per mitigare i poveri o i ben noti le password possono essere facilmente impostate forzatamente a prescindere dall'algoritmo / dal fattore di lavoro utilizzato.

Tuttavia, l'uso di algoritmi lenti richiede che il fattore lavoro venga aggiornato come hardware le prestazioni migliorano e devono essere scelte per attenuare gli attacchi di forza bruta ma non indebitamente verifica lenta della password per gli utenti che accedono al tuo sistema. Utilizzando la crittografia simmetrica di un hash password sia il carico di lavoro che i requisiti di pepe non sono più necessari. Fornito la chiave simmetrica è ben protetta (utilizzando un HSM per esempio) e una buona gestione delle chiavi i processi sono stati stabiliti Non riesco a vedere un aspetto negativo per questo approccio. La difficoltà di un attacco di forza bruta è uguale alla forzatura bruta della chiave indipendentemente dal fatto che la password è di buona qualità o no.

Certamente non creerò l'infrastruttura per fare ciò come tutti i commenti precedenti per quanto riguarda la gestione delle chiavi e mantenere la chiave separata dal server delle applicazioni si applicherebbe. Ma se l'infrastruttura è già in atto e ben consolidata ci sono certamente alcuni aspetti positivi della crittografia di un hash delle password salate.

Direi di no. Per le ragioni che ha detto Adnan, la chiave deve essere accessibile e questo passaggio è quindi probabilmente solo aggiungendo complessità al sistema che è inutile.

Un approccio migliore IMO sarebbe quello di visualizzare la crittografia come un calcolo che potresti permetterti, ma che non hai usato, e considerando se potresti usare quel calcolo per un diverso approccio di hashing.

Esiste un equivoco sul fatto che la stratificazione di diverse pratiche crittografiche si traduca in qualcosa di più sicuro di qualsiasi altra pratica individuale. Tuttavia questo è raramente il caso.

L'hashing della password correttamente implementato con un tempo lungo è crittograficamente sicuro. Lo scopo delle password di hashing e saling è proteggere i dati a riposo. Il che significa che nessuno che si impossessa del database delle password dovrebbe sapere quali sono le password e anche se riescono a decifrare una o più password che non dovrebbero dare alcun vantaggio al cracking di un'altra.

Come Adobe ci ha mostrato nelle scorse settimane i cifrari a blocchi simmetrici non sono grandi in questo compito. Hashing with salt evita completamente questo problema.

Altri hanno sottolineato che un'ulteriore crittografia delle password con hash introduce il problema della gestione delle chiavi e non offre ulteriore sicurezza / solidità per i dati archiviati. La crittografia è utile per garantire che solo quelli con le credenziali appropriate possano accedere ai dati. La crittografia è reversibile per questo motivo. Questo non è un paradigma di autenticazione.

Quando autenticiamo vogliamo che il server usi qualcosa che sa (il sale) e un segreto che solo il tuo utente conosce (la password) per generare in modo coerente lo stesso blob unico di dati. Sappiamo che l'utente è chi dice di essere perché possiamo riprodurre questo enorme blob ancora e ancora. Il sale garantisce che anche due password identiche non abbiano lo stesso hash nel database. Anche la crittografia aggiuntiva non offre alcun aiuto su questo fronte.