A CURA:
La mia prima risposta istintiva è stata NON UTILIZZARE MAI LA PASSWORD COME VALORE SALE. E questo è ancora più o meno dove mi trovo.
Tuttavia; leggendo il tuo post un po 'più attentamente, no il sale non è memorizzato nel risultato dall'algoritmo pbkdf2.
Tuttavia; lo scopo del sale è che aggiunge entropia (casualità) ai dati di input prima dell'hashing.
Salt non è destinato a essere "segreto".
Il primo problema lampante che vedo è l'uso del nome utente come valore salt nella prima chiamata a pbkdf2. Questo è assolutamente prevedibile. Perché non usa un valore di sale generato in modo casuale che viene memorizzato insieme al nome utente e all'hash della password? (La password stessa non dovrebbe mai essere memorizzata da nessuna parte).
Ad ogni modo, è sicuro che il sale non viene memorizzato o trasmesso dal KDF perché è un input che viene utilizzato per generare un valore di uscita unidirezionale, matematicamente non reversibile. Il sale stesso non esiste nell'output.
Ma sia i nomi utente sia le password sono scelte piuttosto scadenti per i valori "salt" perché nessuno dei due è sufficientemente casuale (sufficientemente sicuro dalla duplicazione). Le password in particolare sono altamente suscettibili alla duplicazione su un ampio insieme di account. Molte persone finiscono per usare le stesse password.
Ma se aggiungi generato a caso sale a password identiche prima di eseguirne l'hashing, gli hash risultanti saranno completamente diversi l'uno dall'altro.
D'altra parte, avere valori salati identici (prevedibili!) su più account o più flussi di dati è una cattiva notizia perché introduce un grado di prevedibilità e potenzialmente apre la porta agli exploit.
EDIT # 2:
Hash e sale ... poiché sembrano esserci ulteriori commenti e domande su questo argomento, la linea di fondo è che gli algoritmi di hashing crittografici sono deterministici (lo stesso input in un algoritmo di hashing crittografico sempre produce lo stesso risultato).
Se ciò non fosse vero, allora questi algoritmi non sarebbero utili.
Il problema da un punto di vista della sicurezza è che se non si "saltano" i dati di input (tipicamente, le password), allora gli hash che si memorizzano o trasmettono non sono più unici dei dati originali.
Quindi, se crei un hash (attacchi dizionario o tabelle arcobaleno), hai crackato tutti quelli che corrispondono. Questo è esattamente ciò che ha portato (posso identificare un importante sito di social media business per nome?) Avendo qualcosa come 6 milioni di account compromessi un paio di anni fa.
"Salt" era solo un acuto acronimo nei giorni di green-screen per l'entropia (casualità). È carino pensare di "salare" il tuo "hash" (mettere sale su patate hashbrown o hash di manzo in scatola o altro).
Lo scopo di "salt" è di randomizzare l'input (la password). Se il sale viene generato casualmente, sarà completamente unico per ogni password. Aggiungilo alla password e all'improvviso ogni password è unica anche se migliaia di utenti scelgono la stessa password.
Il valore del sale in sé non è generalmente inteso come segreto. Spesso viene memorizzato direttamente accanto al valore hash (o anche aggiunto ad esso), e il dato originale segreto stesso (la password) non viene mai memorizzato.
Quindi, quando l'utente fornisce il segreto, il sale viene aggiunto alla stringa fornita nello stesso modo in cui era quando l'hash è stato originariamente creato, alimentato nell'algoritmo di hash, e se il risultato corrisponde all'hash memorizzato, si sa che l'utente ha fornito la password corretta.
Quello che @Fleche dice che i nomi utente non sono globalmente unici è vero, e le password non sono nemmeno uniche nei piccoli domini, figuriamoci globalmente.
Usando sia il nome utente che la password come salt in questo modo potrebbe aprirti a un attacco che non hai realmente previsto. Il nome utente è prevedibile e non universalmente univoco anche se sono unici nel tuo dominio. Ma in ogni caso i valori del sale non sono in genere segreti. Quindi potresti essere al sicuro. Ma sembra un po 'approssimativo.