In che modo la password salt aiuta contro un attacco da tavolo arcobaleno?

Ho dei problemi a capire lo scopo di un salt in una password. Comprendo che l'uso primario è quello di ostacolare un attacco da tavolo arcobaleno. Tuttavia, i metodi che ho visto per implementare questo non sembrano davvero rendere il problema più difficile.

Ho visto molti tutorial che suggeriscono che il sale sia usato come il seguente:

$hash =  md5($salt.$password)

Il ragionamento è che l'hash non è ora associato alla password originale, ma a una combinazione di password e salt. Ma dire $salt=fooe $password=bare $hash=3858f62230ac3c915f300c664312c63f. Ora qualcuno con un tavolo arcobaleno potrebbe invertire l'hash e trovare l'input "foobar". Potrebbero quindi provare tutte le combinazioni di password (f, fo, foo, ... oobar, obar, bar, ar, ar). Potrebbero essere necessari alcuni millisecondi per ottenere la password, ma non molto altro.

L'altro uso che ho visto è sul mio sistema Linux. In / etc / shadow le password con hash sono effettivamente memorizzate con il sale. Ad esempio, un sale di "pippo" e la password di "bar" sarebbe hash a questo: $1$foo$te5SBM.7C25fFDu6bIRbX1. Se un hacker in qualche modo fosse in grado di mettere le mani su questo file, non vedo quale scopo serva il sale, poiché te5SBM.7C25fFDu6bIRbXè noto che l' hash inverso contiene "pippo".

Grazie per la luce che chiunque può farci.

EDIT : grazie per l'aiuto. Per riassumere ciò che ho capito, il sale rende la password con hash più complessa, rendendola molto meno probabile che esista in una tabella arcobaleno pre-calcolata. Ciò che ho frainteso prima era che stavo supponendo che esistesse una tabella arcobaleno per TUTTI gli hash.

Un salt pubblico non renderà più difficili gli attacchi del dizionario quando si decifra una singola password. Come hai sottolineato, l'attaccante ha accesso sia alla password con hash sia a Salt, quindi durante l'esecuzione dell'attacco con dizionario, può semplicemente usare il salt noto quando tenta di decifrare la password.

Un sale pubblico fa due cose: rende più dispendioso il tempo per decifrare un ampio elenco di password e rende impossibile utilizzare una tabella arcobaleno.

Per capire il primo, immagina un singolo file di password che contenga centinaia di nomi utente e password. Senza un salt, potrei calcolare "md5 (tentativo [0])", e quindi scansionare il file per vedere se quell'hash si presenta ovunque. Se sono presenti sali, allora devo calcolare "md5 (salt [a]. Tentativo [0])", confrontare con la voce A, quindi "md5 (salt [b]. Tentativo [0])", confrontare con la voce B , ecc. Ora ho ntanto lavoro da fare, dov'è nil numero di nomi utente e password contenuti nel file.

Per capire il secondo, devi capire cos'è un tavolo arcobaleno. Una tabella arcobaleno è un ampio elenco di hash pre-calcolati per le password comunemente utilizzate. Immagina di nuovo il file della password senza sali. Tutto quello che devo fare è passare attraverso ogni riga del file, estrarre la password con hash e cercarla nella tabella arcobaleno. Non devo mai calcolare un singolo hash. Se la ricerca è considerevolmente più veloce della funzione hash (cosa che probabilmente è), questo accelererà considerevolmente il crack del file.

Ma se il file della password viene salato, la tabella arcobaleno dovrebbe contenere il prefisso "salt. Password". Se il sale è sufficientemente casuale, è molto improbabile. Probabilmente avrò cose come "ciao" e "foobar" e "qwerty" nella mia lista di password pre-hash comunemente usate (la tabella arcobaleno), ma non avrò cose come "jX95psDZhello" o "LPgB0sdgxfoobar" o "dZVUABJtqwerty" pre-calcolato. Ciò renderebbe la tavola arcobaleno proibizionalmente grande.

