Protezione delle password utilizzando la lunghezza dell'Hash breve

1

Qualcuno usa deliberatamente hash lunghezze brevi per le password per aumentare la possibilità di collisioni false positive nel caso di un attacco di forza bruta sul database?

Quando ho provato a decidere su una lunghezza hash, la mia ipotesi di default era "lo storage è economico, lo rende enorme". Tuttavia, in realtà poiché la debolezza di una password è spesso che è breve o facilmente ipotizzabile, nessuna quantità di hash length potrebbe aiutare gli utenti nel caso di una violazione del database.

Questo mi ha fatto pensare, qualcuno usa deliberatamente degli hash brevi per oscurare meglio la password originale? Se ci sono solo, diciamo, un milione di possibili hash, avrai delle collisioni dappertutto. Quando l'applicazione è in esecuzione normalmente, non consentirà a un utente malintenzionato di provare più di una manciata di volte, riducendo la possibilità di una congettura fortunata quasi a 0. Se il database viene compromesso, un utente malintenzionato sta per forzare e trovare il bruto tutte le password facili, non importa quale sia il tuo schema di hashing. Tuttavia, se la probabilità di collisioni è elevata, è probabile che una forza bruta trovi una corrispondenza password che l'utente non riutilizzerà in nessun altro posto.

Suppongo che avresti bisogno di scegliere una lunghezza che protegga sufficientemente l'input casuale dalla collisione in una manciata di tentativi, pur avendo una probabilità relativamente alta di avere più parole del dizionario che corrispondono. E forse quell'equilibrio non esiste.

Quindi la mia domanda è: qualcuno lo fa? C'è un nome per questo?

    
posta Vectorjohn 01.11.2017 - 00:00
fonte

2 risposte

4

Non sono a conoscenza di nessuno che lo faccia, attualmente o storicamente.

Vedo ciò che si ottiene - resistenza alla scoperta delle password - ma aumentare la probabilità di collisione come mezzo per attenuare gli attacchi offline è di dubbia utilità. Qualsiasi potenziale vantaggio derivante da ciò è superato dagli svantaggi:

  • Se un utente specifico è mirato, a meno che non ci siano molte collisioni, sarebbe facile per l'attaccante provare tutte le collisioni contro un altro sito o perdite fino a quando non hanno ottenuto una corrispondenza ... che confermerebbe il vero password e cancella qualsiasi beneficio dalle collisioni.

  • Man mano che il numero di collisioni aumenta, aumenta il rischio di un falso positivo online per l'autenticazione (con il sito originale).

  • Ciò significa anche che l'affidabilità / non ripudio dell'autenticazione è ridotta. Qualcun altro tranne l'utente potrebbe (teoricamente) accedere come utente, senza la password effettiva dell'utente. Di solito, il rischio di questo è effettivamente pari a zero nel mondo reale quando si utilizza una funzione hash sufficientemente resistente alle collisioni. Tuttavia, deliberatamente alla ricerca di collisioni, si potrebbe sostenere che non stai seguendo le migliori pratiche che assicurano la non recidiva nella pratica.

Invece, puoi ottenere molti dei benefici che stai cercando semplicemente memorizzando materiale extra privato (una chiave di crittografia o un pepe) in un HSM . Se implementato correttamente, questo ti porterà una certa resistenza all'attacco offline, senza gli svantaggi delle frequenti collisioni.

    
risposta data 01.11.2017 - 04:08
fonte
0

L'unico vantaggio di tale schema è che se il tuo database è compromesso, è improbabile che tu possa compromettere l'account dell'utente su qualche altro sito, non il tuo, perché è probabile che l'altro sito sia usa un diverso algoritmo di hash (e un diverso salt) in modo che sia effettivamente necessaria la password originale, non qualche collisione di hash.

D'altra parte, se ottengono una collisione con l'hash della password, quindi per il tuo sito non importa se non è la password originale, possono usare quella password per accedere al tuo posto. Quindi qualcuno con una password originale casuale lunga potrebbe essere compromesso da una collisione con una password comune corta. Questo è male.

Fondamentalmente stai dando un dubbio beneficio ad altri siti a spese della tua sicurezza. Sembra molto fuorviante quindi dubito molto che qualcuno lo stia facendo.

    
risposta data 01.11.2017 - 15:04
fonte