Doppia sicurezza di hashing

Question

La mia prima domanda è: ho sentito che l'hash della stringa 2 volte (ad esempio sha1 (sha1 (password))), perché il secondo hash ha una lunghezza fissa, è vero ??

La mia seconda domanda è, che è più sicura? (var1 e var2 sono 2 stringhe):

1. sha1 (var1 + sha1 (var2))
2. sha1 (var1 + var2)

Se è il primo, vale il costo delle prestazioni?

Answer 1

Eseguendo l'hashing della stringa due volte, si aumenta il rischio di collisioni, il che è negativo per la sicurezza.

Invece di avere una quantità infinita di input che portano a 2 ¹²⁸ possibili output, avrai 2 ¹²⁸ possibili input che portano forse a meno di 2 ¹²⁸ output.

L'uso di sale e pepe prima dell'hashing mantiene almeno l'input a infinite possibilità. L'hashing due volte aumenta il tempo di esecuzione del tuo script e aumenta il rischio di collisioni, a meno che tu non mantenga la fonte di input infinito.

Answer 2

• sha1 (var1 + sha1 (var2))
• sha1 (var1 + var2)

Nessuno dei due è molto sicuro. Non reinventare la ruota. HMAC è stato progettato per questo; in particolare, sono necessarie misure (riempimento, ecc.) per evitare problemi con alcuni punti deboli in alcuni algoritmi di hash che interagiscono male con le implementazioni "semplici" di cui sopra.

Inoltre, il doppio hash non è utile per migliorare la sicurezza. Considera: nella migliore delle ipotesi, eseguirai il mapping da un valore ish casuale a un altro valore ish casuale. Tuttavia, se c'è una collisione due valori risultanti dal secondo hash sono uguali, hai perso la sicurezza finendo con una collisione. Cioè, non puoi mai sbarazzarti di una collisione in questo modo, ma puoi ottenerne uno.

Detto questo, gli attacchi preimage esistenti potrebbero non funzionare contro il doppio hashing ... ma! Potrebbero ancora funzionare. Non sono qualificato per dire quale, e se lo stai chiedendo qui, probabilmente non lo sei nemmeno. Certamente gli attacchi di collisione, che sono tutti pratici con MD5 oggi, non sono ostacolati dal doppio hashing.

È meglio attenersi agli algoritmi comprovati che hanno resistito a decenni di analisi, perché con la crittografia è fin troppo facile rendere qualcosa che sembra sicuro ma non lo è.

Answer 3

Dubito che ciò aggiungerebbe sicurezza. Aumenterebbe il tempo di esecuzione dello script, ma non aggiungerebbe molta sicurezza all'hash. Ricorda che quando qualcuno tenta di rompere il tuo hash, non ha bisogno di trovare il valore esatto di var1 e var2, deve solo trovarne uno che risulti nello stesso hash.

Answer 4

Non sono un esperto di crittografia, ma per quanto ne so non otterrete alcuna sicurezza dall'hashing di un valore più volte oltre a rallentare il processo. Quindi, se esegui l'hash 1000 volte, eseguirai un attacco (ad esempio un attacco del dizionario) 1000 volte più lento, ma questo è abbastanza irrilevante nel caso dell'hashing una o due volte.

Answer 5

L'uso di solo uno e nessun sale consente di risolverlo facilmente.

Esistono molte tabelle di grandi dimensioni che contengono tonnellate di questi hash, quindi un singolo hash senza sale può essere risolto praticamente in nulla.

L'aggiunta di un secondo hash non sarà di grande aiuto, perché ancora una volta queste tabelle esistono già con i valori salvati.

Un salt dinamico che viene aggiunto alla password aiuterà molto più degli hash multipli. Gli hash multipli non aggiungono molto ad esso.

Answer 6

La mia sensazione è che stai costruendo un muro di mattoni con una porta d'acciaio, ma gli altri muri sono fatti di compensato. In altre parole, puoi inserire tutta la sicurezza che vuoi nelle password di hashing, ma ci saranno comunque modi molto più semplici per craccare il tuo sistema. Penso che sia molto meglio adottare un approccio ampio alla sicurezza invece di preoccuparsi troppo di cose come questa.

Answer 7

var1 + var2 sarà lo stesso in una situazione prevista? Voglio dire, la prima proposta dovrebbe essere ok in quel caso, perché eviteresti lo scontro di hashing. A proposito di valere il costo, è una domanda a cui dovresti rispondere. Evitare una collisione vale il costo.

Per quanto riguarda l'algoritmo sha, dovrebbe davvero mescolare i risultati. Quindi applicarlo molte volte non dovrebbe avere risultati migliori, né applicarlo a un "più casuale" l'input dovrebbe dare risultati migliori.

Answer 8

L'hash di una stringa più volte complica il compito dell'attaccante in caso di attacco del dizionario, rendendolo "molto più lungo" a forza bruta. La tua prima domanda non è chiara, ma più hash non sono meno sicuri perché il secondo hash ha una lunghezza fissa.

Ma più importante di un hash multiplo, l'uso di un salt è essenziale per una migliore sicurezza.

Per quanto riguarda la tua seconda domanda, direi che non è molto semplice dire quale dei 2 è il più sicuro, penso che andare con l'opzione 2 sia davvero abbastanza.