La necessità di nascondere il sale per un hash

StackOverflow https://stackoverflow.com/questions/213380

Domanda

Al lavoro abbiamo due teorie in competizione per i sali. I prodotti su cui lavoro usano qualcosa come un nome utente o un numero di telefono per salare l'hash. Essenzialmente qualcosa di diverso per ogni utente ma che è prontamente disponibile per noi. L'altro prodotto genera casualmente un salt per ogni utente e cambia ogni volta che l'utente cambia la password. Il salt viene quindi crittografato nel database.

La mia domanda è se il secondo approccio è davvero necessario? Posso capire da una prospettiva puramente teorica che è più sicuro del primo approccio, ma che dire dal punto di vista della praticità. In questo momento per autenticare un utente, il salt deve essere non crittografato e applicato alle informazioni di accesso.

Dopo averci pensato, non vedo un vero guadagno di sicurezza da questo approccio. Cambiare il sale da un account all'altro, rende ancora estremamente difficile per qualcuno tentare di forzare l'algoritmo di hashing anche se l'attaccante era a conoscenza di come determinare rapidamente quale fosse per ciascun account. Questo presuppone che le password siano sufficientemente forti. (Ovviamente trovare l'hash corretto per un set di password in cui sono tutte e due le cifre è significativamente più facile che trovare l'hash corretto delle password che sono 8 cifre). Sono errato nella mia logica o c'è qualcosa che mi manca?

MODIFICA: Ok, quindi ecco il motivo per cui penso che sia davvero discutibile crittografare il sale. (fammi sapere se sono sulla strada giusta).

Per la seguente spiegazione, supponiamo che le password siano sempre 8 caratteri e che il sale sia 5 e che tutte le password siano composte da lettere minuscole (semplifica la matematica).

Avere un sale diverso per ogni voce significa che non posso usare la stessa tabella arcobaleno (in realtà tecnicamente potrei se ne avessi una di dimensioni sufficienti, ma per il momento ignoriamola). Questa è la vera chiave del sale da quello che ho capito, perché per decifrare ogni account devo reinventare la ruota per così dire per ognuno. Ora, se so come applicare il salt corretto a una password per generare l'hash, lo farei perché un salt estende la lunghezza / complessità della frase con hash. Quindi taglierei il numero di possibili combinazioni che avrei bisogno di generare per "conoscere" Ho la password + sale da 13 ^ 26 a 8 ^ 26 perché so qual è il sale. Ora è più facile, ma è ancora molto difficile.

Quindi sulla crittografia del sale. Se so che il salt è crittografato, non proverei a decifrarlo (supponendo che sappia che ha un livello sufficiente di crittografia) prima. Lo ignorerei. Invece di provare a capire come decrittografarlo, tornando all'esempio precedente, genererei solo una tabella arcobaleno più grande contenente tutte le chiavi per il 13 ^ 26. Non sapere che il sale mi rallenterebbe sicuramente, ma non penso che aggiungerebbe il compito monumentale di provare a decifrare prima la crittografia del sale. Ecco perché non credo ne valga la pena. Pensieri?

Ecco un link che descrive per quanto tempo le password rimarranno sotto l'attacco di una forza bruta: http://www.lockdown.co.uk/?pg=combi

È stato utile?

Soluzione

La risposta qui è chiederti da cosa stai davvero cercando di proteggere? Se qualcuno ha accesso al tuo database, allora hanno accesso ai sali crittografati e probabilmente hanno anche accesso al tuo codice. Con tutto ciò che potrebbero decifrare i sali crittografati? In tal caso, la crittografia è praticamente inutile comunque. Il sale è davvero lì per farlo, quindi non è possibile formare una tabella arcobaleno per rompere l'intero database delle password in una volta sola se viene rotto. Da quel punto di vista, fintanto che ogni sale è unico, non vi è alcuna differenza, sarebbe richiesto un attacco di forza bruta con i tuoi sali o i sali crittografati per ogni password singolarmente.

Altri suggerimenti

Non è necessario nascondere un sale.

Un sale diverso dovrebbe essere usato per ogni hash. In pratica, questo è facile da ottenere ottenendo 8 o più byte dal generatore di numeri casuali di qualità crittografica.

Da una una mia precedente risposta :

  

Salt aiuta a contrastare gli attacchi con dizionario precalcolato.

     

Supponiamo che un utente malintenzionato abbia un elenco di password probabili. Può hash ciascuno   e confrontalo con l'hash della password della sua vittima, e vedi se   le partite. Se l'elenco è grande, ciò potrebbe richiedere molto tempo. Lui no   vuole passare molto tempo sul suo prossimo obiettivo, quindi registra il risultato   in un "dizionario" " dove un hash punta al suo input corrispondente. Se   l'elenco delle password è molto, molto lungo, può usare tecniche come una   Rainbow Tavolo per risparmiare spazio.

     

Tuttavia, supponiamo che il suo prossimo obiettivo abbia salato la loro password. Anche se il   l'attaccante sa qual è il sale, la sua tabella precompilata è   senza valore: il salt cambia l'hash risultante da ogni password. lui   deve ricodificare tutte le password della sua lista, apponendo quelle del bersaglio   sale all'ingresso. Ogni sale diverso richiede un diverso   dizionario e, se vengono utilizzati abbastanza sali, l'attaccante non avrà spazio   per memorizzare dizionari per tutti. Lo spazio di trading per risparmiare tempo è no   più un'opzione; l'attaccante deve ricorrere all'hash di ogni password   nella sua lista per ogni bersaglio che vuole attaccare.

     

