Le password di ri-salatura regolarmente inseriscono / diminuiscono la sicurezza?

Le collisioni della funzione hash non sono rilevanti per l'hashing della password. Tutti gli hashing delle password funzionano sulla resistenza di preimage, non sulle collisioni. Puoi dimenticare tutto ciò che riguarda le collisioni quando parli di hashing della password.

Salt "collisioni" possono avere importanza ma sono meglio chiamate "riutilizzo del sale". Si evita il riutilizzo del sale utilizzando sali casuali di dimensioni sufficienti (bastano 16 byte; GUID sono buoni sali).

Non puoi cambiare il sale senza avere accesso alla password. Se potessi farlo, allora l'attaccante potrebbe farlo anche tu e annullare i benefici dei sali. Questa sarebbe una grave debolezza della funzione di hashing.

Non ha senso cambiare il sale. Il valore aggiunto salt unico è il modo in cui è diverso dagli altri valori di sale. Non c'è alcun guadagno nel sostituire un valore di sale con un altro valore; può esserci una perdita netta se il nuovo valore è uguale ad un altro valore salino, che porta al riutilizzo del sale.

Vale a dire, quando usi sali casuali, stai assicurando l'assenza di sale in modo euristico: se mai generi s sali, in uno spazio di dimensioni n (ad esempio < em> n = 2 ¹²⁸ per i sali a 16 byte casuali), quindi il rischio di un riutilizzo di sale rimane basso finché s ² è piccolo per quanto riguarda n . Fondamentalmente, con i sali da 16 byte, scelti casualmente da un buon PRNG , hai spazio per circa 2 ⁶⁴ istanze di generazione di sale. Se cambi i sali regolarmente, più spesso di quanto strettamente richiesto, allora stai aumentando s , cioè diminuendo il tuo respiro. Fortunatamente, 2 ⁶⁴ è un numero enorme, quindi supponendo che tu faccia tutto il resto correttamente, quindi sostituisci i sali ogni settimana (quando l'utente accede, perché non puoi farlo senza la password stessa) non implicano un rischio aggiuntivo significativo. Sarà inutile, ma innocuo.

Se, da più valori hash con vari sali e la stessa password, l'utente malintenzionato può elaborare la password stessa o ridurne lo spazio chiave (con maggiore successo rispetto al semplice rischio di riutilizzo del sale spiegato sopra), quindi questa è una crittografia debolezza della funzione di hashing della password. Nessuna debolezza di questo tipo è nota per le normali funzioni di hashing della password (bcrypt, PBKDF2 ...).

Come sottolineato da Tom Leek in precedenza, non c'è motivo di resalting se si utilizza un hash salato "semplice".
Cosa che non dovresti fare, dato che le piattaforme con una dozzina circa di GPU possono potenziare la forza tra decine e centinaia di miliardi [1] di hash al secondo al giorno d'oggi, e non puoi aspettarti che una password utente abbia molto più di 30-40 bit di entropia (se sei davvero fortunato ). 40 bit è 10,9 secondi a 100 G / s.

Tuttavia, puoi effettivamente aumentare la sicurezza "resalting", se (si spera) usi uno schema di derivazione / allungamento a chiave lenta come scrypt o PBKDF2 piuttosto che un semplice hash salato.

Invece di (per esempio)% iterazioni% co_de, dovresti fare 1,000 iterazioni e incrementare 1,000+N dopo un accesso riuscito, con un limite di frequenza (diciamo, una volta al giorno al massimo).
In questo modo, devi tenere traccia di un valore aggiuntivo ( N ) per utente, ma puoi aggiornare ("resalt") la password con hash per quasi gratis, usando una singola iterazione aggiuntiva, e senza dover conoscere la password originale !
Nota che il sale non è tecnicamente cambiato (anche se potresti se lo volevi, ad esempio se aggiungi N al sale) ma è lo stesso risultato netto di un sale diverso, poiché il numero di le iterazioni sono diverse.

Sarebbe possibile incrementare N del numero di giorni dall'ultimo accesso, anche (se ne tenete traccia), quindi gli utenti che accedono solo una volta alla settimana o una volta ogni due settimane avranno in media lo stesso margine di sicurezza.

Lo sforzo computazionale della funzione di derivazione della chiave si adatta quindi nel tempo, tenendo conto che l'hardware di cracking più veloce diventa più economico nel tempo. % iterazioni% co_de diventano iterazioni N dopo due anni. Il costo dell'aggiornamento di tutti gli hash nel database viene ammortizzato tramite accessi ed è molto basso (praticamente zero).