Quindi, il sale riduce l'attaccante a un calcolo per riga per tentativo, che, se abbinato a una password sufficientemente lunga e sufficientemente casuale, è (in generale) indistruttibile.

Le altre risposte non sembrano affrontare i tuoi malintesi sull'argomento, quindi ecco qui:

Due diversi usi del sale

Ho visto molti tutorial che suggeriscono che il sale sia usato come il seguente:

$hash = md5($salt.$password)

[...]

L'altro uso che ho visto è sul mio sistema Linux. In / etc / shadow le password con hash sono effettivamente memorizzate con il sale.

Devi sempre archiviare il salt con la password, perché per validare ciò che l'utente ha inserito nel tuo database delle password, devi combinare l'input con il salt, l'hash e confrontarlo con l'hash memorizzato.

Sicurezza dell'hash

Ora qualcuno con un tavolo arcobaleno potrebbe invertire l'hash e trovare l'input "foobar".

[...]

poiché è noto che l'hash inverso di te5SBM.7C25fFDu6bIRbX contiene "pippo".

Non è possibile invertire l'hash in quanto tale (almeno in teoria). L'hash di "foo" e l'hash di "saltfoo" non hanno nulla in comune. La modifica di un solo bit nell'input di una funzione hash crittografica dovrebbe modificare completamente l'output.

Ciò significa che non è possibile creare una tabella arcobaleno con le password comuni e successivamente "aggiornarla" con del sale. Devi prendere in considerazione il sale fin dall'inizio.

Questo è l'intero motivo per cui hai bisogno di un tavolo arcobaleno in primo luogo. Poiché non è possibile ottenere la password dall'hash, si precompongono tutti gli hash delle password utilizzate più probabilmente e quindi si confrontano gli hash con i loro hash.

Qualità del sale

Ma dire $salt=foo

"pippo" sarebbe una scelta estremamente povera di sale. Normalmente useresti un valore casuale, codificato in ASCII.

Inoltre, ogni password ha il suo sale, diverso (si spera) da tutti gli altri sali sul sistema. Ciò significa che l'attaccante deve attaccare ciascuna password singolarmente invece di avere la speranza che uno degli hash corrisponda a uno dei valori nel suo database.

L'attacco

Se un hacker in qualche modo fosse in grado di mettere le mani su questo file, non vedo a cosa serva il sale,

Un attacco da tavolo arcobaleno ha sempre bisogno /etc/passwd(o qualunque sia il database delle password utilizzato), altrimenti come confronteresti gli hash nella tabella arcobaleno con gli hash delle password effettive?

Per quanto riguarda lo scopo: diciamo che l'attaccante vuole costruire una tabella arcobaleno per 100.000 parole inglesi comunemente usate e password tipiche (pensa "segreto"). Senza sale avrebbe dovuto pre-calcolare 100.000 hash. Anche con il tradizionale sale UNIX di 2 caratteri (ognuno è una delle 64 scelte [a–zA–Z0–9./]:) avrebbe dovuto calcolare e archiviare 4.096.000.000 di hash ... un bel miglioramento.

L'idea con il sale è di rendere molto più difficile indovinare con la forza bruta di una normale password basata sui caratteri. I tavoli Rainbow sono spesso costruiti pensando a un carattere speciale e non includono sempre tutte le combinazioni possibili (anche se possono).

Quindi un buon valore salato sarebbe un intero casuale a 128 bit o più lungo. Questo è ciò che fa fallire gli attacchi da tavolo arcobaleno. Usando un valore salt diverso per ogni password memorizzata, ti assicuri anche che una tabella arcobaleno creata per un particolare valore salt (come potrebbe essere il caso se sei un sistema popolare con un singolo valore salt) non ti dà accesso a tutti password in una volta.

Ancora un'altra grande domanda, con molte risposte molto ponderate: +1 a SO!

