Perché i sali rendono "impossibili" gli attacchi del dizionario?


85

Aggiornamento: Nota che non sto chiedendo cos'è un sale, cos'è una tavola arcobaleno, cos'è un attacco del dizionario o qual è lo scopo di un sale. Sto chiedendo: se conosci gli utenti salt e hash, non è abbastanza facile calcolare la loro password?

Comprendo il processo e lo implemento io stesso in alcuni dei miei progetti.

s =  random salt
storedPassword = sha1(password + s)

Nel database memorizzi:

username | hashed_password | salt

Ogni implementazione del salting che ho visto aggiunge il salt alla fine della password o all'inizio:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

Pertanto, un attacco al dizionario da parte di un hacker che vale il suo sale (ah ah) eseguirà semplicemente ogni parola chiave contro i sali immagazzinati nelle combinazioni comuni elencate sopra.

Sicuramente l'implementazione sopra descritta aggiunge semplicemente un altro passaggio per l'hacker, senza effettivamente risolvere il problema sottostante? Quali alternative ci sono per aggirare questo problema o sto fraintendendo il problema?

L'unica cosa che posso pensare di fare è avere un algoritmo di miscelazione segreto che lega insieme il salt e la password in uno schema casuale, o aggiunge altri campi utente al processo di hashing, il che significa che l'hacker dovrebbe avere accesso al database E al codice per allacciare perché un attacco al dizionario si dimostrasse fruttuoso. (Aggiorna, come sottolineato nei commenti, è meglio presumere che l'hacker abbia accesso a tutte le tue informazioni, quindi questo probabilmente non è il migliore).

Vorrei fare un esempio di come propongo che un hacker possa hackerare un database utente con un elenco di password e hash:

Dati dal nostro database compromesso:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Dizionario delle password comuni:

   Common Password
   --------------
   letmein
   12345
   ...

Per ogni record utente, loop le password comuni e hash:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

Spero che questo illustri molto meglio il mio punto.

Date 10.000 password comuni e 10.000 record utente, dovremmo calcolare 100.000.000 hash per scoprire quante più password utente possibile. Potrebbero essere necessarie alcune ore, ma non è davvero un problema.

Aggiornamento sulla teoria del cracking

Daremo per scontato di essere un host web corrotto, che ha accesso a un database di hash e sali SHA1, insieme al tuo algoritmo per fonderli. Il database ha 10.000 record utente.

Questo sito afferma di essere in grado di calcolare 2.300.000.000 di hash SHA1 al secondo utilizzando la GPU. (Nel mondo reale la situazione probabilmente sarà più lenta, ma per ora useremo quella cifra citata).

(((95 ^ 4) / 2300000000) / 2) * 10000 = 177 secondi

Dato un intervallo completo di 95 caratteri ASCII stampabili, con una lunghezza massima di 4 caratteri, diviso per la velocità di calcolo (variabile), diviso 2 (assumendo che il tempo medio per scoprire la password richiederà in media il 50% di permutazioni) per 10.000 gli utenti impiegherebbero 177 secondi per elaborare tutte le password degli utenti la cui lunghezza è <= 4.

Regoliamolo un po 'per realismo.

(((36 ^ 7) / 1000000000) / 2) * 10000 = 2 giorni

Supponendo che non sia fatta distinzione tra maiuscole e minuscole, con una lunghezza della password <= 7, solo caratteri alfanumerici, ci vorrebbero 4 giorni per risolvere 10.000 record utente e ho dimezzato la velocità dell'algoritmo per riflettere circostanze generali e non ideali.

È importante riconoscere che questo è un attacco di forza bruta lineare, tutti i calcoli sono indipendenti l'uno dall'altro, quindi è un compito perfetto da risolvere per più sistemi. (IE è facile da configurare 2 computer che eseguono attacchi da estremità diverse che richiederebbero la metà del tempo di esecuzione).

Dato il caso di hashing ricorsivamente di una password 1.000 volte per rendere questa attività più costosa dal punto di vista computazionale:

(((36 ^ 7) / 1.000.000.000) / 2) * 1000 secondi = 10,8839117 ore

Rappresenta una lunghezza massima di 7 caratteri alfanumerici, a una velocità di esecuzione inferiore alla metà rispetto alla cifra indicata per un utente .

L'hashing ricorsivo 1.000 volte blocca efficacemente un attacco globale, ma gli attacchi mirati ai dati degli utenti sono ancora vulnerabili.


12
L'intero punto nel salting è impedirti di essere in grado di guardare la password con hash e vedere che più utenti hanno lo stesso hash (e quindi la stessa password). Senza il salting potresti semplicemente usare l'algoritmo di hashing e generare ogni possibile hash e quindi fare una ricerca bruta per quell'hash. Poiché l'algoritmo non cambia mai, lo rende prevedibile per gli aggressori, il salting lo rende molto più difficile.
BeRecursive

25
Perché i cracker sono come le lumache e il sale secca il muco sulla loro pelle e li uccide.
TED

6
@ TED: Mi piacciono piuttosto i cracker salati. Lumache salate, non così tanto.
FrustratedWithFormsDesigner

3
@ Tom - nel tuo esempio di attacco. Se non c'è il sale, l'attaccante può fare "per ogni password comune, hash la password. Corrisponde a uno o più utenti? Sì, ho la loro password" - l'attaccante può attaccare tutte le password "in parallelo" , senza costi aggiuntivi.
Damien_The_Unbeliever

3
@ Tom Gullen - hai solo metà dell'immagine. Senza sale, un utente malintenzionato non utilizzerebbe il metodo illustrato in "Aggiornamento 2". Avrebbe semplicemente fatto una ricerca in una tabella e avrebbe ottenuto la password in O (1) o O (log n) tempo (n è il numero di password candidate). Il sale è ciò che lo impedisce e lo costringe a usare l'approccio O (n) che dimostri. Un'altra tecnica (rafforzamento della chiave) può far sì che ogni tentativo nel tuo ciclo richieda un secondo intero, il che significa che ci vorranno 3 anni per eseguire quei test ... e con solo 10k password, è probabile che tu possa decifrare zero password in questo tempo.
erickson

Risposte:


31

Sì, ti bastano 3 giorni per sha1 (salt | password). Ecco perché buoni algoritmi di memorizzazione delle password utilizzano hashing a 1000 iterazioni: avrai bisogno di 8 anni.


3
+1, risposta molto concisa e al punto finora, non sapevo che fosse un'opzione.
Tom Gullen

Apparentemente non hai mai eseguito un benchmark hash sul tuo sistema. Puoi fare MOLTI MILIONI di calcoli sha1 al secondo. 1.000 round non hanno senso per un attaccante. Anche -1 perché sha1 è una funzione hash rotta.
torre

A quanto pare sto usando nomi e numeri dalla domanda. Se hai mai sentito parlare di argomenti come argomenti e chiarezza ... oh, è Rook. Non importa.
blaze

1
@Rook, 1.000 round significa che ci vorrà 1.000 volte più tempo per la forza bruta. Mi sembra una buona caratteristica.
Tom Gullen

se un utente malintenzionato può indovinare una password, è lo stesso per il login (o qualcosa mi è sfuggito? lol)
khaled_webdev

62

Non ferma gli attacchi al dizionario.

Quello che fa è impedire a qualcuno che riesce a ottenere una copia del file della tua password di utilizzare una tabella arcobaleno per capire quali sono le password dagli hash.

Alla fine, però, può essere forzato. La risposta a questa parte è costringere gli utenti a non utilizzare le parole del dizionario come password (requisiti minimi di almeno un numero o carattere speciale, ad esempio).

Aggiornamento :

Avrei dovuto menzionarlo in precedenza, ma alcuni (la maggior parte?) Sistemi di password utilizzano un salt diverso per ogni password, probabilmente memorizzato con la password stessa. Questo rende inutile un singolo tavolo arcobaleno. Ecco come UNIX libreria crypt ei moderni sistemi operativi UNIX-like hanno esteso questa libreria con nuovi algoritmi hash.

So per certo che il supporto per SHA-256 e SHA-512 è stato aggiunto nelle versioni più recenti di GNU crypt.


17
+1 Salt impedisce che elenchi precalcolati di hash (tabelle arcobaleno) siano utili. L'attaccante deve ricominciare tutto da capo.
Ian Boyd

2
In PHP, puoi utilizzare le librerie mcrypt o bcrypt per una migliore crittografia rispetto a md5 o sha1. Se sei bloccato con md5 o sha1 dovresti "allungare", dove hai hash la password migliaia di volte prima di arrivare a qualsiasi cosa sia memorizzata nel database. Ciò mantiene l'entropia la stessa, ma aumenta il tempo per calcolare l'hash.
Malfist

2
@ Tom Gullen, quali articoli stai leggendo? Esperti autoproclamati o articoli peer review in una rivista scientifica?
Malfist

7
Ed è il tuo sviluppatore Joe medio che pubblica quei blog / post di aiuto su come scrivere un sistema "sicuro". La sicurezza non è qualcosa che puoi cogliere di lato, richiede una conoscenza approfondita. È ingiusto? Probabilmente. È sicuro? Fino a un certo punto. Ci sono ragioni per cui ci sono esperti di sicurezza. Ma poi di nuovo, non tutto deve essere sicuro come Fort Knox. La migliore politica qui è quella di utilizzare un sistema precostruito progettato da quegli esperti e modificarlo per soddisfare le proprie esigenze.
Malfist

3
@ Michael: con un sale più lungo, è necessario precalcolare tutti i possibili valori di sale, affinché compaia nella tabella arcobaleno. Il punto è che non mantieni lo stesso sale per tutte le password, lo scegli a caso per ogni password e lo memorizzi nel database accanto alla password con hash salata memorizzata. Quindi, un hacker avrebbe bisogno di una voce nella tabella arcobaleno per ogni possibile sale di grande valore, rendendo la tabella troppo grande per essere fattibile, che è il punto.
Colin DeClue

31

Per essere più precisi, un attacco al dizionario , cioè un attacco in cui vengono provate tutte le parole di un elenco esaustivo, non diventa "impossibile", ma diventa poco pratico : ogni bit di sale raddoppia la quantità di memoria e calcolo richiesta .

Questo è diverso dagli attacchi di dizionario precalcolati come gli attacchi che coinvolgono le tabelle arcobaleno in cui non importa se il sale è segreto o meno.

Esempio: con un salt a 64 bit (cioè 8 byte) devi controllare 2 64 combinazioni di password aggiuntive nel tuo attacco al dizionario. Con un dizionario contenente 200.000 parole dovrai fare

200.000 * 2 64 = 3,69 * 10 24

test nel caso peggiore - invece di 200.000 test senza sale.

Un ulteriore vantaggio dell'utilizzo di salt è che un utente malintenzionato non può pre-calcolare gli hash delle password dal suo dizionario. Ci vorrebbe semplicemente troppo tempo e / o spazio.

Aggiornare

Il tuo aggiornamento presume che un utente malintenzionato conosca già il sale (o lo abbia rubato). Questa è ovviamente una situazione diversa. Tuttavia non è possibile per l'attaccante utilizzare una tabella arcobaleno precalcolata. Ciò che conta molto qui è la velocità della funzione di hashing. Per rendere un attacco impraticabile, la funzione di hashing deve essere lenta. MD5 o SHA non sono buoni candidati qui perché sono progettati per essere veloci, i candidati migliori per gli algoritmi di hashing sono Blowfish o alcune varianti di esso.

Aggiorna 2

Una buona lettura in merito alla protezione degli hash delle password in generale (andando molto oltre la domanda originale ma comunque interessante):

Basta con le tabelle arcobaleno: quello che devi sapere sugli schemi di password sicure

Corollario dell'articolo: usa hash salati creati con bcrypt (basato su Blowfish) o Eksblowfish che ti consente di utilizzare un tempo di configurazione configurabile per rallentare l'hashing.


4
@Tom Gullen - anche con politiche di password complesse ragionevoli, è probabile che un dizionario di centinaia di milioni o pochi miliardi di candidati ottenga alcuni risultati, perché tutte le password non sono ugualmente probabili (perché le persone usano mnemonici, piuttosto che RNG, per sceglierle) . Un dizionario di quella dimensione è precomputabile sui sistemi di merci se il sale non viene utilizzato. Se viene utilizzato salt, l'attaccante deve ricalcolare gli hash ogni volta e, se vengono eseguite sufficienti iterazioni dell'hash, la velocità di attacco dell'attaccante può essere rallentata a pochi tentativi al secondo.
erickson

3
-1 da parte mia: essere tenuti segreti non è assolutamente il punto dei sali. Hai bisogno che siano comunque accessibili per controllare le password, quindi qualsiasi tentativo di mantenerle segrete rischia di rendere il sistema più vulnerabile a causa della complessità aggiuntiva piuttosto che effettivamente avere successo.
Michael Borgwardt

2
@ 0xA3: ancora una volta: essere sconosciuti a un aggressore non è il punto di un sale . La tua macchina deve accedervi in ​​qualche modo, quindi anche un utente malintenzionato che irrompe nella macchina può ottenerlo. Qualsiasi scenario in cui l'attaccante non conosce il sale è una falsa pista.
Michael Borgwardt

1
Penso che valga la pena ricordare che l'articolo collegato descrive male le tabelle arcobaleno. Quello che descrive è un semplice allegato di dizionario. I tavoli arcobaleno sono davvero molto diversi (e un po 'più complessi). C'è una spiegazione abbastanza decente di come funzionano davvero le tabelle arcobaleno su: kestas.kuliukas.com/RainbowTables
Jerry Coffin

