ブルートフォース攻撃を回避するためのWebアプリケーションセキュリティ認証のベストプラクティス

Question

攻撃の可能性のあるケースをカバーしたいと思います。私のアプリケーションにはすでにキャプチャと2要素認証がありますが、ユーザーを煩わせることなく小さな攻撃を回避するにはどうすればよいですか？私がカバーしようと考えているケースは次のとおりです：

セッションに基づいて3回のログイン試行が失敗した後にキャプチャを表示しますが、問題は、何らかの理由でクリアできるため、ASP.NETセッションに基づくべきではないという関連記事があることです。
CAPTCHAの後に2要素認証を表示しますが、前のステップからの失敗したカウントに基づいて、CAPTCHAも表示する必要がありますか？それとも最初から数えるべきですか？
また、ユーザーのIPを一定期間ブロックすることを考えていますが、同じIPで作業している他のユーザーに影響を与える可能性があります。ハッカーが定期的にIPを変更するツールを持っている場合はどうなりますか？

これらのセキュリティ問題をカバーするための最善の方法は何ですか？

Nzall · Accepted Answer

ブルートフォース攻撃を軽減する比較的ユーザーフレンドリーな方法は、試行間の最小時間を遅らせることです。ユーザーが初めて間違った認証情報を入力したとき、1秒待ってから再試行できます。 2回目は、2秒間待機させます。 3回目は、4秒待つようにします。 4回目、8秒など。これは、IPアドレスではなく、認証に使用されるユーザー名にも基づいています。過去5分間試行がなかった場合（またはユーザーが正常に認証された場合）、カウンターをリセットします。

その結果、パスワードを打ち間違えたユーザーは最初の数回は影響を受けませんが、ブルートフォーサーは、ブルートフォースが事実上不可能になるポイントに非常に迅速に到達します。

ブルートフォース攻撃に対するWebアプリケーションの防止の他に、ハッシュとソルティング（できればPBKDF2またはbcryptを使用）、安全なパスワードのリセット、ユーザー名の列挙に対する緩和などの標準的なパスワード保護の実践も確認する必要があります。しかし、私はあなたがここに投稿したので、あなたはすでにそれを知っていると思います。

user42178 · Answer

ユーザーエクスペリエンスとセキュリティの適切な妥協点は、ユーザー名に関係なく、特定のIPからのログインが数回失敗した後にトリガーされるIPベースのキャプチャを使用することです。

このアプローチは、バックオフ時間が数時間/日に到達し、アカウントの正当な所有者がログインするのを防ぐまで、アカウントを総当たり攻撃することによる単一ユーザーに対するDoS攻撃に対して脆弱ではありません。
NATの後ろで立ち往生している人の数はそれほど多くはありません。アカウントを完全にDoSしてロックアウトする能力を攻撃者に与えるよりも、キャプチャの経験を少し低下させる方が良いです。正当な所有者。
これは、アプリの目的とセッションの存続期間の長さに依存しますが、それがStack Exchangeのようなものである場合、通常、ユーザーは頻繁にログインおよびログアウトしません。

不正なログインを追跡するためにセッションを使用することについてのあなたの懸念に関しては、それは正しいです、それは合法的なユーザーにとっては機能するので意味がありませんが、攻撃者はセッションCookieを保存することすらしません。キャプチャなしのセッションと新規ログインの試行。

IPの変更については、はい、それは少し問題ですが、IPは依然として攻撃者にとってコストであり、最終的にはボットネットのプロキシや侵害されたマシンが不足し、さらに購入する必要があります。また、IPがオープンプロキシデータベース（Googleで検索）またはTor出口ノードのリストにある場合は、常にキャプチャを要求する必要があります。そうすれば、攻撃者はこれらの「無料」のソリューションを使用できなくなり、ボットネットまたはまだブラックリストに含まれていない「プレミアム」プロキシをレンタルする必要があります。

Chris · Answer

私はブルートフォース攻撃の緩和に関するいくつかの調査を行っており、この投稿に出くわしました。私は最近、次のアプローチを実装しました：

24時間以内：単一のIPアドレスに対して20回以上失敗した認証試行では、後続の試行ごとにキャプチャを要求します。 100回失敗すると、リクエストをブラックホール化しますが、リクエストがブラックホール化されたことを示すものではなく、標準エラーメッセージを返し続けるだけです。

同じIPから大量のユーザーがログインすることを心配しておらず、しきい値は通常のユーザーが影響を受けない程度に十分高いと私たちは考えています。 100回失敗した場合、またはユーザー名が複数のIPアドレスに表示された場合にアラートを送信するのは簡単です。

すべてをデータベースに記録します。ボットネットは大量のIPを使用できることを認めますが、IPが認証に失敗したユーザー名をログに記録します。このテーブルは通常、1日に1回チェックされるため、1人のユーザーを対象とした大規模な総当たり攻撃を特定できる可能性があります。

また、最近、パスワード要件を強化して、文字の長さと複雑さを増すとともに、さまざまなパスワード辞書にあるパスワードを許可しません。 Googleのログインページはインデックスに登録されていません（robots.txtではなく、メタrobotsタグを使用してください。攻撃者はrobots.txtで興味深いページを確認できるためです）。最後に、管理者アカウントには2要素認証が必要です。

それでも、総当たり攻撃が可能であるというリスクを受け入れます。