Quanto sarebbe difficile eliminare gli hash di bcrypt se il sale è sconosciuto? [duplicare]

5

(Questo non è un duplicato della domanda collegata IMHO in quanto si tratta più delle differenze tra una password salt e password: entrambe le variabili utilizzate per generare un hash)

Supponiamo che un utente malintenzionato abbia accesso offline a un database in cui le password sono state sottoposte a hash con bcrypt (senza aggiunta di pepe). Gli hash sembrano:

$2y$10$H0mRpD2XJZDguAzxTehwzunRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

In cui sale è: H0mRpD2XJZDguAzxTehwzu e l'hash è nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G .

L'autore dell'attacco non sarà in grado di eseguire una tabella arcobaleno in modo che corrisponda agli hash, ma potrebbe calcolare le password comuni utilizzando il sale incluso, quindi eseguendo:

bcrypt("abcd1234", 10, "H0mRpD2XJZDguAzxTehwzu")

produrrà:

nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G

Ed ecco! Potrebbe passare attraverso tutti i test del database "abcd1234" ed essere in grado di identificare quali utenti utilizzano quella password debole in pochi secondi / minuti.

Quindi cosa succede se nel database è memorizzato solo l'hash nRkjUR8lB3O4UGrAGLiqJuvnlWjFA7G (senza sale)?

Se l'attaccante ha la netta sensazione che l'utente "abcdefg" possa usare la password "abcd1234", come potrebbe testare la sua teoria offline? Avrebbe avuto bisogno di indovinare il sale. Come ha potuto farlo? C'è un metodo più semplice di provare ogni combinazione? Forse in quel caso specifico non ci sarà abbastanza motivazione per provarlo. Ma cosa succede se sospetta che il sistema stia usando lo stesso sale per tutte le password (dato che alcuni hash sono uguali)? Quanto sarebbe difficile per lei rompere?

Aggiorna

La risposta di Peleo è vicina a quello che mi aspettavo. Proverò ad estenderlo (correggimi se sbaglio):

Entropy :

In Bcrypt un sale è solitamente composto da 16 byte casuali (128 bit). Se lo confrontiamo con una password della stessa lunghezza, allora un sale avrà una grata entropia rispetto a una password, in quanto le password di solito sono limitate a ciò che l'utente può digitare con una tastiera.

Quei 16 byte sono codificati in HEX (usando Base64) e diventano 22 di lunghezza. Se li confrontiamo con una password di 22 caratteri, la password conterrà una maggiore entropia (in quanto può includere simboli e l'alfabeto completo).

Lunghezza :

I sali di Bcrypt sono limitati a 16 byte, mentre le password possono essere limitate a 72 byte, a seconda dell'implementazione.

Collision :

2 diversi sali genereranno 2 diversi hash e quindi le password. Tuttavia, a un certo punto, 2 diversi sali potrebbero produrre lo stesso hash utilizzando la stessa password e viceversa. Qual è la probabilità per ciascuno di questi casi? Questo è qualcosa che dovrei chiedere in crypto.SE. Ma lo lascio qui nel caso qualcuno abbia la risposta.

design :

L'algoritmo è stato progettato per proteggere le password e non i sali. Ciò significa che i sali non sono sicuri di essere sicuri dalla progettazione, il che suggerisce che potrebbe esserci un modo per ottenerli senza costringerli brutalmente.

Caso fittizio :

Siamo abituati al metodo della password utente per proteggere l'accesso a un sistema. Ma, cosa succede se succede qualcosa del genere (per favore nuda con me, è solo un esempio)?:

L'azienda CauseWeWantItThatWay utilizza microchip per memorizzare un valore di 22 caratteri esadecimali (da utilizzare come sale). Ogni utente genererà un totale di 5 password o numeri PIN (4 cifre ciascuno, sì, sono pigri) con quel sale unico per accedere a 5 sistemi diversi.

Ora supponiamo di essere assegnato a uno di questi sistemi e conosco uno di quei numeri PIN, e in qualche modo ho accesso al database. Se il sale fosse incluso, sarebbe banale ottenere quei numeri PIN, tuttavia senza sale, dovrei romperlo.

So cosa stai pensando. L'azienda ha una pessima implementazione della sicurezza (e dovrebbero bruciare all'inferno). Inoltre, avrebbero potuto usare il "sale" come pepe e lasciare il sale a caso. Quindi la mia domanda era, in quel caso, sarebbe stato lo stesso aggiungere un carattere di 22 esadecimali come pepe piuttosto che usare quelli come il sale? Secondo Peleus, è lo stesso (quindi non esiste alcuna scorciatoia per ottenere il sale).