3
-1 per "Ovviamente il sale deve essere tenuto segreto". Se un utente malintenzionato ha accesso agli hash della tua password, avrà anche i tuoi sali: ciò di cui hai bisogno sono i sali per utente , non la sicurezza attraverso l'oscurità di un sale "nascosto".
snemarch

17

Un dizionario è una struttura in cui i valori sono indicizzati da chiavi. Nel caso di un attacco di dizionario precalcolato, ogni chiave è un hash e il valore corrispondente è una password che risulta nell'hash. Con un dizionario precalcolato in mano, un utente malintenzionato può cercare "istantaneamente" una password che produrrà l'hash necessario per accedere.

Con il sale, lo spazio necessario per memorizzare il dizionario cresce rapidamente ... così rapidamente che tentare di pre-calcolare un dizionario delle password diventa presto inutile.

I migliori sali vengono scelti casualmente da un generatore di numeri casuali crittografici. Otto byte sono una dimensione pratica e più di 16 byte non servono a nulla.


Il sale fa molto di più che "rendere più irritante il lavoro di un aggressore". Elimina un'intera classe di attacchi: l'uso di dizionari precalcolati.

Un altro elemento è necessario per proteggere completamente le password, ovvero il "rafforzamento delle chiavi". Un round di SHA-1 non è abbastanza buono: un algoritmo di hashing della password sicuro dovrebbe essere molto lento dal punto di vista computazionale.

