Per un'applicazione Web HTTPS, vale la pena crittografare la password prima di inviarla, per impedire a un aggressore MITM di sfruttarlo?

29

La nostra applicazione ha recentemente superato test di penetrazione. Il test ha rilevato una violazione della sicurezza critica , che è essenzialmente:

Il problema:

  • L'attaccante imposta uno spot WiFi.
  • L'utente entra nel nostro sito (che è HTTPS).
  • Utilizzando uno strumento come Cain, l'utente malintenzionato reindirizza l'utente a HTTP o lo mantiene in HTTPS con un certificato di spoofing. (In entrambi i casi, l'utente doveva passare attraverso la pagina "get me out of here" / "aggiungi eccezione")
  • L'utente inserisce il suo nome utente e la sua password.
  • La password viene pubblicata sull'attaccante MITM, che può vederlo. Apparentemente Cain ha una funzione per raccogliere automaticamente nome utente e password, e la nostra password sarebbe facilmente catturata lì.

Soluzione suggerita

Il report consiglia di crittografare o eseguire l'hashing della password sul lato client (utilizzando JavaScript), in un modo che non può essere riprodotto (ad esempio, utilizzando il pad singolo / time stamp). Non potevano raccomandare uno schema specifico (hanno menzionato i certificati client, che potrebbero essere poco pratici per un'applicazione di grandi dimensioni).

Vale la pena crittografare o troncare la password prima di pubblicarla? È pratica comune?

    
posta Kobi 31.08.2014 - 10:47
fonte

3 risposte

47

Questa raccomandazione non ha senso: Il codice JavaScript utilizzato per hash o crittografare la password deve essere trasferito anche al client. Se l'attaccante è in grado di montare un attacco man-in-the-middle, sarà in grado di ispezionare anche il codice JavaScript utilizzato per la crittografia o potrebbe addirittura sostituirlo con qualcos'altro (come nessuna crittografia).

L'hashing invece della crittografia ha ancora meno senso, perché funziona solo se il server accetta la password con hash anziché la vera password. In questo caso l'hacker non ha nemmeno bisogno di conoscere la password, ha solo bisogno di conoscere l'hash.

Che cosa potrebbe essere d'aiuto sarebbe un certificato client perché non è possibile montare un attacco man-in-the-middle SSL che conserva il certificato client (e un downgrade a HTTP semplice non invierà nemmeno il certificato). Ma, dato che devi prima distribuire i certificati ai client e farli installare nel browser, questa soluzione funziona solo quando hai pochi client.

A parte questo: se l'attaccante è nel mezzo potrebbe non aver bisogno della password. Tutto ciò di cui ha bisogno è che la vittima abbia effettuato l'accesso e che l'aggressore possa prendere il controllo della sessione esistente.

Potrebbe anche essere utile rilevare una simile situazione man-in-the-middle, in modo da poter informare l'utente e negare il login da reti compromesse. Alcune idee per rilevare i downgrade della connessione (ovvero http all'attaccante che la inoltra come https):

  • Verifica il metodo della posizione corrente con JavaScript.
  • Crea un cookie sicuro con JavaScript. Dovrebbe essere rispedito solo se il sito è servito con https (che non è un downgrade).
  • Includi uno script come HTTP che server un'immagine e controlla sul lato server come è stata inclusa l'immagine. Se è stato incluso come HTTPS, puoi assumere un attacco di downgrade HTTP perché lo hai incluso esplicitamente con HTTP. Se si accede con HTTP, si ha anche un attacco di downgrade (ma con un aggressore più intelligente) o il browser non si preoccupa dei contenuti misti.

E su come rilevare man-in-the-middle con i certificati falsi:

  • Imposta un secondo sito https (con un nome host diverso) e costruisci una richiesta ajax su questo sito in un modo, che non è semplice per l'hacker di passare a http (ad esempio crea dinamicamente URL). Se l'autore dell'attacco tenta semplicemente di visitare qualsiasi sito MITM, questa richiesta di ajax avrà esito negativo almeno con alcuni browser, poiché il certificato non è attendibile e il browser chiederà all'utente solo i certificati primari di un sito.

Naturalmente tutto questo aiuta solo contro un attaccante che non è determinato a hackerare in particolare tu, ma prende solo gli obiettivi più facili. In questo caso, tutto ciò che devi fare è essere un po 'più difficile da attaccare rispetto al resto.

    
risposta data 31.08.2014 - 10:55
fonte
10

Suggerirei invece di implementare Sicurezza di trasporto rigorosa HTTP , che impedisce all'utente di accettare il certificato falsificato in primo luogo .

    
risposta data 02.09.2014 - 03:44
fonte
3

Se vuoi ignorare che l'autore dell'attacco potrebbe facilmente sostituire il codice Javascript durante un attacco MITM attivo:

È possibile generare una chiave di crittografia asimmetrica, fornire al client quella chiave pubblica per utilizzarla per crittografare il lato client della password. Se si utilizza una nuova chiave per ogni accesso, nessuno dovrebbe essere in grado di riprodurre la password.

    
risposta data 31.08.2014 - 21:47
fonte

Leggi altre domande sui tag