Se si esegue l'hash sul lato client, la password con hash diventa la password effettiva (con l'algoritmo di hashing che non è altro che un mezzo per convertire un mnemonico gestito dall'utente nella password effettiva).

Ciò significa che memorizzerai l'intera password "in testo normale" (l'hash) nel database e avrai perso tutti i vantaggi dell'hashing in primo luogo.

Se decidi di seguire questa strada, potresti anche rinunciare a qualsiasi hashing e semplicemente trasmettere e memorizzare la password grezza dell'utente (che, per inciso, non consiglierei particolarmente).

L'hash sul client ha senso solo se non ci si fida in qualche modo del server e non si vuole mostrare la password "effettiva" (quella che l'utente umano ricorda). Perché non vuoi mostrare la password proprio al sito in cui la suddetta password ha qualche utilità? Perché hai riutilizzato la password altrove! Di solito è male, ma esiste una versione relativamente sicura che si incarna in miriadi di estensioni del browser o bookmarklet come questo o quello (non garantisco 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 di dominio del sito come una sorta di sale, in modo che due siti distinti ottengano password distinte.

Anche se questo scenario ha senso, farlo con Javascript inviato dal server stesso non lo fa. In effetti, lo scopo dell'hashing della password lato client è che il server è potenzialmente ostile (ad es. Sovvertito da un aggressore), e quindi il codice Javascript inviato da quel server è, come minimo, sospetto. Non vuoi inserire la tua preziosa password in qualche Javascript ostile ...

Un altro caso di hashing lato client riguarda l ' hashing lento . Poiché le password sono, per definizione, deboli, vuoi contrastare gli attacchi ai dizionari. Presumi che il malintenzionato abbia una copia del database del server e "proverà le password" sulle sue macchine (vedi questo post del blog per alcune discussioni su questo). Per rallentare l'avversario, utilizzi un processo di hashing intrinsecamente lento (come bcrypt), ma questo rallenterà l'elaborazione per tutti, incluso il server. Per aiutare il server, potresti voler scaricare parte del lavoro sul client, quindi eseguirne almeno una parte in un po 'di codice Javascript in esecuzione nel browser del client ...

Sfortunatamente, Javascript è terribilmente lento in questo tipo di lavoro (in genere da 20 a 100 volte più lento di un codice C decente) e il sistema client non sarà in grado di contribuire in parte sostanziale allo sforzo di hashing. L'idea è valida ma dovrà aspettare una tecnologia migliore (avrebbe funzionato con un client Java , però: 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 ci sono davvero buoni motivi per eseguire l'hashing delle password lato client, dal codice Javascript inviato dal server stesso. È sufficiente inviare la password "così com'è" al server tramite un tunnel HTTPS (la pagina di accesso, l'URL di destinazione del modulo e qualsiasi pagina sia protetta dalla password devono essere tutte servite tramite SSL, altrimenti hanno problemi di sicurezza più urgenti rispetto all'uso delle password).

Trovo che tutte le tue preoccupazioni siano valide, ma il mio consiglio sarebbe di farlo lato server.

C'è sempre una possibilità abbastanza grande che un utente lasci il proprio terminale sbloccato, consentendo la manipolazione. E anche; se la tua logica di hashing è lato client, la stai esponendo.

Un'altra opzione potrebbe essere quella di generare le password lato server; allora non stai inviando una password in chiaro. Ma avresti comunque bisogno di comunicare la password all'utente. E poiché la maggior parte degli utenti non utilizza ancora la posta elettronica crittografata, la considero meno sicura.

Ho visto soluzioni per inviare password tramite un tunnel crittografato a un cellulare; ma dubito che la sicurezza sia migliore di SSL. Forse qualcuno potrebbe provare / confutare questo?

L'hashing lato server è importante come hanno indicato tutte le altre risposte, ma vorrei aggiungere che l'hashing lato client sarebbe una bella funzionalità di sicurezza oltre all'hashing lato server.

L'hashing lato client presenta vantaggi nei seguenti scenari:

1. Protegge la password dell'utente quando il server è compromesso. Cioè se il client non è compromesso, ma il server lo è, se il client esegue l'hashing della password, il server potrebbe comunque ottenere l'accesso a un sistema, ma hai protetto la password dell'utente, il che è importante se utilizza quella password altrove.
2. Protegge la password dell'utente quando l'utente pensa di accedere a un server ma in realtà accede a un altro (errore utente). Ad esempio, se ho due conti bancari e digito accidentalmente una delle password della mia banca nel sito web della banca sbagliata, se la banca ha effettuato l'hashing della password lato client, quella banca non conosceva la password dell'altra banca. Penso che sarebbe una cosa "educata" da fare per eseguire l'hashing lato client in modo che la loro password in testo semplice non venga mai trasmessa via cavo.

Per lo più mostra rispetto per la password dell'utente. L'utente condivide un segreto che potrebbe non essere esclusivo del tuo software, quindi se rispetti quel segreto, dovresti fare tutto quanto in tuo potere per proteggerlo.

Se ti trovi in ​​un tunnel HTTPS, la password o l'hash devono essere protetti dalla sorveglianza Ethernet.

Sul lato client forse potresti salare l'hash con un ID di sessione.
Questo potrebbe essere più difficile da simulare per Javascript dannoso.

L'hashing della password lato client richiederà Javascript. Alcune persone disabilitano Javascript sul proprio browser. Devi gestire questo scenario.

Ho visto software per forum che esegue l'hashing della password lato client e invia l'hash all'accesso se possibile , altrimenti la password viene inviata in chiaro testo. Quindi funziona in entrambe le situazioni.

L'invio della password in chiaro non è una delle principali preoccupazioni se si utilizza https. Idealmente il tuo server dovrebbe quindi rifiutarsi di servire pagine in http in modo da evitare attacchi man in the middle. Il ragionamento è: un utente malintenzionato potrebbe forzatamente "eseguire il downgrade" della tua connessione da https a http e avviare lo sniffing del traffico (ad esempio con uno strumento come SSL Strip).

La risposta accettata di @Nicole Calinoiu è ovviamente corretta ma forse troppo difficile da capire all'inizio.

Il punto è la password dovrebbe essere sottoposto ad hashing sul server in modo che il malintenzionato non possa utilizzare gli hash che ha violato dal database dal server per ottenere l'accesso al tuo account o ai tuoi dati.

Come già detto, se hai l'hash sul lato client e il back-end lo supporta, l'hash diventa la tua password e se l'hash viene rubato tramite un hack, l'hacker ha la password.

La risposta di @Thomas Pornin ha anche trovato un ottimo punto sul motivo per cui dovresti voler hash la password sul client, ma la cosa che descrive in la sua prima storia può essere fatta solo se il back-end del server supporta la gestione delle password con hash (cioè non eseguire l'hashing della password se è già hash, ma che qualcuno cerchi di supportare qualcosa del genere è altamente improbabile), il che la maggior parte delle il tempo non sarà il caso immagino. La seconda storia di lui è molto buona.

È possibile eseguire entrambe le operazioni, eseguirne l'hashing sul client in modo che se l'aggressore riesce a superare la sicurezza https non sarà in grado di vedere la password in testo normale. Quindi hash di nuovo sul server in modo che se l'aggressore ottiene le password memorizzate nel server, non può semplicemente inviarle al server e ottenere l'accesso alla password.

Se il tuo server avrà più possibili amministratori e non puoi necessariamente fidarti di tutti loro per non ottenere ram dump, dovresti davvero eseguire l'hashing lato client per proteggere gli amministratori dal rubare le password degli utenti [che potrebbero essere riutilizzate su altri siti web- -Nonostante questa sia una cattiva pratica, gli utenti lo fanno e continueranno a farlo], quindi hash quel lato server in modo che il furto della tabella non dia automaticamente agli aggressori la cosiddetta password in chiaro per il sito web stesso.

E fintanto che utilizzi la funzione di hash sicuro, puoi utilizzare lo stesso salt per entrambi i lati.

A tutti gli effetti, vorrai eseguire l'hashing solo sul lato client. L'idea alla base di un hash è impedire a chiunque tranne l'utente di conoscere la password. Poiché qualsiasi buon sito dovrebbe utilizzare TLS, il fatto che l'hash venga inviato al server è irrilevante (si noti che anche se questo fosse un problema, l'invio della password in testo normale sarebbe altrettanto negativo).

Infine le risposte elencate sembrano non riuscire a rendersi conto che se il server viene compromesso ogni individuo sulla password del server verrà compromesso poiché le password vengono inviate ad esso in testo normale.