クライアントノンスの使用は何ですか？
ロスアンダーソンの本のパートIセキュリティエンジニアリングを読み、ウィキペディアのいくつかのトピックを明確にした後、クライアントナンス（cnonce）のアイデアに出会いました。ロスは彼の本でそれについて決して言及していません、そして私はそれがユーザー認証で役立つ目的を理解するのに苦労しています。
通常のナンスは、期限切れの応答を使用して特権を取得することを含むリプレイ攻撃を回避するために使用されます。サーバーは、クライアントに応答をハッシュするために強制的に使用されるノンス（Number used ONCE）をクライアントに提供し、サーバーは提供されたノンスを使用して期待する応答をハッシュし、クライアントのハッシュがその後、サーバーはリクエストが有効で最新であることを確認できます。これが検証するすべてです。 有効で新鮮です。
ただし、クライアントナンスについて私が見つけた説明は、単純明快ではなく、疑わしいものです。ここでのStackoverflowのデジタルアクセス認証といくつかの応答のWikipediaページは、選択された平文攻撃を回避するためにクライアントナンスが使用されることを示唆しているようです。このアイデアにはいくつか問題があります。
- 人がパケットを傍受して挿入できる場合、最大の脆弱性は、nonceもcnonceも克服できない中間者攻撃であり、したがって両方を無意味にします。
- 攻撃者がman-in-the-middle攻撃をしたくなく、認証の詳細を回復したいとしていると仮定すると、どのようにしてcnonceは追加の保護を提供しますか？攻撃者が通信を傍受し、独自のナンスを使用して要求に応答する場合、クライアントからの応答は、暗号化されていない形式の番号に加えて、ナンス、データ、および番号のハッシュになります。これで、攻撃者はnonce、cnonce、およびハッシュにアクセスできます。攻撃者は、レインステーブルをノンスとノンスでハッシュして、一致を見つけることができます。したがって、クライアントは追加の保護を提供しません。
では、cnonceの目的は何ですか？
理解していない部分があると思いますが、その部分の説明はまだわかりません。
[〜＃〜] edit [〜＃〜]いくつかの回答は、クライアントがナンスを提供でき、同じ目的を果たすことを示唆しています。これはチャレンジ/レスポンスモデルを壊しますが、これの意味は何ですか？
nonceは、プロトコル内のエンティティによって選択される一意の値であり、非常に大きな「リプレイ」の範疇に入る攻撃からそのエンティティを保護するために使用されます。
たとえば、次のようなパスワードベースの認証プロトコルについて考えてみます。
- サーバーは「チャレンジ」（おそらくランダムな値c）をクライアントに送信します
- クライアントはh（c || p）を送信して応答する必要があります。ここでhは安全なハッシュ関数です（例：SHA-256）、-pはユーザーパスワード、および ''は連結を示します
- サーバーは独自のデータベースでパスワードを検索し、予想されるクライアント応答を再計算して、クライアントが送信したものと一致するかどうかを確認します
パスワードは人間の脳に合う秘密の値です。そのため、それらは非常に複雑にすることはできず、高い確率でユーザーパスワードを含む大きな辞書を作成することが可能です。 「大きな」とは、「数週間で中規模のクラスターで列挙できる」という意味です。現在の議論では、攻撃者が数週間の計算を費やすことで単一のパスワードを解読できることを受け入れます。これは、達成したいセキュリティレベルです。
パッシブ攻撃者を想像してみてください。攻撃者は盗聴しますが、メッセージを変更しません。彼はcとh（c || p）を見ているため、クラスターを使用して、一致するものが見つかるまで潜在的なパスワードを列挙できます。これは彼にとって高価になるでしょう。攻撃者がtwoパスワードを攻撃したい場合、攻撃者はtwiceの仕事をしなければなりません。攻撃者したい事前計算されたテーブルを使用して2つの攻撃インスタンス間で少しコストを共有する（ "Rainbowテーブル"は、最適化されたストレージを備えた事前計算されたテーブルの一種です。ただし、Rainbowテーブルを作成するには、完全な辞書を列挙し、各パスワードをハッシュする必要があります）。ただし、ランダムチャレンジは攻撃者を破ります。各インスタンスには新しいチャレンジが含まれるため、同じパスワードが使用されている場合でも、ハッシュ関数の入力はセッションごとに異なります。したがって、攻撃者は有用な事前計算済みテーブル、特にRainbowテーブルを作成できません。
次に、攻撃者がアクティブになったとします。メッセージを単に観察する代わりに、メッセージを積極的に変更したり、一部をドロップしたり、他のメッセージを複製したり、独自のメッセージを挿入したりします。攻撃者は、クライアントからの接続試行を傍受できるようになりました。攻撃者は自分のチャレンジを選択して送信し（c '）、クライアントの応答を待ちます（h（c' || p））。真のサーバーにはアクセスしないことに注意してください。悪意のあるネットワークエラーをシミュレートするために、攻撃者はクライアント応答の直後に接続を突然ドロップします。この攻撃モデルでは、攻撃者は大幅な改善を加えました。攻撃者はまだチャレンジc 'とそれに対応する応答を持っていますが、チャレンジは攻撃者が適切と判断した値です。攻撃者が行うことは、常に同じチャレンジc 'に対処することです。毎回同じチャレンジを使用すると、攻撃者は事前計算を実行できます。特別な「チャレンジ」を使用する事前計算されたテーブル（つまり、レインボーテーブル）を構築できます。これで攻撃者は、それぞれの辞書列挙コストを発生させることなく、いくつかの異なるパスワードを攻撃できます。
A client nonceはこの問題を回避します。プロトコルは次のようになります。
- サーバーがランダムなチャレンジを送信c
- クライアントはノンスを選択しますn（毎回異なる必要があります）
- クライアントはn ||を送信しますh（c || n || p）
- サーバーはh（c || n || p）を再計算し（データベースのpを使用）、この値がクライアントが送信したものと一致するかどうかを確認します
クライアントは各セッションのハッシュ関数入力に新しいランダム値（「ノンス」）を含めるため、攻撃者がチャレンジを選択できる場合でも、ハッシュ関数入力は毎回異なります。これにより、事前計算された（Rainbow）テーブルが無効になり、意図したセキュリティレベルが復元されます。
ユニークなナンスの大まかなエミュレーションはユーザー名です。同じシステム内の2人の異なるユーザーは、異なる名前を持ちます。ただし、ユーザーはパスワードを変更しても名前を保持します。 2人の異なるユーザーが2つの異なるシステムで同じ名前を持つ場合があります（たとえば、すべてのUnixライクなシステムには「root」ユーザーがいます）。したがって、ユーザー名は適切なナンスではありません（ただし、クライアントナンスをまったく持たないよりはましです）。
要約すると、クライアントnonceは、クライアントをリプレイ攻撃から保護することです（「サーバー」は実際には攻撃者であり、攻撃したいすべてのクライアントに同じチャレンジを送信します）。強力なサーバー認証（SSLなど）を含むチャネルを介してチャレンジが実行される場合、これは必要ありません。 Password Authenticated Key Exchange は、事前の信頼（SSLクライアントがSSLサーバー証明書を認証するときの「ルート証明書」）と保護を必要とせずに、クライアントとサーバー間の相互パスワードベース認証を保証する高度なプロトコルです。アクティブおよびパッシブの攻撃者（単一のパスワードに対する「2週間のクラスター」攻撃を含む。これは、上記のプロトコルよりも厳密に優れており、ノンスまたはノンスです）。
あなたの質問の要点に答えてみましょう：「攻撃者が中間者攻撃に従事することを望まず、認証の詳細を回復することを1秒間想定すると、どのようにconnceは追加を提供しますか？保護？"
通常、クライアントはリクエストにnonceをincludesするだけでなく、signsリクエスト全体nonceを含む。つまり、攻撃者がクライアントとサーバー間のメッセージを傍受したとしても、
- リプレイ攻撃は機能しません（サーバーがクライアントのナンスを追跡しているため）。
- 攻撃者はsignの方法がわからないため、newクライアントナンスで新しいメッセージを生成することはできません。新しいメッセージを適切に（つまり、クライアントシークレット、または秘密鍵を欠いている）。
RFC 2617 によると、cnonceおよびncパラメータは、選択された平文攻撃から保護します。これはどのようにしてそのような攻撃から保護しますか？
イブがナンスを変更した場合、サーバーはクライアントに送信します。イブは何を獲得したのですか？ Eveはh(password || nonce)からh(password || fake_nonce)を生成できません。理論的には、サーバーは発行されたnonceが何であるかを認識している必要があるため、サーバーはh(password || fake_nonce)を受け入れるべきではないようですナンスはそうではありません。
Oauth のようなものでnonce値がどのように使用されるかについて読むことは良い考えだと思います。つまり、OAuthを使用するアプリケーションがOAuth対応のサーバーにリクエストを行う場合、そのリクエストには、タイムスタンプとノンスの2つのフィールドの束が含まれている必要があります。フォームの目的明白です：メッセージが古くなっているかどうかについてサーバーがより正確に推測できるように、メッセージが送信された時間枠を示します。後者は明らかにランダムな文字/バイトの束です。
OAuthヘッダー全体がコンシューマシークレットでハッシュされると、これらのフィールドの両方が含まれます。次に、は署名をリクエストに追加し（クエリパラメータであれHTTPヘッダーであっても）、送信されますリクエストの実際のbodyはハッシュされません。
OAuthサーバーは、特定のクライアントの以前のN個のnonce値のセットを追跡して、それらが再利用されていないことを確認する必要があります。メッセージの本文が変更される可能性がある（基本的にハッシュへの影響）リクエストが一意であることを確認するために、変更される何か（つまり、nonce）を持つことが重要です。HTTPのオープン/プレーンテキストの性質を考えると、これはかなり重要です。
これは目的を明確にするのに役立ちますか？ （そう願っています:)）。