In Linux abbiamo il sale proprio accanto all'hash della password nel file / etc / shadows.
Sento sempre che il valore di sale impedisce che le password con hash vengano violate dai metodi di forza bruta. Ma se in qualche modo otteniamo il file shadow possiamo iniettare il sale nell'algoritmo e usare ancora un metodo di forza bruta, giusto?
Non sto considerando il tempo trascorso, solo l'idea generale. So che la forzatura brutale di un hash SHA256 o SHA512 durerà per sempre.
L'hashing della password con un salt rende molto più difficile per un utente malintenzionato utilizzare un elenco precompilato di hash (ovvero tabelle arcobaleno) per eseguire l'hash scoperto.
Lo costringerà a calcolare nuovamente gli hash per ogni hash di password salata che vuole crack.
Il sale non deve essere segreto. Tuttavia, DEVE essere unico per ogni password. Considera questo: se tutte le tue password sono state sottoposte a hash con la stessa quantità di sale, un hacker che ha accesso al tuo database "only" deve calcolare H (pwd + salt) per ogni possibile valore di pwd e ottiene tutte le tue password. Se il sale è unico, tuttavia, la stessa operazione otterrà solo una password, quella associata al sale che ha appena provato.
A salt fa not rende più bruta la forzatura di una singola password, come hai giustamente sottolineato.
Senza un sale, un utente malintenzionato potrebbe creare una sola tabella arcobaleno e (s) otterrebbe tutte le password contemporaneamente. Con un sale, l'attaccante deve costruire un tavolo arcobaleno esattamente per questo sale, quindi non può riutilizzare tavoli arcobaleno già esistenti. Quando si utilizza un diverso sale unico per ogni password, un utente malintenzionato dovrebbe creare una tabella arcobaleno per ciascuna password. Questo non ha senso, dopo aver trovato una partita non c'è alcun vantaggio nel finire questo tavolo arcobaleno, la forza bruta è più economica.
Con una password salt per password, non è possibile utilizzare una tabella arcobaleno precalcolata per ottenere più password contemporaneamente.
Questo risponde anche alla domanda, perché il sale non ha bisogno di essere segreto. Algoritmi come SHA- * sono non appropriati alle password hash, perché sono troppo veloci e quindi possono essere forzati brutalmente troppo facilmente. Utilizzali insieme a PBKDF2 o utilizza Bcrypt / Scrypt, che offre un fattore di costo.
Hai ragione. Salting rende davvero più difficile l'hacking delle password per le password non banali, ma se alcuni utenti usano password comuni, possono ancora modificare la password con la forza bruta alcune migliaia di volte.
Se il sale è pubblico / memorizzato insieme, come il tuo caso, è solo usato per prevenire la ricerca di hash delle password pre-calcolate, cioè la tabella dell'arcobaleno.
Quindi, se per algoritmi simili nelle applicazioni web, suggerirei potrebbe anche anteporre una chiave segreta specifica dell'applicazione specifica alla password degli utenti, prima di eseguire l'hashing tramite l'algoritmo salato. Ovviamente se la chiave segreta dell'app è trapelata, allora questo miglioramento della sicurezza è sparito. Pertanto, memorizzo quella chiave segreta nel codice per separarla dal database degli hash delle password. (Questo è irraggiungibile nel file shadow di Linux)
Ulteriore commento : il punto principale dell'aggiunta della "chiave segreta" extra (o pepe) è: anche l'hash di una password semplice non può essere la forza bruta solo poche migliaia di volte per spezzarla (loro sono difficili come password complicate per la forza bruta), dato che l'hacker conosce solo l'hash della password, ma non è ancora in grado di vedere la chiave segreta nel codice. (Nel frattempo, non protegge i tentativi di forza bruta del sito Web online, ma protegge il tentativo offline di crackare solo l'hash stesso)
Rende un attacco del dizionario molto più difficile, se il sale viene creato in modo intelligente. Ad esempio, bcrypt utilizza un sale a 128 bit .
Un sale viene solitamente generato casualmente. Se fosse derivato solo dalla password o dall'hash della password, non aggiungerebbe molta sicurezza. Se viene generato in un modo che non può essere previsto dall'attaccante, aumenta significativamente lo spazio di ricerca - rendendo l'attacco di forza bruta richiede molta più forza bruta.
Tieni presente che anche in un attacco di forza bruta, un utente malintenzionato proverà ancora le password prevedibili (come "pa $$ w0rd") per prime. Assumendo un imprevedibile sale a 128 bit, l'attaccante ora deve provare fino a 2 ^ 128 più possibilità di crackare l'hash per "pa $$ w0rd" + salt. In media questa sarà la metà di 2 ^ 128 possibilità prima che l'hacker abbia successo, che è ancora 2 ^ 127 possibilità in più.