Un piccolo punto che non ho visto esplicitamente menzionato è che, aggiungendo un salt casuale a ogni password, stai praticamente garantendo che due utenti che hanno scelto la stessa password produrranno hash diversi.

Perché questo è importante?

Immagina il database delle password di una grande azienda di software negli Stati Uniti nord-occidentali. Supponiamo che contenga 30.000 voci, di cui 500 hanno la password bluescreen . Supponiamo inoltre che un hacker riesca a ottenere questa password, leggendola in una e-mail dall'utente al dipartimento IT. Se le password non sono salate, l'hacker può trovare il valore con hash nel database, quindi semplicemente abbinarlo per ottenere l'accesso agli altri 499 account.

Salare le password garantisce che ciascuno dei 500 account abbia un unico (salt + password), generando un hash diverso per ciascuno di essi e riducendo così la violazione a un singolo account. E speriamo, con ogni probabilità, che qualsiasi utente abbastanza ingenuo da scrivere una password in chiaro in un messaggio e-mail non abbia accesso all'API non documentata per il sistema operativo successivo.

Stavo cercando un buon metodo per applicare i sali e ho trovato questo eccellente articolo con un codice di esempio:

http://crackstation.net/hashing-security.htm

L'autore consiglia di utilizzare sali casuali per utente, in modo che l'accesso a un sale non renda l'intero elenco di hash facile da decifrare.

Per memorizzare una password:

• Genera un lungo sale casuale usando un CSPRNG.
• Prepara il salt alla password e l'hash con una funzione hash crittografica standard come SHA256.
• Salvare sia il salt sia l'hash nel record del database dell'utente.

Per convalidare una password:

• Recupera il sale e l'hash dell'utente dal database.
• Prepara il salt alla password data e l'hash usando la stessa funzione hash.
• Confronta l'hash della password data con l'hash del database. Se corrispondono, la password è corretta. Altrimenti, la password non è corretta.

La ragione per cui un sale può far fallire un attacco di un tavolo arcobaleno è che per n-bit di sale, il tavolo arcobaleno deve essere 2 ^ n volte più grande della dimensione del tavolo senza il sale.

Il tuo esempio di utilizzo di "foo" come sale potrebbe rendere la tavola arcobaleno 16 milioni di volte più grande.

Dato l'esempio di Carl di un sale a 128 bit, questo rende la tabella 2 ^ 128 volte più grande - ora è grande - o in altri termini, quanto tempo prima che qualcuno abbia una memoria portatile così grande?

La maggior parte dei metodi per interrompere la crittografia basata su hash si basa su attacchi di forza bruta. Un attacco arcobaleno è essenzialmente un attacco di dizionario più efficiente, è progettato per utilizzare il basso costo dell'archiviazione digitale per consentire la creazione di una mappa di un sottoinsieme sostanziale di possibili password per gli hash e facilitare la mappatura inversa. Questo tipo di attacco funziona perché molte password tendono ad essere piuttosto brevi o utilizzano uno dei pochi schemi di formati basati su parole.

Tali attacchi sono inefficaci nel caso in cui le password contengano molti più caratteri e non siano conformi ai formati basati su parole comuni. Un utente con una password complessa per cominciare non sarà vulnerabile a questo stile di attacco. Sfortunatamente, molte persone non scelgono buone password. Ma c'è un compromesso, puoi migliorare la password di un utente aggiungendo spazzatura casuale ad esso. Quindi ora, invece di "hunter2", la loro password potrebbe diventare effettivamente "hunter2908! Fld2R75 {R7 /; 508PEzoz ^ U430", che è una password molto più forte. Tuttavia, poiché ora è necessario archiviare questo componente password aggiuntivo, ciò riduce l'efficacia della password composita più forte. A quanto pare, c'è ancora un vantaggio netto in tale schema poiché ora ogni password, anche quelle deboli, non sono più vulnerabili alla stessa tabella hash / rainbow precalcolata. Al contrario, ogni voce hash della password è vulnerabile solo a una tabella hash univoca.

