https security - la password deve essere hashed lato server o lato client?

Se esegui l'hash sul lato client, la password con hash diventa la vera password (con l'algoritmo di hash non è altro che un mezzo per convertire un mnemonico user-held nella password effettiva).

Ciò significa che nel database verrà archiviata la password completa "plain-text" (l'hash) e in primo luogo avrai perso tutti i vantaggi dell'hashing.

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

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).

Trovo che tutte le tue preoccupazioni suonino, ma la mia raccomandazione sarebbe di farlo lato server.

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

Un'altra opzione sarebbe quella di generare le password lato server; quindi non stai inviando una password in chiaro. Ma avresti ancora bisogno di comunicare la password all'utente. E poiché la maggior parte degli utenti continua a non utilizzare l'e-mail crittografata, la considero meno sicura.

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

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

L'hashing sul 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 è, se il client ha hash la password, il server potrebbe comunque accedere a un sistema, ma hai protetto la password dell'utente che è importante se la usano altrove.
2. Protegge la password dell'utente quando l'utente pensa di collegarsi a un server, ma si connettono realmente a un altro (errore dell'utente). Ad esempio, se ho due conti bancari e accidentalmente inserisco una delle password della mia banca nel sito web della banca sbagliata, se la banca ha cancellato la password sul lato client, quella banca non conoscerebbe la password della mia altra banca. Penso che sarebbe una cosa "educata" da fare per l'hash lato client in modo che la loro password in chiaro non venga mai trasmessa sul filo.

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 il possibile 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.

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

Il punto è che la password deve essere sottoposta a hash sul server in modo che il malintenzionato non possa utilizzare gli hash che ha violato dal database dal server per accedere al proprio account o ai propri dati.

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

La risposta @Thomas Pornin ha anche fornito un ottimo motivo per cui si vorrebbe hash la password sul client, ma la cosa che descrive nella sua prima storia può essere eseguita solo se il back-end del server supporta la gestione delle password con hash (cioè non hash la password se già hash, ma che qualcuno cerchi di supportare qualcosa del genere è altamente improbabile), il che non è il caso per la maggior parte del tempo, suppongo. La seconda storia di lui è molto buona.

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

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

L'invio della password in chiaro non è un problema serio se utilizzerai https. Idealmente, il tuo server dovrebbe rifiutarsi di pubblicare pagine in http in modo da evitare l'attacco dell'uomo nel mezzo. Il ragionamento è: un utente malintenzionato potrebbe forzatamente "downgrade" la connessione da https a http e avviare il traffico sniffing (ad esempio con uno strumento come SSL Strip).

Se il tuo server ha più amministratori possibili e non puoi necessariamente fidarti di tutti loro per non scaricare i dump di ram, dovresti davvero hash lato client per proteggere gli amministratori dal furto di password utente [che possono essere riutilizzate su altri siti web- -inoltre questo è una cattiva pratica, gli utenti lo fanno e continueranno a farlo], e poi ha quel lato server hash in modo che il furto della tabella non dia automaticamente agli hacker la cosiddetta password in chiaro per il sito web stesso.

E finché usi la funzione di hash sicura, puoi usare lo stesso sale per entrambi i lati.

A tutti gli effetti vorrete solo hash sul lato client. L'idea alla base di un hash è di impedire a chiunque tranne l'utente di conoscere la password. Poiché ogni buon sito dovrebbe utilizzare TLS, il fatto che l'hash venga inviato al server è irrilevante (si noti che anche se ciò rappresentasse un problema nell'inviare la password in testo semplice sarebbe altrettanto grave).

Infine, le risposte elencate sembrano non riuscire a capire che se il server viene mai compromesso, ogni individuo sulla password del server verrà compromesso dal momento che le password vengono inviate in chiaro.