Memorizzazione di più hash per prevenire collisioni, rischi per la sicurezza?

In breve: meglio non farlo. Una soluzione migliore sarebbe utilizzare qualcosa come BCrypt . Puoi utilizzare un numero maggiore di round per garantire che l'attacco che sia computazionalmente non fattibile.

Per quanto riguarda la sicurezza aggiunta o ridotta: dipende dal fatto che gli hash perdano. In entrambi i casi la differenza di sicurezza non è così grande, quindi tutto ciò che sta accadendo è che stai bruciando cicli di CPU che potrebbero essere stati usati per bcrypt.

Se gli hash non sono trapelati all'attaccante, allora il tuo sistema è trascurabilmente più sicuro, perché anche se per caso una collisione hash è stata trovata, è improbabile al limite che la collisione si estenderebbe agli hash alternativi. Quindi questa soluzione difende dalle collisioni. Ma dal momento che la possibilità di una collisione è molto piccola in primo luogo, rendendola ancora più piccola ha un rapporto vantaggi-costi-costi praticamente nulla.

Se l'hash fa perde all'attaccante, allora ha ancora molti altri hash da attaccare. Il sistema diventa proporzionalmente meno sicuro, se scoprire la fonte di un hash variante fornisce suggerimenti su quale potrebbe essere la password reale . Per questo motivo, la variante hash dovrebbe essere sé un hash (e nel caso, un hash binario e ottenuto da un algoritmo diverso). Quindi l'attaccante non ha modo di sapere cosa ha trovato. La sicurezza del sistema rimane la stessa e abbiamo appena bruciato alcuni cicli della CPU.

UPDATE: let's assume the hashing algorithm used is something ridiculous (and fast) like MD5, and that the attacker has gained access to the database > through whatever means.

Ok, in questo caso il nostro ipotetico attaccante può provare a montare un attacco preimage o un attacco di collisione, oppure potrebbe semplicemente google tutti loro. E trova, per esempio, f7eedbcbee1453935bc9b36870810f58 su Google.

La probabilità di trovare un hash su Google è approssimativa (dal momento che abbiamo a che fare con modifiche banali, ma comunque modificate) proporzionali al numero di hash da attaccare.

Garantito, f7eedbcbee1453935bc9b36870810f58 è non l'hash della password "reale". Tuttavia, a quel punto la password real (per la quale ha un hash per confermare che è stata effettivamente trovata) è a pochi millesimi di secondo.

Salatura e / o manipolazione degli hash cambia poco. Quello che fa è aumentare la X-fold della sicurezza. Ma avere quattro hash invece di uno è ancora approssimativamente, diciamo, fino a quattro volte meno sicuro. Salatura fa sì che invece di avere un quarto di un piccolo numero, hai un quarto di un enorme numero. Usando hash extra no , aumenteresti comunque la sicurezza generale.

Questa non è una buona idea.

La prima ragione è che le collisioni non sono un problema . Per l'hashing delle password, non si fa affidamento sulla resistenza alle collisioni, ma sulla resistenza alle pre-immagini . Non c'è bisogno di una funzione di hashing della password per ammettere collisioni facili da costruire, ma se lo fa, anche questo non è un problema. Ad esempio, le collisioni possono essere costruite con PBKDF2. E non ci importa.

La seconda ragione è che l'autore dell'attacco intenzionato a trovare una password che corrisponda a un determinato hash non ha bisogno di calcolare diversi hash. L'utente malintenzionato tenta un lungo elenco di potenziali password, ma tale elenco è molto più piccolo dell'intervallo di output della funzione hash. La conseguenza è che quando l'utente malintenzionato trova una password corrispondente, è la password - e questo è vero anche quando l'attaccante lavora su una singola funzione hash. Pertanto, anche se tu spendi la CPU per calcolare diversi hash, l'attacker è perfettamente contento di lavorare con uno solo. In altre parole, i numerosi hash sprecano la CPU . Questo è importante perché normalmente si desidera utilizzare un hash lento (con un numero configurabile di iterazioni) in modo che gli attacchi vengano rallentati. Facendo il lavoro più volte, ti costringi ad abbassare il conteggio delle iterazioni, dando così automaticamente un vantaggio all'attaccante.

La terza ragione è una generalizzazione della precedente: l'hacker deve solo lavorare su un valore hash. Se fornisci diversi , allora questo può solo aiutare l'attaccante: sceglierà quello che rende le cose più facili per lui.

Riepilogo: l'idea di "molti hash" non risolve un problema reale, ma può aiutare l'autore dell'attacco. Quindi non farlo. Come spiega @Iserni, usa bcrypt. Per un trattamento più dettagliato su come dovrebbe essere fatto l'hashing della password, leggi questo .