HTTPリクエストは、各リクエストのwhileプロトコルの再実行を回避するために、すばやく連続して受信される場合があります。サーバーnonceは、複数のリクエストに対してクライアントによって再利用される場合があります(nonceがクライアントリクエストが有効なウィンドウを決定するためのタイムスタンプ)。 。
この方法を使用することの長所と短所は何ですか?
HTTPリクエストは、各リクエストのwhileプロトコルの再実行を回避するために、すばやく連続して受信される場合があります。サーバーnonceは、複数のリクエストに対してクライアントによって再利用される場合があります(nonceがクライアントリクエストが有効なウィンドウを決定するためのタイムスタンプ)。 。
この方法を使用することの長所と短所は何ですか?
ナンスを再利用することの長所は、有効なナンスを維持およびチェックするために必要なリソースが少なくて済み、パイプライン化された要求の認証失敗を回避できることです。
[…]ナンスを生成およびチェックするために選択された方法には、パフォーマンスとリソースにも影響があります。たとえば、サーバーは、最近発行された各ナンスが返されたかどうかの記録を維持し、すべての応答のAuthentication-Infoヘッダーフィールドでnext-nonceディレクティブを送信することにより、各ナンス値の使用を1回だけ許可することを選択できます。これは、即時のリプレイ攻撃からも保護しますが、ナンス値をチェックするコストが高く、おそらくより重要なことは、パイプライン化された要求の認証失敗を引き起こします(おそらく古いナンス表示を返します)。
ただし、短所は、リプレイ攻撃が1回限りのナンスよりも可能性が高いことです。
リプレイ攻撃の可能性が許容されないアプリケーションの場合、サーバーは1回限りのnonce値を使用できますが、これは2回目の使用では受け入れられません。これには、nonceタイムスタンプ(したがって、それを使用して構築されたダイジェスト)が期限切れになるまで、どのnonce値が使用されたかをサーバーが記憶するオーバーヘッドが必要ですが、リプレイ攻撃から効果的に保護します。