In che modo un sistema autentica un utente utilizzando una funzione di hash, dopo che è stato salato?

Quando si hash la password per la prima volta (quando l'utente si registra), si utilizza un salt e si memorizzano sia il salt che l'hash risultante nel database.

La seconda volta (quando provano ad accedere di nuovo), usi il tuo nome utente per estrarre il sale e l'hash dal database. Si utilizza il sale per hash la propria password e si confrontano i due hash.

Ci si potrebbe chiedere "ma se qualcuno accede al mio database, hanno tutti i sali - non è un problema enorme?". Il fatto che abbiano i sali non è un problema, poiché lo scopo del sale non è quello di aggiungere qualcosa di "segreto", ma è quello di garantire che se due utenti hanno la stessa password hanno diversi hash poiché gli hash sono stati creati con diversi sali.

Se non hai usato sali, o se hai usato esattamente lo stesso sale per ogni utente (purtroppo non è un errore raro), ci saranno molti hash duplicati (dal momento che alcune persone useranno la stessa password, e quelli le password identiche avranno tutti hash identici). Se qualcuno accede al tuo database, può cercare gli hash che appaiono più spesso, concentrarsi sul cracking di quegli hash, e per ognuno che riescono a crack hanno accesso a più account. Salendo ogni hash in modo diverso, è molto probabile che non ci siano degli hash duplicati: i diversi sali significano che anche le password duplicate avranno hash differenti. Per ogni hash che incrinano, ottengono l'accesso a esattamente un account - non di più. Questo è lo scopo del sale.

Il sale è memorizzato con l'hash, per esempio in un campo di database separato o è taggato alla fine dell'hash o il nome utente è usato come sale.

Lo scopo è che anche se due utenti hanno la stessa password, i loro sali saranno diversi e quindi i loro hash non saranno gli stessi.

Questo è utile se qualcuno riesce a rubare il database, dovranno crackare separatamente ciascuna hash + combinazione di sale. Quindi, nel caso dei nostri due utenti che condividono la stessa password, l'utente malintenzionato non saprà di essere lo stesso fino a quando non li incrinerà entrambi.

È anche il caso che senza Sali l'utente malintenzionato può generare gli hash delle password comuni e controllarli rispetto al database rubato. Salting rende inutili queste tabelle arcobaleno generate.

L'utente invia sempre la password effettiva al server e il server memorizza i valori salt e hash. Il punto di un salt è semplicemente quello di assicurarsi che se il DB è compromesso, un utente malintenzionato non può provare a forzare brute forzando tutte le password contemporaneamente. Inoltre impedisce l'identificazione delle password riutilizzate.

Non importa se il sale diventa di dominio pubblico perché non riduce il lavoro di chi attacca per sapere il sale, dal momento che devono solo provare ogni password fino a quando non ottengono una corrispondenza. L'hashing viene eseguito sul server in modo che il client non possa semplicemente restituire l'hash così come viene visualizzato nel DB senza conoscere la password.

Grandi risposte finora, ma una cosa che penso dovrebbe essere menzionata anche perché non è molto chiara dall'articolo a cui si fa riferimento. La funzione di hashing viene eseguita contro il sale concatenato insieme alla password e quindi il sale viene nuovamente concatenato con l'hash risultante dalla funzione e quella stringa è ciò che è memorizzato nel database delle password come / etc / shadow.

Un vero esempio

Questo esempio mostra cosa succede quando un utente sceglie la sua password su un sistema Unix, come viene memorizzato in / etc / shadow e come viene controllata la password quando l'utente esegue il login. Utilizzerò invece esempi reali di nomi variabili o stringhe come foobar. Ignorerò anche cose come pam per renderlo un po 'più semplice.

1. Utente 'monroe' esegue il programma passwd e sceglie la password 'HorseStapler + 5'
2. Il programma passwd riceve la password, la controlla (per le regole di validità), quindi determina quale algoritmo deve utilizzare per l'hashing, (DES, MD5, SHA-256, SHA-512) Diciamo che il sistema sceglie SHA- 512 per il suo algoritmo di hashing.
3. L'algoritmo SHA-512 utilizza una stringa casuale di 16 caratteri per il suo sale composto da caratteri alfanumerici + '.' e '/' . Il sistema genera una stringa salt casuale "BohpaS.aul0Qua / t".
4. Il sistema ora concatena il sale sulla password come questo 'HorseStapler + 5BohpaS.aul0Qua / t'. Questo è il "nuovo" testo in chiaro che verrà in realtà sottoposto a hash e memorizzato. Lo rende più unico in modo che chiunque usi la password "HorseStapler + 5" a causa della sua popolarità non risulti nello stesso hashtext nel database delle password. Protegge anche dagli attacchi dei tavoli arcobaleno.
5. Il sistema esegue l'algoritmo hash sulla nuova stringa SHA512 ('HorseStapler + 5BohpaS.aul0Qua / t') e ottiene l'output hashtext 'IVUen1dSKZ634jM.KLQ1Am / WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1'
6. In modo che il sistema possa autenticare l'utente in futuro, memorizza il sale e un indicatore per il tipo di hashing utilizzato nel file / etc / shadow come la seguente stringa nel secondo campo (campo crittografato) per quello la voce dell'utente come questa '$ 6 $ BohpaS.aul0Qua / t $ IVUen1dSKZ634jM.KLQ1Am / WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1'

La voce completa in / etc / shadow è la seguente:

monroe:$6$BohpaS.aul0Qua/t$IVUen1dSKZ634jM.KLQ1Am/WPh..DSO2MYI53qffac2IFzESKwIufyVjzQGlxNenOXGehMTCdSoL9DLPe6Zfm1:15196:0:99999:7:::

La parte $ 6 $ indica che si trattava di hash SHA-512. La parte tra il 2 ° e il 3 ° carattere '$' memorizza il sale che è stato usato. Questo campo nel file shadow è chiamato campo crittografato. Ad alcune persone questo nome non piace perché è hash, non crittografato. Crittografato implica che può essere decodificato, cosa che non può. Tuttavia, mi riferirò ad esso come il campo della password crittografato.

Re-autenticazione

1. La volta successiva che l'utente monroe accede al sistema, invia la password "HorseStapler + 5".
2. Il sistema ricerca l'utente in / etc / shadow e trova la stringa completa sopra. Il sistema prende la parte salt di esso (la parte tra il 2 ° e il 3 ° '$') e poi la concatena con la password come sopra. Quindi blocca quello usando l'algoritmo SHA-512 come indicato dall'algoritmo designatore '6' tra il 1 ° e il 2 ° '$'.
3. Il sistema confronta quindi l'hashtext risultante con la stringa dopo il terzo '$' nel campo della password crittografata del file shadow.

Si spera che questo dimostri perché l'algoritmo di hashing deve essere solo un algoritmo a senso unico e come viene usato esattamente il sale.

Il motivo del file shadow è perché il file / etc / password deve essere leggibile da un mondo su un sistema unix. Hanno usato per memorizzare la password crittografata (e molto tempo fa la password cleartext anche) nel 2 ° campo del file / etc / password. Lo hanno spostato nel file shadow e hanno dato solo l'accesso come root a quel file e il meccanismo di autenticazione ha bisogno dei privilegi di root per autenticarti.

Bene, questo ha finito per essere molto più lungo di quanto pensassi.