Quindi, non è necessario mantenere segreto il sale. Garantire che il   attaccante non ha un dizionario pre-calcolato corrispondente a quello   il sale particolare è sufficiente.

Dopo averci pensato un po 'di più, mi sono reso conto che ingannarti nel pensare che il sale potesse essere nascosto è pericoloso. È molto meglio supporre che il sale non possa essere nascosto e progettare il sistema in modo sicuro nonostante ciò. Fornisco una spiegazione più dettagliata in un altro risposta.

La mia comprensione di " salt " è che rende più difficile il cracking, ma non cerca di nascondere i dati extra. Se stai cercando di ottenere una maggiore sicurezza rendendo il sale "segreto", allora vuoi davvero solo più bit nelle tue chiavi di crittografia.

Il secondo approccio è solo leggermente più sicuro. I sali proteggono gli utenti dagli attacchi del dizionario e dagli attacchi della tabella arcobaleno. Rendono più difficile per un attaccante ambizioso compromettere l'intero sistema, ma sono ancora vulnerabili agli attacchi focalizzati su un utente del sistema. Se utilizzi informazioni pubblicamente disponibili, come un numero di telefono, e l'attaccante ne viene a conoscenza , allora hai salvato loro un passaggio nel loro attacco. Naturalmente la domanda è controversa se l'attaccante ottiene l'intero database, i sali e tutto il resto.

MODIFICA: Dopo aver riletto questa risposta e alcuni dei commenti, mi viene in mente che parte della confusione potrebbe essere dovuta al fatto che sto solo confrontando i due molto specifici casi presentati nella domanda: sale casuale vs sale non casuale. La domanda di usare un numero di telefono come salt è controversa se l'attaccante ottiene l'intero database, non la questione dell'uso di un salt.

Un sale nascosto non è più sale. È pepe Ha il suo uso. È diverso dal sale.

Pepper è una chiave segreta aggiunta alla password + salt che trasforma l'hash in un HMAC (Hash Based Message Authentication Code). Un hacker con accesso all'output dell'hash e al salt può teoricamente forzare la forza a indovinare un input che genererà l'hash (e quindi passerà la validazione nella casella di testo della password). Aggiungendo pepe si aumenta lo spazio problematico in modo crittografico casuale, rendendo il problema intrattabile senza hardware serio.

Per ulteriori informazioni su pepper, controlla qui .

Vedi anche hmac .

Ecco un semplice esempio che mostra perché è male avere lo stesso sale per ogni hash

Considera la seguente tabella 

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)

Caso 1 quando sale 1 è uguale a salt2 Se Hash2 viene sostituito con Hash1, l'utente 2 potrebbe accedere con la password utente 1

Caso 2 quando il sale 1 non è lo stesso sale2 Se Hash2 viene sostituito con Hash1, l'utente2 non può accedere con la password dell'utente 1.

  

... qualcosa come un nome utente o un numero di telefono per salare l'hash. ...

     

La mia domanda è se il secondo approccio è davvero necessario? Posso capire da una prospettiva puramente teorica che è più sicuro del primo approccio, ma che dire dal punto di vista della praticità?

Da un punto di vista pratico, un sale è un dettaglio di implementazione. Se cambi mai il modo in cui le informazioni utente vengono raccolte o gestite & # 8211; e sia i nomi utente che i numeri di telefono a volte cambiano, per usare i tuoi esempi esatti & # 8211; allora potresti aver compromesso la tua sicurezza. Vuoi che un cambiamento così rivolto verso l'esterno abbia problemi di sicurezza molto più profondi?

L'arresto del requisito secondo cui ogni account ha un numero di telefono deve comportare una revisione completa della sicurezza per assicurarsi di non aver aperto tali account a un compromesso sulla sicurezza?

Esistono due tecniche, con obiettivi diversi:

  • Il "sale" viene utilizzato per crittografare in modo diverso due password altrimenti uguali. In questo modo, un intruso non può utilizzare efficacemente un attacco di dizionario contro un intero elenco di password crittografate.

  • Il (condiviso) "segreto" viene aggiunto prima di eseguire l'hashing di un messaggio, in modo che un intruso non possa creare i propri messaggi e farli accettare.

Tendo a nascondere il sale. Uso 10 bit di sale anteponendo un numero casuale da 1 a 1024 all'inizio della password prima di eseguire l'hashing. Nel confrontare la password immessa dall'utente con l'hash, eseguo il ciclo da 1 a 1024 e provo ogni possibile valore di salt fino a quando non trovo la corrispondenza. Questo richiede meno di 1/10 di secondo. Ho avuto l'idea di farlo in questo modo dal PHP password_hash e password_verify . Nel mio esempio, il "costo" è 10 per 10 bit di sale. O da ciò che un altro utente ha detto, nascosto "sale" si chiama "pepe". Il salt non è crittografato nel database. È brutale costretto a uscire. Renderebbe necessario il tavolo arcobaleno per invertire l'hash 1000 volte più grande. Uso sha256 perché è veloce, ma comunque considerato sicuro.

In realtà, dipende da quale tipo di attacco stai cercando di proteggere i tuoi dati.

Lo scopo di un unico salt per ogni password è prevenire un attacco del dizionario contro l'intero database delle password.

Crittografare il salt unico per ogni password renderebbe più difficile decifrare una singola password, sì, ma devi valutare se c'è davvero un grande vantaggio. Se l'attaccante, con la forza bruta, trova questa stringa: 

Marianne2ae85fb5d

hash su un hash memorizzato nel DB, è davvero così difficile capire quale parte è il passaggio e quale parte è il sale?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top