Come sono sicuri i sali nel database? [duplicare]

Lo scopo della salatura è che non è possibile creare una tabella arcobaleno per ottenere più password contemporaneamente.

Senza salting : un utente malintenzionato può cercare in internet tabelle arcobaleno precalcolate e trovare le password senza alcuno sforzo.

Con una costante salata : l'attaccante deve creare una tabella arcobaleno per questo specifico sale e può quindi ottenere tutte le password con questa singola tabella arcobaleno.

Con un salt unico : se ciascuna password ottiene il proprio valore, l'utente malintenzionato deve creare una tabella arcobaleno per ciascuna password. In questo caso la forzatura bruta è più veloce, non ha senso finire il tavolo arcobaleno dopo aver trovato una corrispondenza, perché comunque non puoi ottenere altre password.

Quindi vedi, anche se il sale è noto, soddisfa il suo scopo. Se si desidera aggiungere un segreto al processo, è necessario utilizzare una chiave lato server e crittografare gli hash delle password già calcolati. Non confondere la salatura con altre misure di sicurezza.

Hai risposto alla tua domanda, ma non l'hai visto.

why all people say on SO or Internet anyway that putting the salt in the database is good practice or safe

La risposta è:

if I hack to a database (...) I will take the salt of the first record for example and make a dictionary of all hashes of all english words ( rainbow table ) and then I make another step which is using the salt that I got from the first record and try hashing it with each hash I got in the rainbow table and I will get the salted hash easily at the end

Un hash non salato avrà già disponibili tabelle arcobaleno. Se usi sale, dovrai costruirlo. L'unica cosa in cui ti sbagli è quando dici che è facile. Non è affatto facile, perché avrai bisogno di un nuovo "tavolo arcobaleno" per l'hash salato. Ci vuole un sacco di energia e tempo del computer, e questa è la protezione che stai aggiungendo.

Nota: un hash salato non sta rielaborando l'hash della password con un salt. È più come mescolare (o concatenare) la password originale e il sale e poi eseguirne l'hashing.

Altri hanno chiarito lo scopo di Salt, che è quello di richiedere un processo di forza bruta separato per utente per crack, che richiederebbe molto più tempo di un singolo processo di forza bruta che trova corrispondenze per ogni utente in una volta. Il sale non è necessario per essere segreto, solo unico.

Un buon modo per migliorare questo è includere Pepper, che è segreto. Pepper è solo una stringa casuale per l'applicazione, memorizzata nel codice sorgente o in un file separato, ma non nel database SQL.

Il peperone segreto viene combinato con il sale prima di generare l'hash. In questo modo se l'attaccante usa SQL Injection (accedendo a Hash + Salt) e non è in grado di violare il tuo filesystem (dove è conservato il Pepper), non sarà in grado di crack.

E naturalmente ci sono modi per limitare l'impatto di SQL Injection.

Il di sale deve essere memorizzato in un posto facilmente accessibile dato un ID utente. Ciò significa una tabella di database. L'hacker che può ottenere le password hash può ottenere i sali allo stesso modo, spesso utilizzando l'iniezione SQL. Come altri hanno già scritto, il sale blocca gli attacchi di precomputazione

Esiste un approccio chiamato hash con chiave in cui l'hash viene generato da una concatenazione della password in chiaro, la salt (ancora memorizzata nel database e univoco per utente) e una chiave segreta . La chiave non ha bisogno e non dovrebbe essere memorizzata nel database. Potrebbe essere memorizzato nel filesystem o compilato nel programma di login. Ciò fornisce una difesa contro l'iniezione SQL. Tuttavia, come altri hanno già scritto, non esiste una sicurezza assoluta. Se l'utente malintenzionato può compromettere il sistema operativo del server o l'applicazione di accesso, la chiave viene compromessa e la sicurezza è tosta. (Ma gli attacchi di precomputazione sono ancora prevenuti dal sale, anche per l'attaccante che ha accesso alla chiave.)