チャレンジレスポンス認証は、man-in-the-middle攻撃をどのように防止しますか？wikiの記事を読みましたが、それでも理解できません。
質問する
8514 次
2 に答える
10
一般に、チャレンジレスポンスシステムは必ずしも中間者攻撃を防ぐわけではありません。アリスがボブに銀行口座番号を伝えようとしている場合、チャレンジとレスポンスを実装するこのプロトコルは整合性を提供しません。プライバシー：
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
マロリーは、アリスまたはボブの代わりに「はい」と答えたり、3番目の「結果」メッセージを偽造したり、3番目のメッセージを聞いたりすることができます。
課題が改善されたとしても、「共有パスワードの前に0x31415926をハッシュしてください」のように、クリアで（または弱い/貧弱な暗号で、または不十分なキー選択で）送信されたデータはプライバシーとデータを失う可能性がありますメッセージ認証チェックなしで送信された場合、サードパーティによって変更される可能性があります。
チャレンジ/レスポンスプロトコルが本当に優れているのは、リプレイ攻撃の防止です。アリスがボブに「アカウントに5ドルの借方を記入し、アカウントに5ドルの貸方を記入してください」というメッセージを送信した場合、マロリーはメッセージを録音して再生し、アリスのアカウントを使い果たす可能性があります。 。
優れたチャレンジ/レスポンスシステムは、すべてのトランザクションまたはセッションに対して新しいチャレンジを生成します（そして、以前のチャレンジが再利用されないようにします！）。そのため、セッションのトランスクリプトをつなぎ合わせて新しい不正なシステムを作成することはできません。
これがお役に立てば幸いですが、あなたの疑問がどこから来ているのかについての詳細な考えがなければ、それはただのノイズになるでしょう。
于 2011-01-21T07:40:12.927 に答える
3
ユーザーsarnoldはすでに良い答えを提供しています、私は以下に注意を引き付けたいと思います。
チャレンジレスポンスは2つの問題を解決します-プレーンテキストでシークレットを送信する必要がなくなり（ハッシュのような製品が送信されます）、リプレイ攻撃を防ぎます（チャレンジは毎回変更されるため）。それ以上のことは何もしません-それは自分自身で誰かを誰に対しても認証しません、それはクライアントが彼のユーザー名とパスワード（秘密）を送信し、サーバーがそれらが正しいかどうかを決定するプレーンテキストプロトコルの改善にすぎません。
したがって、途中にパーティが存在する場合、それを検出したり、特定のセッションのクライアントになりすますことを防止したりすることはできませんが、シークレットがプレーンテキストで送信されることはないため、そのパーティはシークレットにアクセスできません。パーティーはリプレイを行うことによって再び偽装することはできません-それはまさにそのセッション中にのみ偽装して働くことができます。
于 2011-01-21T08:10:02.383 に答える