Come l'hashing della password è utile nell'attacco MITM?

L'hashing della password viene utilizzato per proteggere gli utenti nel caso in cui un database venga compromesso. La trasmissione della password al server è uno scenario di sicurezza completamente diverso.

Entrambe le tue affermazioni sullo sniffing del traffico all'inizio della tua domanda sono corrette. La trasmissione della password in chiaro consente a un utente malintenzionato di annusare la password. Calcolare l'hash sul lato client rende essenzialmente l'hash la password, quindi un utente malintenzionato può solo annusare l'hash e utilizzarlo.

Per rispondere alle tue domande alla fine:

1. HTTPS utilizza SSL (o TLS) per fornire sicurezza endpoint-endpoint. Ciò significa essenzialmente che un utente malintenzionato non può annusare i dati, poiché è crittografato. Inoltre, non può iniettare dati, poiché anche l'autenticità è fornita. Quando viene utilizzato SSL, il server ha un certificato che contiene la sua chiave pubblica. Il certificato è firmato da una CA attendibile dal browser, pertanto è possibile verificare che sia corretta. Il browser genera una chiave di sessione e la crittografa utilizzando la chiave pubblica del server. Solo il server può decrittografarlo, perché solo il server conosce la chiave privata. Una volta che sia il server che il client conoscono la chiave di sessione, possono comunicare in modo sicuro.

2. Un ISP o un proxy potrebbero utilizzare un attacco man-in-the-middle per presentare un certificato falso. Se accetti quel certificato, possono decifrare la conversazione e iniettare i propri dati. Tuttavia, il tuo browser ti avviserà che il certificato non è valido. Alcuni governi ottengono certificati reali a loro assegnati per questo scopo, quindi non te ne accorgi se non controlli il certificato.

3. Se l'utente malintenzionato conosce la tua password WPA2, può connettersi alla rete. Ciò consente loro di intercettare il traffico.

Nella tua situazione, invia la password su HTTPS, quindi esegui l'hash sul lato server con un algoritmo di derivazione chiave strong come PBKDF2 o bcrypt.

Come ha detto il polinomio, l'hashing non riguarda la protezione di una password trasmessa. È così che se qualcuno entra nel tuo database, non ha immediatamente tutte le password.

Se sei preoccupato per un attacco MITM, una cosa che potresti voler provare è usare un nonce. Di 'che vuoi inviare la password. Per prima cosa invia una richiesta al server per generare una stringa casuale. Prendi la stringa restituita, e invece di inviare hash (passa) invii hash (hash (pass) + nonce). Quindi il server lo confronta con l'hash + nonce memorizzato per l'autenticazione. Anche se l'hacker annusa l'hash, non può riutilizzarlo perché ogni nonce è un uso singolo.

L'hashing della password non serve per la sicurezza delle password mentre vengono trasmesse via cavo, ma per storage sul server. Abbiamo le password hash perché a volte capita (più spesso di quanto vorremmo) che le persone cattive possano dare un'occhiata ai file e / o al database del server. Per quello che succede sul filo, abbiamo bisogno di due cose:

• Abbiamo bisogno dell'integrità perché l'autenticazione è sempre relativa ad alcuni dati scambiati successivamente. Non vogliamo un utente malintenzionato, in grado di eseguire un attacco MitM , per attendere l'autenticazione si verifica e quindi dirottare la connessione "autenticata" dal vivo.

• Abbiamo bisogno della riservatezza perché non vogliamo che gli hacker osservino le password in transito o persino gli hash delle password, perché un hash delle password è sufficiente per "testare le password a casa". Più in generale, di solito preferiamo che i dati sensibili che stiamo per scambiare rimangano confidenziali (non è sempre il caso, ma succede ancora spesso).

SSL fornisce entrambi. Quando si utilizza SSL (chiamato HTTPS in un contesto Web), la connessione è protetta da alterazioni, crittografata e il client è ragionevolmente sicuro di parlare al server giusto. In queste condizioni, la password può essere inviata da client a server senza alcun tipo di hash applicato, e questo è esattamente ciò che accade nella maggior parte dei siti Web in cui si digita il login e la password. Il server deve ancora memorizzare, da qualche parte nel suo database, alcuni dati che consentano la verifica della password inviata dall'utente; che l'elemento dati dovrebbe essere la password hash (con il solito assortimento di protezioni: hashing lento, sali ...).

Penso che il pezzo mancante per te sia l'uso di sali. Hai ragione, in quanto l'invio di un hash non è buono in quanto può essere annusato, un sale può essere utilizzato per proteggere l'hash della password. Un salt è un pezzo di dati casuali con hash che viene aggiunto all'hash della password, quindi il tutto viene re-hash. spw = hash (hash (pwd) + salt). Posso inviare lo spw più il sale all'altro lato che può quindi utilizzare la versione memorizzata localmente della password per l'autenticazione.

Il MiTM può intercettare spw e il sale, ma per ottenere pwd dovrebbe essere costretto a forzarlo, il che sarebbe computazionalmente costoso e dispendioso in termini di tempo. Nota che questo è vulnerabile agli attacchi di replay quindi non sto sostenendo quanto sopra come metodo di autenticazione, il punto è che aggiungendo un salt il MiTM non può ottenere l'hash della password. Challenge Handshake Authentication Protocol è un esempio del modo in cui i sali vengono utilizzati per l'autenticazione, ma se si vuole veramente impedire che gli attacchi MiTM utilizzino chiavi pubbliche-private.