generate salt encrypt it with AES using user's password as key save
the encrypted salt and hash
Potresti farlo e sarebbe un sale efficace, ma in realtà non sarebbe più sicuro di un normale sale.
Consideriamo due vettori di attacco:
Collisioni con password
Ovviamente non vogliamo che due utenti con la stessa password abbiano la stessa password con hash. Per evitare ciò usiamo un salt casuale e assumiamo che la probabilità di due utenti con la stessa password e lo stesso sale generato in modo casuale sia effettivamente 0.
Tuttavia, se due utenti hanno la stessa password e coincidono con lo stesso sale, avranno lo stesso hash indipendentemente dal fatto che il sale sia crittografato con la loro password o non sia affatto crittografato. Pertanto, crittografando il sale non lo renderai meno probabile che si verifichi una collisione nel sale . Gli unici fattori che lo rendono meno probabile sono la qualità dei valori casuali usati per il sale e il numero di bit.
Attacchi a forza bruta
Se un utente malintenzionato sta tentando un attacco di forza bruta e hai crittografato il sale, l'unico passaggio in più che devono eseguire è decrittografare il sale memorizzato ogni iterazione e utilizzarlo per produrre l'hash che hanno poi confrontato con la password hash per vedere se hanno una corrispondenza.
Ciò richiede uno sforzo leggermente maggiore per un utente malintenzionato, ma quando si tratta di crittografia, fare qualcosa durare solo due o tre volte di più non è significativo. Se la forzatura bruta di una password richiede 3 giorni invece di 2, non l'hai resa materialmente più sicura. Se stai cercando di creare qualcosa di sicuro, è necessario che impieghi 5000 anni invece di 2 giorni.
Se vuoi rallentare gli attacchi di forza bruta ti conviene ripetere il processo di hashing decine di migliaia di volte o usare una funzione di hash che è specificatamente progettata per essere computazionalmente lenta.