Supponiamo di avere password statisticamente lunghe 7-8 caratteri. L'aggiunta di un carattere lungo di 200 caratteri è meno sicuro di un valore di 5 caratteri, a causa degli analoghi input della funzione hash?
Mi stavo chiedendo: cosa succede se qualcuno cerca di indovinare il sale forzando il sale con la password "123456", o un'altra password popolare che può essere trovata nel sistema o anche su una password conosciuta dal proprio hacker account?
Come Mike e Gumbo hanno menzionato nei commenti, un salt non ha lo scopo di aggiungere protezione alle password sbagliate. Ha lo scopo di impedire agli aggressori di rompere l'intero database in una sola volta. La lunghezza del sale non ha lo scopo di aggiungere difficoltà a rompere le password memorizzate. Ha lo scopo di garantire che il tuo sale sia ragionevolmente unico rispetto ad altri su Internet e (se lo stai facendo bene) nessun altro utente avrà lo stesso sale.
Immagina di avere 20 utenti che hanno tutti "dio" come password. Considera i seguenti scenari:
Le password non sono corrette
L'utente malintenzionato può utilizzare una tabella precalcata per interrompere la password di un utente nell'ordine breve molto . Inoltre, una volta che ha il primo dei 20, avrà anche gli altri 19 poiché i loro hash sarebbero identici.
Le password sono salate. Il sale usato è piuttosto corto. Lo stesso sale è usato per tutti gli utenti.
L'autore dell'attacco potrebbe dover cercare un po ', ma potrebbe eventualmente imbattersi in una tabella precompuita creata appositamente per la configurazione. Dopo questo punto, vedi lo scenario 1.
Le password sono salate. Il sale usato è ragionevolmente strong. Lo stesso sale è usato per tutti gli utenti.
È probabile che l'utente malintenzionato non trovi una tabella pre-calcolata per il tuo sistema su Internet. Dovrà fare uno dei suoi. Questo richiederà un po 'di tempo extra. Tuttavia, una volta terminato, torniamo allo scenario 1.
Quindi, usa i sali lunghi e rendili unici per utente. Ma non contate su quello per aiutare i singoli utenti molto se usano "dio" come loro password.
Un sale troppo lungo non ridurrà la sicurezza. Un sale troppo breve ridurrà la sicurezza.
Man mano che il sale aumenta la sicurezza migliorerà. Ad un certo punto attraverserai un confine, dove inizierai a ottenere rendimenti decrescenti all'aumentare della lunghezza del sale. E alla fine attraverserai un altro confine, dove un sale più lungo non aggiunge alcuna sicurezza.
Tuttavia, poiché un sale più lungo non ha costi significativi, vi sono pochi motivi per smettere di aumentare la lunghezza fino a raggiungere il secondo limite. Anche se dovessi aumentare la lunghezza del sale oltre a questo, l'unico inconveniente è il minor costo aggiuntivo in termini di tempo di archiviazione e di elaborazione.
Purtroppo i sali vengono generati più spesso con una lunghezza inferiore alla più bassa delle due soglie.
Quindi quali sono le due soglie?
La soglia inferiore è determinata dal numero di utenti e dallo scopo del sale, che deve essere diverso per ogni password scelta da qualsiasi utente. Se prendiamo alcune stime prudenti, il numero di utenti in tutto il mondo è inferiore a 10 ^ 10 e ogni utente ha password per meno di 10 ^ 2 sistemi e durante la loro vita cambia questa password meno di 10 ^ 3 volte. Ciò significa che in totale ci saranno meno di 10 ^ 15 password. Detto questo, si potrebbe erroneamente concludere che 50 bit di entropia nel sale sono sufficienti a garantire che non ci saranno mai due sali che si ripetono, ma a causa del paradosso del compleanno dobbiamo raddoppiare quel numero.
Quindi una volta che il sale cresce più a lungo di 100 bit, iniziamo a vedere rendimenti decrescenti in termini di maggiore sicurezza. La soglia dei 100 bit ha comportato molte supposizioni. La prossima soglia implica molto meno indovinare. Più di 100 bit di entropia nel sale migliorano ancora la sicurezza, ma non di molto.
Una volta che il sale cresce per essere più lungo dell'output della funzione hash sottostante, non vi è tuttavia alcuna sicurezza aggiuntiva nel renderlo più lungo. Ciò che la soglia dipende dalla funzione di hash, questi vanno da 128 a 512 bit per gli hash tipici.
Ricorda che i sali sono generalmente generati con 6 bit di entropia per carattere, quindi avrai bisogno di 86 caratteri di sale per raggiungere i 512 bit di entropia.
L'unica proprietà di un sale che è importante dal punto di vista della sicurezza è che è globalmente unico . La lunghezza può influire su quanto sia unico il sale, ma è irrilevante da qualsiasi altra prospettiva. Supponendo che abbia un effetto positivo o negativo su qualsiasi cosa è chiedere a Salt di eseguire una funzione che non è stata pensata per servire.
Quindi, un sale dovrebbe essere abbastanza lungo da assicurare ragionevolmente l'unicità, e questo è tutto. Supponendo che il sale abbia una buona unicità, non influirà più sulla sicurezza in modo positivo o negativo, ma sicuramente sprecherà spazio di archiviazione.
Altri hanno commentato l'uso corretto di sali e password ma forse è utile aggiungere una parola sulle funzioni di hash perché la tua domanda sembra suggerire un'intuizione alquanto errata del loro modo di lavorare.
In base alla progettazione, una buona funzione di hash crittografica non dovrebbe farti intuire quanto simili gli input fossero basati sui valori dell'hashed stessi. Altrimenti, potrebbe essere invertito riducendo gradualmente questa distanza che sarebbe molto meno costosa di una pura ipotesi di forza bruta. Quindi hash (salt1 + "12345") non dovrebbe essere più simile a hash (salt1 + "67890") o a hash ("12345") che a hash (salt2 + "67890").
L'intero punto di sale è assicurarsi che gli input (e quindi l'hash) non siano identici anche se due account utilizzano la stessa password ma similarità non dovrebbe essere un problema.
La lunghezza di un sale segue la legge dei rendimenti decrescenti.
In nessun punto un sale diventa less sicuro essendo più lungo,
ma smette di ottenere in modo significativo più in modo relativamente rapido.
Non si "incrina" mai un sale: ciò che si sta spezzando è la password con hash, a cui viene aggiunto il sale. Il sale affronta solo la minaccia delle tabelle arcobaleno - la possibilità di trovare tabelle di hash precalcolate che consentono di saltare il laborioso processo di forzatura bruta.
Per questo scopo, tutto ciò di cui hai bisogno sono i sali abbastanza a lungo che nessuno avrà già creato tabelle arcobaleno complete per tutti i possibili sali. E a causa del costo della creazione di una tavola arcobaleno e della crescita esponenziale del numero di sali che dovresti calcolare mentre aumenti la lunghezza massima del sale, questo non è un requisito molto difficile: solo pochi caratteri di sale saranno già è altamente probabile che nessuno abbia calcolato tabelle arcobaleno complete su sali del tuo formato.
Per scegliere un valore casuale dal nulla, i sali di, diciamo, 16 caratteri esadecimali o più saranno abbastanza buoni, assumendo che il tuo metodo per selezionarli casualmente non abbia difetti sfruttabili.
Oltre a ciò, l'aumento della sicurezza diventa sempre più trascurabile.
Leggi altre domande sui tag passwords password-policy hash salt