Supponi di avere un sito con requisiti di sicurezza della password deboli. Se non usi affatto la password salt i tuoi hash sono vulnerabili alle tabelle hash pre-calcolate, qualcuno con accesso ai tuoi hash avrebbe quindi accesso alle password per una grande percentuale dei tuoi utenti (comunque molte password vulnerabili usate, che sarebbe un percentuale sostanziale). Se usi una password costante salt, le tabelle hash pre-calcolate non sono più preziose, quindi qualcuno dovrebbe impiegare il tempo per calcolare una tabella hash personalizzata per quel salt, ma potrebbe farlo in modo incrementale, calcolando tabelle che coprono permutazioni sempre maggiori dello spazio problematico. Le password più vulnerabili (ad esempio semplici password basate su parole, password alfanumeriche molto brevi) verrebbero violate in poche ore o giorni, le password meno vulnerabili verrebbero violate dopo alcune settimane o mesi. Col passare del tempo un utente malintenzionato otterrebbe l'accesso alle password per una percentuale sempre crescente di utenti. Se si utilizza un salt unico per ogni password, occorrerebbero giorni o mesi per accedere a ciascuna di quelle password vulnerabili.

Come puoi vedere, quando passi da nessun sale a un sale costante a un sale unico imponi un aumento di diversi ordini di grandezza nello sforzo di decifrare le password vulnerabili ad ogni passaggio. Senza un sale le password più deboli dei tuoi utenti sono banalmente accessibili, con un sale costante quelle password deboli sono accessibili a un determinato aggressore, con un sale unico il costo di accesso alle password è aumentato così in alto che solo l'attaccante più determinato potrebbe ottenere l'accesso a un piccolo sottoinsieme di password vulnerabili, e quindi solo a grandi spese.

È proprio questa la situazione. Non puoi mai proteggere completamente gli utenti da una scelta sbagliata delle password, ma puoi aumentare il costo di compromettere le password dei tuoi utenti a un livello tale da compromettere in modo proibitivo persino la password di un utente.

Uno scopo della salatura è quello di sconfiggere le tabelle hash pre-calcolate. Se qualcuno ha un elenco di milioni di hash pre-calcolati, non sarà in grado di cercare $ 1 $ foo $ te5SBM.7C25fFDu6bIRbX1 nella loro tabella anche se conoscono l'hash e il sale. Dovranno comunque forzare la forza.

Un altro scopo, come menziona Carl S, è quello di rendere più costosa la forzatura di un elenco di hash. (dare loro tutti i diversi sali)

Entrambi questi obiettivi sono ancora raggiunti anche se i sali sono pubblici.

Per quanto ne so, il sale è destinato a rendere più difficili gli attacchi del dizionario.

È noto che molte persone useranno parole comuni per password anziché stringhe apparentemente casuali.

Quindi, un hacker potrebbe usare questo a suo vantaggio invece di usare solo la forza bruta. Non cercherà password come aaa, aab, aac ... ma invece utilizzerà parole e password comuni (come i nomi del Signore degli Anelli!;))

Quindi, se la mia password è Legolas, un hacker potrebbe provarlo e indovinarlo con "pochi" tentativi. Tuttavia, se saliamo la password e diventa fooLegolas, l'hash sarà diverso, quindi l'attacco del dizionario non avrà successo.

Spero che aiuti!

Suppongo che tu stia utilizzando PHP --- md5 () e $ variabili precedenti --- quindi, puoi provare a guardare questo articolo Shadow Password HOWTO Specialmente l'11 ° paragrafo.

Inoltre, hai paura di utilizzare algoritmi di digest dei messaggi, puoi provare algoritmi di crittografia reali, come quelli forniti dal modulo mcrypt , o algoritmi di digest dei messaggi più potenti, come quelli che forniscono il modulo mhash (sha1, sha256 e altri).

Penso che un algoritmo digest digest più forte sia un must. È noto che MD5 e SHA1 stanno avendo problemi di collisione.