I sali devono essere globalmente unici
Anche se questo potrebbe non essere applicabile al tuo caso, ci sono buone ragioni per cui i sali non possono essere derivati da un nome utente o da altri dati costanti sull'utente.
Considera un utente Alice che utilizza la stessa password su più siti, entrambi i quali usano il suo nome utente come sale. Ciò porterà allo stesso hash che appare in entrambi. Utilizzare una combinazione di nome utente e sito stesso per il sale dovrebbe rispondere a quella specifica preoccupazione.
Formato sali
Come altri hanno sottolineato, il tuo sale è nel formato sbagliato. È possibile eseguire un hash dell'indirizzo e-mail e del nome del sito e quindi troncare tale hash a 16 byte.
L'hashing del lato server è ancora richiesto
Ci sono alcune cose che l'hashing lato client offre, ma non può mai (beh, quasi mai) essere un sostituto per l'hashing lato server. E a meno che non sia associato ad altre costruzioni utili, l'hashing del lato client non offre davvero molto. Per lo più aiuta a salvare il server un po 'di lavoro.
Il più evidente apparente vantaggio dell'hash del lato client è che rende più difficile per il servizio imparare la password dell'utente poiché la password stessa non viene inviata. Ma quel vantaggio funziona solo con un modello di minaccia molto limitato. È necessario un utente malintenzionato in grado di acquisire il lato server della password quando viene inviato dal client, ma non può modificare il codice JavaScript nella pagina di accesso.
C'è anche una sorta di superamento della mentalità di hash qui. L'hash che il client invia è un segreto. Se viene catturato (diciamo in transito) può essere utilizzato da un utente malintenzionato per accedere al servizio proprio come farebbe la conoscenza della password di origine. Quindi, solo perché l'hash non sembra un segreto (mentre la password di origine lo fa), è una prova di autenticazione.
Non sto dicendo che l'hashing del lato client è inutile, ma è molto meno utile che la gente si aspetta in molte circostanze.