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

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.

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.

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.

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 ⁶⁴ combinazioni di password aggiuntive nel tuo attacco al dizionario. Con un dizionario contenente 200.000 parole dovrai fare

200.000 * 2 ⁶⁴ = 3,69 * 10 ²⁴

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.

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.

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.

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.

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.

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).

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.

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 ...

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.