Ho letto da qualche parte che quando si utilizza l'accesso basato su chiave invece di un accesso basato su password, non è possibile che si verifichi un attacco Man-in-the-Middle.
Questa domanda non riguarda ciò che è più sicuro: login basato su chiave o accesso basato su password .
Invece sono interessato a sapere:
In primo luogo, un uomo nel mezzo di attacco non può accadere né con la chiave basata né con l'autenticazione basata su password se il client autentica correttamente il server.
Un uomo nell'attacco centrale è possibile se una password viene utilizzata solo se il client ignora l'avviso che l'impronta digitale del server è cambiata. In questo caso il client crea inconsapevolmente una connessione con l'utente malintenzionato, che come endpoint della connessione può leggere la password semplice inserita dall'utente e quindi può inoltrare i dati al server originale.
Se invece viene utilizzata una coppia di chiavi per l'autenticazione, il client non fornisce la chiave privata ma fornisce solo la prova che possiede la chiave privata alla chiave pubblica conosciuta dal server firmando un messaggio. Il messaggio da firmare contiene l'identificatore di sessione della connessione, che a sua volta è il risultato dello scambio di chiavi e quindi diverso per la connessione tra client e attaccante e attaccante e server. Ciò significa che la prova di proprietà fornita dal client all'autore dell'attacco non può essere riutilizzata dall'attaccante come prova di proprietà del server e quindi l'autenticazione contro il server avrà esito negativo.
Si noti che questo è molto simile all'autenticazione basata su certificato client in TLS. Pertanto, vedi anche L'autenticazione reciproca ha un impatto sulle possibilità MiTM ? .
È un argomento importante. Qui ho intenzione di condividere alcuni dettagli senza troppo che non sono necessari e un buon riferimento.
Man-in-the-Middle non è ostacolato dall'autenticazione dell'utente ma dall'autenticazione del server. Prima che l'utente sia autenticato, il server è.
Ciò avviene tramite Diffie-Hellman per creare un segreto condiviso e un identificatore di hash / sessione di scambio. Un uomo nel mezzo avrebbe bisogno di fare uno scambio di DH tra il Cliente e loro stessi e il Server. Entrambe le uscite saranno garantite per essere diverse.
Il server firma l'identificatore di sessione con la sua chiave privata. Il client lo verifica con la chiave pubblica del server. Tieni presente che è affidabile al primo utilizzo, quindi è aperto a MITM fino a quando non è stato stabilito tutto.
La RFC ha più dettagli.
Leggi altre domande sui tag cryptography ssh tls man-in-the-middle key-exchange