Dopo tutto non tutti seguono i consigli e l'algoritmo ti permette di impostare il sale, il che rende questo tipo di scenario totalmente possibile (anche se non così probabile né raccomandato).

    
posta lepe 25.07.2016 - 08:16
fonte

3 risposte

8

Penso che tu abbia frainteso lo scopo di un sale, perché se hai capito che cosa è progettato per raggiungerti forse non farei questa domanda. L'unico scopo è quello di fornire un livello di univocità a ciascuna password al fine di evitare che le tabelle precalcolate ("tavole arcobaleno") siano una forma efficace di attacco.

Di conseguenza, non è progettato per essere "segreto" o aggiungere entropia alla password in alcun modo, ed è per questo che viene memorizzato insieme all'hash della password. Infatti nella maggior parte dei casi non può essere segreto perché l'applicazione stessa avrà bisogno di accedere a Salt per calcolare l'hash corretto della password. È molto difficile consentire l'accesso all'applicazione, ma impedire a un utente malintenzionato che ha violato l'applicazione di ottenere lo stesso privilegio.

In ogni caso, per rispondere alla tua domanda reale - in un mondo teorico in cui dovevi "crackare" il sale perché era sconosciuto e non poteva essere recuperato per qualche motivo, sarebbe esattamente lo stesso livello di complessità delle password. Fondamentalmente (spazio caratteri) ^ (lunghezza).

Nel tuo esempio fornisci un hash di "H0mRpD2XJZDguAzxTehwzu". Supponendo caratteri alfanumerici maiuscoli / minuscoli che sia uno spazio di caratteri di 62 caratteri e che abbia una lunghezza di 22 caratteri. Quindi 62 ^ 22 = 3.397504e + 23 anni di ipotesi supponendo 1 miliardo di ipotesi al secondo. In altre parole, non è disconnessa (questo è anche supponendo che la password sia nota e stai provando a indovinare semplicemente un sistema salato).

    
risposta data 25.07.2016 - 13:20
fonte
4

Un sale è memorizzato accanto alla password. Non esiste una regola che dice che DEVE essere così, ma è un risultato logico della destinazione di un sale. Costruire un tavolo arcobaleno non è un compito banale. Il punto del sale è che l'attaccante avrebbe bisogno di una tabella arcobaleno separata per ogni password salata (nel qual caso è più semplice attaccare direttamente ogni hash della password).

Puoi leggere una lunga risposta sul sale , che dovrebbe chiarire il motivo per cui non ha senso tenerlo segreto.

Se vuoi includere del sale segreto, dovresti leggere ciò che viene comunemente chiamato a pepper , che aggiunge una chiave segreta per l'intera applicazione alle tue password salate. Questo potrebbe proteggerti da violazioni parziali (come il compromesso del database attraverso, ad esempio, l'iniezione SQL), ma non aiuterà in caso di violazioni complete del sistema, a meno che non si utilizzi un modulo Hardware Security (HSM) ) per proteggere il valore del pepe.

    
risposta data 25.07.2016 - 09:43
fonte
3

Quando un utente malintenzionato conosce solo l'hash e non il sale, non deve solo testare tutte le password possibili, ma ogni possibile password con ogni possibile sale. Con valori di sale lunghi e casuali questo è praticamente impossibile.

Tuttavia, questo non è uno scenario realistico. Quando un utente malintenzionato compromette un sistema, è necessario presumere che abbiano compromesso il database sia degli hash che dei sali. Separare questi due set di dati in qualche modo è impossibile perché sono sempre usati insieme.

    
risposta data 25.07.2016 - 13:49
fonte

Leggi altre domande sui tag