7

質詢 - 響應認證如何防止中間人攻擊?我閱讀了維基文章,但仍然無法理解。挑戰 - 響應協議如何幫助抵禦中間人攻擊?

+1

有什麼具體的你不明白? – sarnold 2011-01-21 07:22:23

+0

您是否正在閱讀這個鏈接? http://en.wikipedia.org/wiki/Challenge-response_authentication是的,我認爲它很混亂。 – 2011-01-21 08:02:15

回答

8

一般來說,挑戰 - 響應系統不一定能防止中間人攻擊:如果Alice試圖告訴Bob她的銀行帳號,這個協議確實實現了一些挑戰和迴應,牛逼提供完整性和保密性:

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 

馬洛裏可以回答「是」的地方Alice或者鮑勃的,可以僞造的第三個「結果」的消息,或能竊聽到的第三個消息。

即使挑戰得到改善,例如:「請在我們的共享密碼前面加上hash 0x31415926」,以明文形式傳輸的數據(或者在弱/弱密碼或劣質密鑰選擇下)將會丟失隱私和未經任何消息身份驗證檢查而傳輸的數據可能會由第三方進行修改。

凡質詢/響應協議大放異彩是在防止重播攻擊:如果Alice只是向Bob發送沿線的消息「請借記我的帳戶$ 5存入您的帳戶$ 5」,馬洛裏可以記錄該信息並重播消息來消耗Alice的帳戶。

一個好的挑戰/響應系統會對每個事務或會話產生新的挑戰(並確保以前的挑戰不會被重複使用!),因此會話記錄不能拼接在一起以創建新的欺詐系統。

我希望這會有所幫助,但恐怕沒有更詳細的想法,您的懷疑來自何處,它只是噪音。

+0

將使用公鑰密碼術的挑戰反應系統幫助消除中間人的攻擊? – user574183 2011-01-21 08:16:27

3

User sarnold已經提供了a good answer,我想把注意力放到下面。

挑戰 - 響應解決了兩個問題 - 使發送祕密不必要(散列式產品發送),並防止重播攻擊(因爲挑戰每次都會改變)。除此之外,它沒有做任何事情 - 它不會向任何人認證任何人,它只是客戶端發送他的用戶名和密碼(祕密)的明文協議的改進,並且服務器決定這些是否正確。

因此,如果在中間有某個派對,它將無法檢測到它或阻止它作爲該特定會話的客戶端進行模擬,但該派對將無法訪問該祕密,因爲該祕密從未發送過明文,並且該方將不能通過重播來模仿 - 它只能在該會話期間模仿。