Perché il sale non avrebbe impedito l'accesso alle password di LinkedIn?

Krebs fa seguito a questa domanda e Ptacek chiarisce cosa intende:

BK: Okay. So if the weakness isn’t with the strength of the cryptographic algorithm, and not with the lack of salt added to the hashed passwords, what’s the answer?

Ptacek: In LinkedIn’s case, and with many other sites, the problem is they’re using the wrong kind of algorithm. They use a cryptographic hash, when they need to use a password hash.

Nel prossimo paio di paragrafi, egli elabora anche le ragioni per questo. Il lungo e breve è che SHA1, con o senza sale, è troppo veloce per essere usato come un hash della password. È così veloce che quando si calcola usando una GPU o qualcosa di simile, si può eseguire una forza bruta di 10 secondi di migliaia di hash al secondo. Come viene spiegato più avanti nell'intervista, LinkedIn avrebbe dovuto usare bcrypt , che è un hash adattivo che avrebbe rallentato il tempo di forza bruta nell'ordine di 10 secondi di hash al secondo.

Diamo un'occhiata prima alla domanda salt e poi al problema della velocità:

Salve, attacchi dizionario e tabelle arcobaleno

Un sale aiuta in modo massiccio contro gli attacchi di dizionario nel caso comune di un utente malintenzionato che ha accesso a più hash di password.

Senza sale, un attaccante ordinerà tutti gli hash. Egli cancellerà la prima parola dal dizionario delle password e controllerà se l'hash calcolato è nella sua lista ordinata di hash rubati . Con un po 'di fortuna, ha già avuto accesso a più account.

Ma con un sale , deve attaccare ogni account separatamente .

Le tabelle arcobaleno sono solo un caso speciale di attacchi al dizionario, nel senso che sono state eseguite prima dell'attacco e sono pronte per l'uso.

È importante notare che: attaccare una stringa casuale a tutte le password renderà inutilizzabili le tabelle arcobaleno predefinite. Ma è ancora una cattiva idea a causa del problema di parallelismo descritto in precedenza.

Velocità, algoritmi per i documenti e per le password

Oltre a non usare sale, LinkedIn ha utilizzato un algoritmo di hash che è molto veloce e può essere eseguito su hardware speciale per una velocità ancora maggiore. Questo hardware speciale non è esotico ma fa parte delle comuni schede grafiche .

Robert David Graham ha pubblicato i dettagli del suo lavoro di cracking , compreso il rendimento dati:

2 billion per second using the Radeon HD 7970. A 6 [character] password [in] 500 seconds [...] with brute force.

Il caso d'uso originale per gli algoritmi hash era di firmare i documenti. Quindi essere veloci era un obiettivo di design.

I moderni algoritmi di hash per le password sono progettati per essere relativamente lenti . Un modo semplice per renderli più lenti è utilizzare la funzione hash ripetutamente. ShaCrypt e BCrypt sono tali algoritmi. Prestano particolare attenzione per impedire l'elaborazione parallela e la resistenza agli attacchi pre-immagine in un singolo round.

Scrypt fa un ulteriore passo avanti: oltre ad essere lento, richiede molta memoria (ad esempio 16 MB per la configurazione predefinita). Solitamente l'hardware specializzato ha accesso a circa 1 KB di memoria interna veloce. L'accesso alla memoria di base è lento. Pertanto la creazione di un crack cracker veloce nell'hardware diventa molto rapida molto rapidamente.

Hai ragione, ma ciò non cambia il fatto che è essenziale usare un sale. In questo caso, gli hacker hanno ottenuto le password hash, in modo che potessero utilizzare una tabella arcobaleno o iniziare un attacco di tipo brute force o dizionario.

• Una tabella arcobaleno ti porterà tutte le password (fino alle dimensioni e alla complessità nella tabella) in un brevissimo spazio di tempo.

• Allo stesso modo, un attacco di dizionario ti darà le password che sono nei dizionari.

• Forza bruta ti consente di ottenere rapidamente e rapidamente le password brevi e semplici, ma il tempo necessario per ottenere quelle più lunghe diventa così proibitivo che gli utenti con password lunghe sono ancora relativamente al sicuro.

Quindi un sale rimuove la prima serie di possibilità, costringendo gli aggressori a utilizzare le soluzioni dizionario e forza bruta, rendendo gli utenti più sicuri.

Ciò che fa un salato rende inutili le tabelle arcobaleno, il che rallenta i tentativi bruteforce sulla password.

Definizione di rainbow table:

A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes.

Senza sale, un utente malintenzionato potrebbe facilmente utilizzare una tabella arcobaleno pre-generata contenente milioni di password e il relativo equivalente di hash e confrontarla con la password.

Con un valore salt, ogni password richiede che l'attaccante generi una tabella arcobaleno completamente nuova.

Non ha alcun impatto sugli attacchi del dizionario - password semplici e ovvie basate su dizionario come la password verranno facilmente eliminate con o senza sale.

Un sale DOVREBBE essere usato comunque. Il cracking delle password riguarda tutto il tempo / lo sforzo. Nessuna password / hash è invincibile. Si tratta di costringere l'aggressore a trascorrere più tempo di quanto sia disposto a spendere per le tabelle delle password.