Molte persone usano PBKDF2, una funzione di derivazione della chiave, che restituisce i risultati alla funzione hash migliaia di volte. L'algoritmo "bcrypt" è simile, utilizzando una derivazione della chiave iterativa che è lenta.

Quando l'operazione di hashing è molto lenta, una tabella precalcolata diventa sempre più desiderabile per un utente malintenzionato. Ma il sale adeguato sconfigge questo approccio.


Commenti

Di seguito sono riportati i commenti che ho fatto sulla domanda.


Senza sale, un utente malintenzionato non utilizzerebbe il metodo dimostrato in "Update 2". Avrebbe semplicemente fatto una ricerca in una tabella precalcolata e avrebbe ottenuto la password in O (1) o O (log n) tempo (n è il numero di password candidate). Il sale è ciò che lo impedisce e lo costringe a usare l'approccio O (n) mostrato in "Update 2".

Una volta ridotto ad un attacco O (n), dobbiamo considerare quanto tempo impiega ogni tentativo. Il rafforzamento delle chiavi può far sì che ogni tentativo nel ciclo richieda un secondo intero, il che significa che il tempo necessario per testare 10.000 password su 10.000 utenti si estenderà da 3 giorni a 3 anni ... e con solo 10.000 password, è probabile che tu riesca a decifrare zero password in quel momento.

