Vulnerabilità dei protocolli challenge-response (autenticazione) agli attacchi man-in-the-middle in linea

Question

Vulnerabilità dei protocolli challenge-response (autenticazione) agli attacchi man-in-the-middle in linea

#1 da (2 voti)

0

Tutti i protocolli challenge-response (o di altra autenticazione) sono vulnerabili agli attacchi main-in-the-middle in linea?

Diciamo che Alice vuole impostare una connessione con Bob (ad esempio, vuole accedere su un server). Bob le manda un numero casuale, r. Alice risponde quindi con un MAC del numero casuale, usando la sua password. Bob sa che solo Alice può farlo e registrarla sul server.

E se durante tutto questo tempo ci fosse stato un avversario online tra Alice e Bob. Può intercettarlo e inviarlo ad Alice stesso. Poteva falsificare l'IP del server, quindi Alice pensa che provenga da Bob. Alice invia quindi la sua risposta e di nuovo l'avversario lo intercetta e lo invia al server. L'avversario ha appena inoltrato il messaggio in modo che Bob lo accetti come corretto e accede all'avversario. Ora ha impostato una connessione con Bob, nel nome di Alice.

Il mio ragionamento è corretto? Suppongo che, per questo motivo, non utilizzerai mai i protocolli challenge-response per accedere a un utente o avviare una sessione. Se non sbaglio, l'uso delle chiavi di sessione protegge da questo attacco e consente una connessione sicura.

authentication man-in-the-middle challenge-response

posta Thomas Vanhelden 05.06.2017 - 13:43

fonte

1 risposta

Leggi altre domande sui tag authentication man-in-the-middle challenge-response

Quali possibili attacchi potrebbero verificarsi su una porta TCP / IP di SQL Server? Selezione del codice cloudflare basata sul supporto AES-NI

score 2 · Accepted Answer

La tua ipotesi è vera se Alice e Bob devono fare affidamento esclusivamente su questo singolo canale di comunicazione e non avere alcun tipo di conoscenza dell'altra parte prima di stabilire la connessione.

Ma considera che Alice ha una coppia di chiavi dove la chiave pubblica è pubblica e quindi nota a Bob ma la chiave privata è nota solo ad Alice. In questo caso di conoscenza precedente esistente, Bob può inviare una sfida ad Alice che può firmare con la chiave privata. Questa firma può essere verificata da Bob utilizzando la chiave pubblica. Un uomo nel mezzo non può fingere perché non ha accesso alla chiave privata.

Questo meccanismo può essere reso più flessibile con un Public Key Innfrastructure (PKI) in modo che Bob non abbia bisogno di sapere tutte le chiavi pubbliche di tutte le possibili Alice, ma devono solo fidarsi di un'agenzia di certificazione che emette certificati per questi Alice. E questo è fondamentalmente il modo in cui il server è autenticato in SSL / TLS per rilevare gli attacchi man in the middle.

Si noti che la crittografia a chiave pubblica non è l'unico modo in cui la conoscenza precedente potrebbe essere usata per difendersi da tale attacco di mezzo. Un segreto condiviso tra entrambi i lati della comunicazione funzionerebbe anche se l'uomo in mezzo all'attaccante non conosce il segreto. Ma la crittografia a chiave pubblica che utilizza un PKI si adatta meglio se sono coinvolte molte parti.