I sali prevengono il parallelismo. Il parallelismo è generico nell'intero continuum spazio-temporale; con questo intendo che può essere applicato space-wise e time-wise :

• Il parallelismo spazio-saggio è quando l'attaccante ha diversi hash da decifrare (questa è la situazione di LinkedIn). Con hash non salati, l'utente malintenzionato può cancellare una sola password potenziale e visualizzare il risultato nell'intero elenco di hash che desidera crack.

• Parallelismo tempo-saggio è quando l'attaccante precarica gli hash delle password comuni, in una grande tabella (arcobaleno o meno), per applicare su hash che successivamente ottiene.

Ciò che intendeva per Ptacek era:

• I sali fanno solo metà del lavoro; per davvero rallentare l'aggressore, è necessario un processo di hashing intrinsecamente lento, come bcrypt .

• Quando ci sono molti utenti, almeno alcune delle password saranno così deboli da essere incrinate, indipendentemente da quanta crittografia salata si faccia.

Quindi, mentre i sali avrebbero in qualche modo migliorato la situazione per LinkedIn, non li avrebbero salvati , solo ritardato e un po 'diluito il problema. Usare bcrypt o PBKDF2 avrebbe migliorato ulteriormente le cose, ma non al punto che la violazione potesse essere completamente ignorata.

Se un utente malintenzionato sfrutta un sistema e anche il sale viene compromesso, la differenza è che le tabelle arcobaleno pre-calcolate saranno inutili. (Qualsiasi password particolare potrebbe essere archiviata in diversi modi, a seconda delle dimensioni del sale). I tavoli Rainbow sono un compromesso tra tempo e spazio, sarebbe necessario molto più spazio.

Spero che aiuti. Un esempio è l'utilizzo di sale nel file shadow in UNIX, descritto chiaramente qui: Perché shadow?

Ptacek in realtà non dice che un sale non avrebbe impedito la violazione delle password di LinkedIn. Dovrei obiettare che, a seconda della dimensione del sale, avrebbe persino protetto la peggiore delle password.

L'unica debolezza SHA1 è la sua debolezza per un attacco di forza bruta. Tutto ciò che devi fare è generare X hash prima del tempo e confrontare il valore dell'hash SHA1 di una stringa con l'elenco di hash generato.

Con un sale a seconda delle dimensioni per generare in anticipo l'elenco ci vorrebbe molto tempo e una grande quantità di spazio su disco. Devi ricordare che si dovrebbe generare la stessa lista per ogni sale possibile. A questo punto, la tua unica speranza è provare ogni singola combinazione e sperare di trovare una corrispondenza. Se sei in grado di generare un sale unico per utente senza memorizzare il sale in un database, sei ancora più sicuro.

In altre parole ... Invece di craccare ogni singola password ... LinkedIn guarderebbe solo una piccola percentuale delle password degli utenti che sono trapelate (la peggiore delle peggiori).

Aggiorna

Where would you store the key?

Se fatto nel modo corretto, non è necessario memorizzarlo. Basta generare un salt basato sul nome utente, quando è stato creato l'account, o una combinazione dei due e si avrebbe un sale unico per l'utente specificato.

Quindi, a meno che l'origine del tuo sito Web non sia stata divulgata, tutti gli hacker non sarebbero in grado di generarlo. Potresti renderlo più sicuro e generare un nuovo salt quando l'utente ha modificato la password dell'account.

Una persona con le tabelle del database rubate ha solo 2 campi per utente.

password hash                                  salt
c32528b3e9191a8c7471252c6de289939a1e6f01       cGFzc3dvcmQ

Nei termini più basilari, nel modo in cui lo capisco, tutto ciò che fa la salatura è rendere la password più lunga .

La password originale era 'password'. Ma ho aggiunto la password prima di calcolare l'hash il sale cGFzc3dvcmQ per rendere passwordcGFzc3dvcmQ . Cosa fa? Bene, lo rende così se ti capita di avere una tabella arcobaleno di password comuni e i loro hash,

password                        hash
password                        5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

dove puoi vedere a colpo d'occhio che SHA('password')=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 , cercare la password originale dall'hash è troppo semplice. Vogliamo che il cracker debba fare del lavoro per questo.

Quindi andiamo "Dyoh! Abbiamo aggiunto o aggiunto QUESTO RANDOM STRING QUI alla password originale! Ora le tue tabelle hash di password comuni e i relativi hash sono inutili"

Quali sono. Perché abbiamo complicato ogni password con la stringa casuale, in pratica "migliorando le password dell'utente" e avvitando completamente gli hash, quindi ora sono completamente rari.

Quindi la salatura rende così ogni hash deve essere spezzato individualmente , perché per farlo, se il cracker ha i sali, il cracker deve aggiungere / anteporre il sale a ogni comune password ci prova. 2 utenti diversi potrebbero usare la semplice password password , ma cracking che sarà 2 lavori completamente separati per il cracker, a causa del sale. Quindi crackare tutte le password richiederà più tempo.

L' articolo qui dice che a causa della potenza di calcolo disponibile oggi, tuttavia, usando sali è banale da spezzare.