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?