Sali segreti; perché rallentano l'aggressore più di quanto non facciano a me?

54

Quando studi le diapositive di Dan Boneh per 'Gestione delle sessioni e User Authentication '(2011) menziona' sali segreti 'sulla diapositiva' Ulteriori difese '(diapositiva 48 su 58).

Suggerisce di memorizzare nella base dati:

Alice|SA|H(pwA , SA , rA)

In cui Alice è il nome utente, SA il sale associato ad Alice e H(pwA , SA , rA) il risultato dell'asportazione della password di Alice pwA insieme al sale e un piccolo valore casuale rA .

Non capisco perché l'aggiunta di un breve valore casuale r (8 bit) rallenti la verifica di un fattore di 128 mentre un aggressore viene rallentato di un fattore di 256.

    
posta harm 06.12.2016 - 18:06
fonte

3 risposte

101

Questo probabilmente verrebbe spiegato nella conferenza uditiva che accompagnano queste diapositive.

La mia ipotesi è che sta calcolando questo assumendo che gli utenti in genere inseriscano le password corrette. Devi solo scorrere le opzioni per r finché non ne trovi una che produca un hash corretto.

Se hai ricevuto la password corretta, ti imbatterai in un r che produce un hash corretto; quando esattamente ciò accade varierà (dato che è casuale), ma in media passerai attraverso la metà delle opzioni totali (2 ** 8 = 256, 256/2 = 128) prima di trovarlo.

Tuttavia, l'utente malintenzionato di solito prova le password errate . Ciò significa che dovranno provare ogni singola opzione di r , che è il 256 completo.

    
risposta data 06.12.2016 - 18:44
fonte
15

Solo per aggiungere qualcosa di più alla risposta di Xiong :

In caso di compromissione di un database, un utente malintenzionato tenterà di recuperare tutte le password (o almeno quelle più interessanti), il che significa che deve provare ciascuna password per ciascun candidato con "sale segreto", che è piuttosto costoso

Nel frattempo il server ha solo bisogno di scorrere il possibile "sale segreto" con la password inserita dall'utente. È probabile che non solo la password sia corretta, ma è anche solo una per ogni accesso utente in

    
risposta data 06.12.2016 - 19:58
fonte
1

Oltre a quanto sopra:

protezione contro Rainbow Tables e (Distribuito) attacchi Bruteforce.

Le tabelle arcobaleno contengono i risultati di un determinato hash, ovvero se ne esiste uno per un determinato tipo di hashing (ad esempio sha1). Puoi semplicemente cercare il risultato e "decifrare" un set di hash abbastanza facilmente. Che non funziona se hai blocchi di hash o ogni singolo hash su di sé salato.

Lo stesso vale per gli attacchi Distributed Bruteforce. Se si tenta di decodificare / back indovinare un risultato hash (utilizzando i punti deboli di sicurezza in un algoritmo di hashing) è possibile utilizzarli per velocizzare gli hash simili. L'utilizzo di più macchine (la parte distribuita) che iniziano a guardare un ulteriore offset, aumenta notevolmente le possibilità di successo. Se il colpo può verificarsi ovunque in un determinato intervallo, la probabilità di un colpo aumenta notevolmente se si inizia su più offset contemporaneamente. Inoltre, qualsiasi hash scoperto può essere nuovamente testato rispetto agli altri hash all'interno del set che stai cercando di bruteforce.

Tutto ciò è reso inutile quando salti un hash, in quanto il risultato non è più lineare, prevedibile o ricercabile.

    
risposta data 07.12.2016 - 15:06
fonte