チャレンジを要求することによる攻撃チャレンジ/レスポンス認証
クライアント/サーバーアプリケーションが認証にチャレンジ/レスポンスパターンを使用する場合SCRAMなどでは、リプレイ攻撃を防ぐためにナンス（クライアントナンスとサーバーナンス）を使用することがよくあります。
サーバーは、クライアントのナンスと連結された安全でランダムに生成された数に基づいて、サーバーのナンスを生成します。 「古い」または「無効な」ナンスが受け入れられないことを保証するために、サーバーが最新の受信したクライアントナンスと発行されたサーバーナンスを保存しているとすると、攻撃ベクトルが開かれます。
攻撃者は、実際のクライアントが知らない有効で合意されたクライアント/サーバーナンスを新しい値で上書きするために、ユーザーが推測するユーザーIDに対して要求を総当たり攻撃する可能性があります。これが実際のクライアントのチャレンジとレスポンスの間に発生した場合、nonceは有効ではなくなるため、サーバーはアクセスを拒否します。これは、一種のサービス拒否攻撃になります。
チャレンジ/レスポンスが全体として正常に実行された場合にのみ、サーバーがストレージ内の実際に有効なサーバー/クライアントナンスのみを更新することを決定した場合、最新のチャレンジに応答していないユーザーのチャレンジリクエストを拒否する必要があります。これにより、攻撃ウィンドウも開かれます。攻撃は、ユーザーが最初にチャレンジを要求するのを防ぐために、（推測された）ユーザーにチャレンジを要求する可能性があります。
サーバーが未使用のナンスのリストを追跡すると仮定すると、両方の攻撃が防止されますが、これにより攻撃者が大量のチャレンジを要求する別の方法が開かれ、サーバーはそれらのナンスをすべてストレージに格納します。 I/O負荷を引き起こし、再びDoSにつながる可能性があります。
とにかく、私は現在、これらのDoS攻撃を防ぐためにサーバー側でナンス処理を安全に実装する方法を理解していません。現在、私はDoSを支持して、リプレイ攻撃に対する保護をトレードしていると感じています。
ファイアウォールなどでリクエストスロットリングを介してこれを防止する他の方法があることを知っていますが、可能であればチャレンジ/レスポンス実装レベルでこの問題を解決したいと思います。アイデアと回答をありがとう。
あなたが提起した2つの懸念は次のとおりです。
- サーバーのサーバーnonceのコピーは、パスワードを知らない攻撃者によって変更される可能性があります。
- サーバーのクライアントナンスのリストが無限に大きくなると、DoSで使用できます。
一般的な手法は、ナンスを時間制限することです。適切なMのためにM分間言う。
最初の問題では、ナンスを時間制限することにより、サーバーはクライアントとの複数の認証セッションを維持でき、それぞれが自身のナンスを追跡します。これらのセッションはM分後に自動的に削除されるため、サーバー上の大きなリソースの浪費ではありません。
2番目の問題は、時間制限クライアントナンスによって解決されます。これが機能するには、クライアントのナンスにタイムスタンプが含まれている必要があります。そうしないと、サーバーが期限切れのナンスを消去し、それによって使用済みナンスを「忘れる」ときに、タイムアウト後のリプレイ攻撃にさらされます。したがって、クライアントのナンスはtimestamp + secure random number。 nonceにタイムスタンプを含めることで、nonceがタイムアウト後に使用されないようにします。
Mの値を決定するときは、ネットワーク通信時間とサーバーとクライアント間のクロック差を処理するのに十分な大きさである必要があります。 Mは、リソース要件を十分に下げるのに十分な小ささである必要があります。 Mが1であったり、1未満であったりしても、認証プロセス中にユーザーの操作が必要ない場合は適切です。ユーザー入力が必要な場合は、より大きなMが必要になります。
十分なリソースを持つ攻撃者は、これが発生するまでのM分のウィンドウがまだあるため、DoSを実行できる可能性があります。ただし、これは小さなウィンドウであり、多くの攻撃者リソースを必要とします。つまり、これはDDoSであり、単純なDoSではありません。 DDoS攻撃の存続は、それ自体が問題です。