How does challenge-response protocol help against man-in-the-middle attacks?

How does challenge-response authentication prevent man-in-the-middle attacks? I read th开发者_如何转开发e wiki article but still I cannot understand.

In general, challenge-response systems do not necessarily prevent man-in-the-middle-attacks: If Alice is trying to tell Bob her bank account number, this protocol, which does implement some challenge and response, won't provide integrity or privacy:

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 could answer "yes" in place of either Alice or Bob, could fake the third 'result' message, or could listen in on the third message.

Even if the challenges are improved, to something like: "Please hash 0x31415926 prepended to our shared password", data transmitted in the clear (or under weak/poor ciphers or with poor key selection) would be subject to loss of privacy, and data transmitted without any message authentication checks could be subject to modification by a third party.

Where challenge/response protocols really shine is in preventing replay attacks: if Alice just sends Bob a message along the lines of "Please debit my account $5 and credit your account $5", Mallory could record the message and replay the message to deplete Alice's account.

A good challenge/response system will generate a new challenge for every transaction or session (and make sure that previous challenges are not reused!), so that session transcripts cannot be spliced together to create new fraudulent systems.

I hope this helps, but I'm afraid without more detailed idea of where your doubts are coming from, it'll just be noise.

User sarnold already provides a good answer, I'd like to drag attention to the following.

Challenge-response solves two problems - makes sending the secret in plaintext unnecessary (hash-like product is sent) and prevents replay attacks (since challenges change every time). It doesn't do anything beyond that - it doesn't authenticate anyone to anyone on its own, it is only an improvement of a plaintext protocol where the client sends his username and password (the secret) and the server decides whether those are correct.

So if there's some party in the middle it won't help detect it or prevent it from impersonating as the client for that specific session, yet that party will not gain access the the secret, since the secret is never sent in plaintext, and that party will be unable to impersonate again by doing a replay - it can only work impersonated during that very session.