How does challenge-response authentication prevent man-in-the-middle attacks? I read the wiki article but still I cannot understand.

- 167,383
- 100
- 513
- 979

- 710
- 1
- 10
- 22
-
1Is there something specific you do not understand? – sarnold Jan 21 '11 at 07:22
-
Are you reading this link? http://en.wikipedia.org/wiki/Challenge-response_authentication Yes, I think it's confusing. – Harvey Kwok Jan 21 '11 at 08:02
2 Answers
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.

- 102,305
- 22
- 181
- 238
-
will a challenge response system using public key cryptography help eliminate man in the middle attack? – user574183 Jan 21 '11 at 08:16
-
@user574183: How exactly would you want it to use public key cryptography? – sharptooth Jan 21 '11 at 08:29
-
-
@user574183: There's one secret - say the password. The client knows the password and the server knows the password. Looks like a symmetric key. – sharptooth Jan 21 '11 at 08:34
-
@user574183: They operate on both symmetric and asymmetric systems: You could replace my "hash the secret with this nonce" routine with "Decrypt this nonce using your private key, then sign the sha-256 hash of the nonce concatenated to your username, and return the signature". (You never want to design a protocol that requires one party to sign content entirely provided by another party; every use of public key systems leaks some (very small) amount of key data, so always sign _hashes_ of data.) – sarnold Jan 21 '11 at 08:52
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.

- 1
- 1

- 167,383
- 100
- 513
- 979
-
ok so in this challenge/response authentication a man in the middle attack is possible only if the middle one knows the secret key. If the key is known he would be able to decrypt the challenge and answer the challenge correctly am i correct ? – user574183 Jan 21 '11 at 08:29
-
@user574183: First the challenge is sent unencrypted, the secret is used to combine the challenge with the secret. If the party-in-the-middle knows the secret it can impersonate as a client at any time - it know the secret, so the server can't distinguish between it and the client. It can also interfere with a session already in progress even wihtout knowing the secret - the secret is only used in teh beginning, it is not used for the data being sent during the session. – sharptooth Jan 21 '11 at 08:33