L'hashing sul client ha senso solo se non ci si fida del server in qualche modo e non si vuole mostrare la password "effettiva" (quella che l'utente umano ricorda). Perché non vorresti mostrare la password proprio al sito su cui la suddetta password ha qualche utilità? Perché hai riutilizzato la password altrove! Ora di solito è male, ma esiste una versione relativamente sicura che si incarna in una miriade di estensioni del browser o bookmarklet come questo uno o quello (I don garanzia per la loro qualità). Si tratta di strumenti in cui l'utente umano ricorda una "password principale", da cui viene generata una password specifica del sito, utilizzando il nome del dominio del sito come una sorta di sale, in modo che due siti distinti ottengano password distinte.
Sebbene questo scenario abbia senso, farlo con Javascript inviato dal server stesso non lo fa. In effetti, il punto di hashing della password lato client è che il server è potenzialmente ostile (ad esempio sovvertito da un utente malintenzionato), e quindi il codice Javascript inviato da quel server è, per lo meno, sospetto. Non vuoi inserire la tua preziosa password in qualche Javascript ostile ...
Un altro caso per l'hashing lato client riguarda l'hashing lento . Poiché le password sono, per definizione, deboli, desideri bloccare gli attacchi al dizionario . Presumi che il cattivo abbia una copia del database del server e "provi le password" sulle sue macchine (vedi questo post del blog per alcune discussioni su questo). Per rallentare l'avversario, si impiega un processo di hashing intrinsecamente lento (come bcrypt ), ma questo renderà l'elaborazione lenta per tutti, incluso il server. Per aiutare il server, potresti voler scaricare parte del lavoro sul client, quindi fare almeno una parte di esso in qualche codice Javascript in esecuzione nel browser client ...
Sfortunatamente, Javascript è terribilmente lento in questo tipo di lavoro (in genere da 20 a 100 volte più lento del codice C decente) e il sistema client non sarà in grado di contribuire in modo sostanziale allo sforzo di hashing. L'idea è buona, ma dovrà attendere una tecnologia migliore (avrebbe funzionato con un client Java , tuttavia: con una JVM decente, il codice Java ottimizzato è da 2 a 4 volte più lento del codice C ottimizzato , per un lavoro di hashing).
Per riassumere, non c'è davvero buon motivo per fare l'hashing della password sul lato client, dal codice Javascript inviato dal server stesso. Basta inviare la password "così com'è" al server attraverso un tunnel HTTPS (la pagina di accesso, l'URL di destinazione del modulo e qualsiasi pagina protetta dalla password, devono tutti essere pubblicati su SSL, altrimenti tu avere problemi di sicurezza più urgenti rispetto all'uso delle password).