Devi considerare che un utente malintenzionato utilizzerà gli strumenti più veloci che può, non PHP, quindi migliaia di iterazioni, anziché 100, sarebbero un buon parametro per il rafforzamento delle chiavi. Dovrebbe impiegare una grossa frazione di secondo per calcolare l'hash per una singola password.

Il rafforzamento della chiave fa parte degli algoritmi standard di derivazione della chiave PBKDF1 e PBKDF2, da PKCS # 5, che creano ottimi algoritmi di offuscamento delle password (la "chiave derivata" è l '"hash").

Molti utenti su StackOverflow fanno riferimento a questo articolo perché era una risposta al post di Jeff Atwood sui pericoli delle tabelle arcobaleno. Non è il mio articolo preferito, ma discute questi concetti in modo più dettagliato.


Ovviamente presumi che l'attaccante abbia tutto: salt, hash, nome utente. Supponiamo che l'aggressore sia un dipendente della società di hosting corrotto che ha scaricato la tabella degli utenti sul tuo fansite myprettypony.com. Sta cercando di recuperare queste password perché si girerà e vedrà se i tuoi fan di pony hanno usato la stessa password sui loro account citibank.com.

Con uno schema di password ben progettato, sarà impossibile per questo ragazzo recuperare le password.


1
Penso che con "attacco dizionario", Tom si riferisca a provare password deboli note (cioè direttamente da un dizionario di linguaggio umano), non tabelle di testo in chiaro hash precalcolate - questo è anche ciò a cui penso per la prima volta quando leggo "dizionario" in questo contesto.
Michael Borgwardt

