In generale, sali e hash sono fatti lato server, non lato client. La comunicazione tra server e client deve essere protetta con crittografia (TLS). Come menziona Anders in un commento, questo potrebbe rispondere a molte delle tue domande: Per un'applicazione web HTTPS, vale la pena crittografare la password prima di inviarla, per impedire a un utente malintenzionato MITM di farlo da battito?
Informazioni su salti e hashing in generale: l'idea alla base di sali e hash spesso si riduce a costringere l'attaccante a eseguire un algoritmo a forza bruta. Questo (a) acquista il tempo di servizio per proteggere la rete e cambiare le password degli utenti, e (b) impedisce ai cattivi attori all'interno dell'azienda / sito web di acquisire la password dell'utente (per cose cattive come provare quella password su altri siti).
I sali fanno molte cose. (1) protegge da attacchi con arcobaleno come hai detto, (2) in caso di violazione dei dati, rende il cracking delle password più difficile dell'hash vaniglia (cioè, non c'è modo che un attaccante possa creare un database di tutti gli hash per un algoritmo: dovrebbero avere quel database per l'hash ogni , che non è fattibile); questo consente al sito / utenti di modificare l'algoritmo e le password, (3) impedisce alle persone che lavorano per il sito di rubare facilmente la password di un utente e (4) concede più opzioni architetturali per proteggere il processo di autenticazione.
Per parlare di (4) per un minuto, un mio cliente (molto grande internazionale) aveva un'architettura di microservizio, e i loro processi di autenticazione funzionavano tagliando la password con uno dei molti sali (basato sul nome utente) prima inviandolo al microservizio che ha verificato il database effettivo. Questo tipo di separazione impediva al codice che gestiva il database di conoscere sia sale che password, e il microservizio che sapeva che il sale non avrebbe mantenuto gli hash (né in memoria né su disco). Un utente malintenzionato non può utilizzare un dump del database; avrebbero bisogno del software e del database da più di un server. Ciò aumenta la complessità, dal momento che un database rubato non li avvicina più all'hashing del database; avrebbero anche bisogno dell'elenco di sali (da un altro server). Nessun dipendente ha avuto accesso a entrambi i server, cosa che ha aiutato con (3).
Perché l'hashing lato client non è super utile :
Un uomo nel mezzo dell'attacco può catturare tutto ciò che viene trasmesso tra il client e il server. Hashing la password prima di inviare fa molto poco; l'autore dell'attacco non deve essere in grado di generare l'hash, devono solo inviare nuovamente la stessa richiesta per ottenere l'accesso.
Ad esempio, osserviamo le seguenti richieste e parametri (non sto usando intestazioni HTTP reali per la leggibilità):
POST /auth/login
[email protected]
pass=mypassword
vs
POST /auth/login
[email protected]
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8
Il server non può sapere dall'hash che la vera password è "mypassword", quindi userà l'hash così com'è per verificare l'account dell'utente. Un utente malintenzionato che può leggere quella richiesta non ha bisogno di sapere che la tua password è "mypassword", devono solo prendere l'hash; che non fornisce alcuna protezione per l'account. La cosa solo impedisce che l'hacker possa testare la password su altri siti (ad esempio, molte persone usano scioccamente la stessa email e la stessa password per google e la loro banca).