W jaki sposób protokół typu challenge-response pomaga w atakach typu man-in-the-middle?

Question

W jaki sposób uwierzytelnianie typu challenge-response zapobiega atakom typu man-in-the-middle? Przeczytałem artykuł wiki, ale nadal nie mogę tego zrozumieć.

Answer 1

Ogólnie rzecz biorąc, systemy reagowania na wyzwania niekoniecznie zapobiegają atakom pośrednim: Jeśli Alicja próbuje podać numer konta bankowego Bobowi, ten protokół, który wykonuje pewne wyzwanie i odpowiedź, wygrał ". t zapewnienie integralności i prywatności:

Alice: Bob, is that you? // first challenge 
Bob: Yes, Alice, it is me, is that you? // first response, second challenge 
Alice: Yes! Great. My account number is 314159. // second response, and result 

Mallory mógł odpowiedzieć „tak” w miejsce obu Alice lub Bob może fałszywy komunikat trzeci „wynik”, czy może słuchać na trzecim komunikacie.

Nawet jeśli wyzwania zostaną poprawione, na przykład: "Proszę hasz 0x31415926 dodany do naszego wspólnego hasła", dane przesyłane w przejrzysty sposób (lub pod słabymi/złymi szyframi lub przy złym doborze klucza) mogą ulec utracie prywatność, a dane przesyłane bez jakiejkolwiek weryfikacji uwierzytelnienia wiadomości mogą podlegać modyfikacji przez stronę trzecią.

Gdzie protokoły wyzwanie/odpowiedź naprawdę zabłysnąć w zapobieganiu atakom powtórzenie: jeśli Alice właśnie wysyła Bobowi wiadomość wzdłuż linii „Proszę obciążyć moje 5 dolarów, a Twoje konto 5 $”, Mallory mogła nagrać wiadomość i powtórka wiadomość, aby zlikwidować konto Alice.

Dobry system wyzwań/reakcji stworzy nowe wyzwanie dla każdej transakcji lub sesji (i upewnij się, że poprzednie wyzwania nie zostaną ponownie wykorzystane!), Tak że transkrypty sesji nie mogą być łączone razem w celu utworzenia nowych nieuczciwych systemów.

Mam nadzieję, że to pomoże, ale obawiam się, że bez bardziej szczegółowego pojęcia, skąd pochodzą twoje wątpliwości, będzie to po prostu hałas.

Answer 2

już zapewnia a good answer, chciałbym zwrócić uwagę na następujące.

Wyzwanie-odpowiedź rozwiązuje dwa problemy - sprawia, że ​​wysyłanie sekretu w postaci zwykłego tekstu jest niepotrzebne (wysyłany jest produkt podobny do hash) i zapobiega atakom typu "powtórka" (ponieważ wyzwania zmieniają się za każdym razem). Nie robi nic poza tym - nie uwierzytelnia nikogo komukolwiek samemu, jest tylko ulepszeniem protokołu zwykłego tekstu, w którym klient wysyła swoją nazwę użytkownika i hasło (sekret), a serwer decyduje, czy są one poprawne .

Więc jeśli w środku jest jakaś impreza, nie pomoże to w wykryciu go lub uniemożliwi mu podszywanie się pod klienta podczas tej konkretnej sesji, ale ta strona nie uzyska dostępu do sekretu, ponieważ sekret nie zostanie nigdy wysłany zwykły tekst, a strona ta nie będzie w stanie ponownie podszyć się pod inną osobę, wykonując powtórkę - może tylko podszywać się pod nią podczas tej sesji.