@Michael Borgwardt: Sono d'accordo, @erickson si riferisce ad attacchi al dizionario precalcolati.
Dirk Vollmar

1
Salt blocca gli attacchi al dizionario precalcolati. Il rafforzamento delle chiavi blocca gli attacchi al dizionario. Entrambi devono essere usati insieme per l'autenticazione sicura della password.
erickson

Voglio dire semplici tavoli inglesi sì. La domanda mira ad affrontare il problema di come impedire a un hacker di elaborare tutte le possibili combinazioni di hash per ogni account utente
Tom Gullen

7

Lo scopo della salatura è impedire l'ammortamento dello sforzo dell'aggressore.

Senza sale, una singola tabella di voci hash-password precalcolate (ad esempio MD5 di tutte le stringhe di 5 caratteri alfanumerici, facili da trovare online) può essere utilizzata su ogni utente in ogni database del mondo.

Con un sale specifico per il sito, l'attaccante deve calcolare la tabella da solo e può quindi utilizzarla su tutti gli utenti del sito.

Con un sale per utente, l'attaccante deve spendere questo sforzo per ogni utente separatamente.

Naturalmente, questo non fa molto per proteggere le password veramente deboli direttamente da un dizionario, ma protegge le password ragionevolmente forti da questo ammortamento.


1
Risposta breve e precisa: vale la pena aggiungere che senza sale o con sale a livello di sito, puoi facilmente individuare gli utenti con la stessa password e dovrai solo forzarne una. Con i sali per utente, non puoi farlo.
snemarch

6

Inoltre, un altro punto importante, l'utilizzo di un sale specifico per USER impedisce il rilevamento di due utenti con la STESSA password: i loro hash corrisponderebbero. Ecco perché molte volte l'hash è hash (salt + nome utente + password)

Se si tenta di mantenere segreto l'hash, anche l'attaccante non può verificare gli hash.

Modifica: ho appena notato che il punto principale è stato fatto in un commento sopra.


1
È necessario modificare per specificare il sale per utente; i siti che utilizzano un salt a livello di sito consentiranno comunque di rilevare password identiche.
snemarch

@snemarch - Sì, grazie mille per questa importante distinzione!
Dominik Weber

5

I sali sono implementati per prevenire attacchi al tavolo arcobaleno. Una tabella arcobaleno è un elenco di hash precalcolati, che rende la traduzione di un hash nella sua frase molto più semplice. Devi capire che il salting non è efficace come prevenzione moderna per decifrare una password a meno che non abbiamo un algoritmo di hashing moderno.

Quindi diciamo che stiamo lavorando con SHA1, sfruttando i recenti exploit scoperti con questo algoritmo, e diciamo che abbiamo un computer che funziona a 1.000.000 di hash / secondo, ci vorrebbero 5,3 milioni di milioni di milioni di anni per trovare una collisione , quindi sì php può funzionare 300 al secondo, grande woop, non importa. Il motivo per cui saliamo è perché se qualcuno si preoccupasse di generare tutte le frasi comuni del dizionario, (2 ^ 160 persone, benvenute agli exploit dell'era 2007).

Quindi ecco un database reale, con 2 utenti che utilizzo per scopi di test e amministrazione.

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

In effetti, lo schema di salatura è il tuo sha1 (tempo di registrazione + nome utente). Avanti, dimmi la mia password, queste sono vere password in produzione. Puoi anche sederti lì e fare l'hash di un elenco di parole in php. Scatenati.

Non sono pazzo, so solo che questo è sicuro. Per divertimento, la password del test ètest . sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

Si avrebbe bisogno di generare un intero tavolo arcobaleno perpended con 27662aee8eee1cb5ab4917b09bdba31d091ab732per solo questo utente. Ciò significa che posso effettivamente consentire alle mie password di non essere tutte compromesse da una singola tabella arcobaleno, l'hacker deve generare un'intera tabella arcobaleno per 27662aee8eee1cb5ab4917b09bdba31d091ab732 per il test, e ancora f3f7735311217529f2e020468004a2aa5b3dee7f per briang. Ripensa ai 5,3 milioni di milioni di milioni di anni per tutti gli hash. Pensa alla dimensione di memorizzare solo i 2 ^ 80 hash (che sono ben oltre 20 yottabyte ), non succederà.

Non confondere il salting come mezzo per creare un hash qualcosa che non puoi mai decodificare, è un mezzo per impedire a una tabella arcobaleno di tradurre tutte le tue password utente. È impossibile a questo livello di tecnologia.


Capisco cos'è un tavolo arcobaleno, ma ti manca il punto della mia domanda. Se mi hai fornito il tuo algoritmo di salting, una password con hash e il salt, allora sì, probabilmente potrei dirti qual era la tua password entro pochi minuti.
Tom Gullen

Metti i tuoi soldi dove è la tua bocca?
Incognito

Certo, ma mi hai appena detto qual è la password nel tuo esempio, dammi un salt, una password con hash e come combini salt + password (non ricorsiva) e fintanto che la password <= 5 caratteri alfanumerici minuscoli (senza spazi bianchi / caratteri speciali) Ti farò sapere cosa c'è in questa casella. Se vuoi che ci metta i soldi come suggerisci, fammelo sapere, anche se il mio commento di pochi minuti è probabilmente una grossolana sottovalutazione, ma entro poche ore sì.
Tom Gullen,

1
Forse secondi in realtà, vedere golubev.com/hashgpu.htm che utilizza la GPU per calcolare come indicato " 2300 M / s SHA1 hash al secondo". Con una gamma completa di 95 caratteri ASCII che vanno da 1 a 6 caratteri, possiamo decifrarlo in <6 minuti. Se abbiamo solo caratteri alfanumerici minuscoli, fino a 8 caratteri di lunghezza <25 minuti. Con un database di 10.000 record utente, possiamo trovare tutte e 4 le password ASCII complete di caratteri in <200 secondi ((((95 ^ 4) / 2300000000) / 2) * 10000). (Un sovraccarico maggiore di quanto indicato e le velocità della GPU citate sono probabilmente situazioni ideali).
Tom Gullen,

Sì, il salting non ti impedisce di poter forzare la password. Rende più difficile generare il ((10 ^ 5) * (94 ^ 10)) = 10 ^ 24 se gli utenti hanno password di circa 10 caratteri, il che è molto più difficile del 10 ^ 19 senza hash. Ancora una volta, non è per rendere difficile la violazione di una password, ma per rendere impossibile la violazione di tutte le password con una tabella arcobaleno pre-elaborata. (e controlla i miei calcoli qui, ma credo che 10 ^ 25/2300000000/60/60/24/365/1000 = 137869 ~ milinea per la password di tutti). Se vogliamo password più sicure non le saliamo, usiamo cose come lo scambio di chiavi Diffie – Hellman.
Incognito

3

L'idea alla base dell'attacco del dizionario è che si prende un hash e si trova la password, da cui è stato calcolato l' hash , senza il calcolo dell'hash. Ora fai lo stesso con la password salata: non puoi.

Non utilizzare un salt rende la ricerca della password facile come la ricerca nel database. L'aggiunta di un salt fa sì che l'attaccante esegua il calcolo hash di tutte le possibili password (anche per l'allegato del dizionario questo aumenta significativamente il tempo di attacco).


Nello scenario dell'OP, l'attaccante ha i sali dal database e dovrà provare ogni sale con ogni voce nel "dizionario". ...Credo.
FrustratedWithFormsDesigner

2

In termini più semplici: senza salting, ogni password candidata deve essere sottoposta ad hashing solo una volta per confrontarla con ogni utente, ovunque nell '"universo conosciuto" (raccolta di database compromessi), la cui password viene sottoposta ad hashing tramite lo stesso algoritmo. Con il salting, se il numero di possibili valori di sale supera sostanzialmente il numero di utenti nell '"universo noto", ogni password candidata deve essere sottoposta ad hashing separatamente per ogni utente rispetto al quale verrà testata.


2

In poche parole, il salting non impedisce a un hash di attaccare (bruteforce o dizionario), ma lo rende solo più difficile; l'attaccante dovrà trovare l'algoritmo di salting (che se implementato correttamente farà uso di più iterazioni) o forzare l'algoritmo, che a meno che non sia molto semplice, è quasi impossibile. La salatura inoltre elimina quasi completamente l'opzione delle ricerche nelle tabelle arcobaleno ...


1

Il sale rende gli attacchi alla tabella Rainbow molto più difficili poiché rende un singolo hash della password molto più difficile da decifrare. Immagina di avere una password orribile solo del numero 1. Un attacco al tavolo arcobaleno lo risolverebbe immediatamente.

Ora immagina che ogni password nel db sia salata con un valore casuale lungo di molti caratteri casuali. Ora la tua pessima password "1" è memorizzata nel db come un hash di 1 più un mucchio di caratteri casuali (il sale), quindi in questo esempio la tabella arcobaleno deve avere l'hash per qualcosa come: 1.

Quindi, supponendo che il tuo salt sia qualcosa di sicuro e casuale, diciamo ()% ISLDGHASKLU ( % #% #, la tabella arcobaleno dell'hacker dovrebbe avere una voce per 1 * ()% ISLDGHASKLU (*% #% #. Ora usando una tabella arcobaleno anche su questa semplice password non è più pratica.


Si prega di consultare l'aggiornamento n. 2, si dovrebbero semplicemente avere password non elaborate e calcolare tutti gli hash rispetto ai sali per ogni record utente.
Tom Gullen

2
Certo Tom, sono d'accordo, ma il punto è che l'hacker deve eseguire quel brutto processo che richiede tempo una volta per ogni password se viene utilizzato il sale. Pertanto, il sale rende più difficile l'uso di un tavolo arcobaleno.
Cory House

3
@Tom Gullen: la generazione di tabelle arcobaleno salate è fattibile solo se vengono utilizzati sali a livello di sito; il salting per utente rende gli attacchi alle tabelle arcobaleno praticamente inutili.
snemarch
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.