最近のTwitter のハイジャックとJeff の Dictionary Attacks に関する投稿への回答として、ブルート フォース ログイン攻撃から Web サイトを保護する最善の方法は何ですか?
Jeff の投稿では、ログインを試行するたびに遅延を増やすことを提案しており、2 回目の試行に失敗した後にキャプチャを追加することをコメントで提案しています。
どちらも良いアイデアのように思えますが、「試行回数」をどうやって知るのでしょうか? セッション ID (攻撃者が毎回変更する可能性があるため) または IP アドレス (より優れていますが、ボットネットに対して脆弱です) に依存することはできません。ユーザー名に対してログを記録するだけで、遅延メソッドを使用して正当なユーザーをロックアウトできます (または、少なくともログイン プロセスが非常に遅くなります)。
考え？提案？
これを処理する唯一の方法は、特定のアカウントに対してデータベースが保持する短いロックアウト期間 (1 ～ 5 分) だと思います。useridデータベース内のそれぞれにはtimeOfLastFailedLoginとが含まれていますnumberOfFailedAttempts。numbeOfFailedAttempts > X数分間ロックアウトしたとき。
これはuserid、問題のロックをしばらくの間ロックしていることを意味しますが、永続的ではありません。また、ログイン試行ごとにデータベースを更新していることも意味します (もちろん、ロックされていない限り)。これにより、他の問題が発生する可能性があります。
アジアでは少なくとも 1 つの国全体が NAT されているため、IP は何にも使用できません。
私の目にはいくつかの可能性があり、それぞれに短所と長所があります。
ご覧のとおり、「優れた」ソリューションはすべてユーザーの選択に依存します。これにより、ユーザーがチェーンの最も弱い要素であることがわかります。
他に何か提案はありますか？
あなたはグーグルがすることをすることができた。これは、一定の試行回数の後、captachaが表示されます。captachaを数回使用した後よりも、数分間ロックアウトします。
私は他のコメントのほとんどに同意する傾向があります。
私が指摘したかったのは、「強力な」パスワードを強制することには細心の注意を払う必要があるということです。これは、多くの場合、机の上の付箋に書かれたり、モニターに取り付けられたりすることを意味するためです。また、一部のパスワード ポリシーは、より予測しやすいパスワードにつながります。例えば：
パスワードが以前に使用されたパスワードではなく、数字を含める必要がある場合は、その後に連番が続く一般的なパスワードである可能性が高くなります。6 か月ごとにパスワードを変更する必要があり、そのユーザーが 2 年間そこにいる場合、パスワードは password4 のようなものである可能性があります。
さらに制限するとします: 少なくとも 8 文字である必要があり、連続した文字を含めることはできず、文字、数字、および特殊文字を含める必要があります (これは、多くの人が安全だと考える実際のパスワード ポリシーです)。ジョン・クインシー・スミスのアカウントに侵入しようとしていますか? 3月6日生まれって知ってる？彼のパスワードはjqs0306 のようなものである可能性が高いです。(または多分jqs0306~ )。
ここで、ユーザーにパスワードpasswordを持たせることが良い考えだと言っているわけではありません。強制された「安全な」パスワードが安全だと思って冗談を言ってはいけません。
krosenvoldのコメント：ユーザーテーブルにnum_failed_loginsとlast_failed_timeを記録し（ユーザーが一時停止されている場合を除く）、失敗したログインの数がしきい値に達したら、ユーザーを30秒または1分間一時停止します。これがベストプラクティスです。
この方法は、単一アカウントのブルートフォース攻撃と辞書攻撃を効果的に排除します。ただし、攻撃者がユーザー名を切り替えることを防ぐことはできません。パスワードを固定し、多数のユーザー名で試してみてください。サイトに十分なユーザーがいる場合、その種の攻撃は、停止されていないアカウントが不足してヒットする前に、長期間継続することができます。うまくいけば、彼は単一のIPからこの攻撃を実行するので（ボットネットが最近実際に取引のツールになっているため、そうは思われません）、それを検出してIPをブロックできますが、攻撃を分散している場合は...さて、それは別の質問です（私はここに投稿したばかりなので、まだ投稿していない場合はチェックしてください）。
元のアイデアについて覚えておくべきもう1つのことは、アカウントが攻撃されて一時停止されている間でも、つまり、実際のユーザーとボットを区別できる場合でも、もちろん正当なユーザーを通過させようとする必要があるということです。
そして、少なくとも2つの方法でできます。
ユーザーが永続的なログイン（「rememberme」）Cookieを持っている場合は、通過させてください。
「ログインに失敗したため、アカウントが停止されました」というメッセージが表示されたら、「安全なバックアップログイン-HUMANS ONLY（ボット：嘘なし）」というリンクを含めてください。冗談はさておき、彼らがそのリンクをクリックしたときに、アカウントの一時停止ステータスをバイパスするreCAPTCHA認証済みのログインフォームを提供します。そうすれば、彼らが人間であり、正しいログイン+パスワードを知っている（そしてCAPTCHAを読み取ることができる）場合、彼らは遅延に悩まされることはなく、あなたのサイトは急速な攻撃の影響を受けません。
唯一の欠点：一部の人（視覚障害者など）はCAPTCHAを読み取ることができず、自動ログイン機能を使用していない場合でも、ボットによって生成される迷惑な遅延の影響を受ける可能性があります。
欠点ではありません。自動ログインCookieには、同様のセキュリティ対策が組み込まれていません。なぜこれが欠点ではないのですか？賢明に実装している限り、ログインCookieのセキュアトークン（同等のパスワード）はパスワードの2倍のビット数（つまり、10倍のビット数になります！）であるため、ブルートフォース攻撃になります。事実上問題ありません。ただし、本当に気が狂っている場合は、自動ログイン機能にも1秒の遅延を設定してください。
この目的のために、バックエンドデータベースに関連付けられていないアプリケーションにキャッシュを実装する必要があります。
何よりもまず、正当なユーザー名のみを遅らせると、有効な顧客ベースを「あきらめる」ことになります。これは、ユーザー名が厳重に保護された秘密でなくても、それ自体が問題になる可能性があります。
次に、アプリケーションによっては、データをDBに保存する場合よりも、アプリケーション固有の遅延対策を使用する方が少し賢くなります。
DOS状態をバックエンドデータベースにリークする高速試行に対して耐性があります。
最後に、IPに基づいていくつかの決定を下すことは許容されます... 1つのIPからの単一の試行が正直な間違いであるのに対して、神からの複数のIPは、他の予防策を講じるか、エンドユーザーに通知するシステムの数を知っています。日陰の活動。
その真の大規模なプロキシフェデレーションでは、使用するために大量のIPアドレスを予約できますが、一部のサイトではCookieデータをIPに関連付ける習慣があるため、ほとんどの場合、レガシー目的でソースアドレスを一定期間維持するために合理的な努力を払っています。
ほとんどの銀行と同じように、X ログインの失敗後にユーザー名/アカウントをロックアウトします。しかし、口座のロックを解除するには電話をかけなければならないという点で、私は銀行ほど厳格ではありません。1〜5分で一時的にロックします。当然のことながら、Web アプリケーションは銀行と同じくらいデータの機密性が高くなります。:)
ユーザー名を再度ログインする必要があると思います。これが唯一の定数です (他のものはすべて偽装できます)。はい、正当なユーザーを 1 日ロックアウトする可能性があります。しかし、ハッキングされたアカウントと閉鎖されたアカウント (1 日) のどちらかを選択する必要がある場合、私は間違いなくロックを選択しました。
ちなみに、3回失敗すると（一定時間内に）アカウントをロックして、所有者にリリースメールを送ることができます。メールには、アカウントのロックを解除するためのリンクが含まれています。これはユーザーに少し負担がかかりますが、クラッカーはブロックされます。また、メール アカウントがハッキングされた場合でも、1 日あたりのロック解除回数に制限を設けることができます。
なんらかの形式のCAPTCHAテストを追加できます。しかし、それらのほとんどは、目や耳の障害のある人々へのアクセスをより困難にすることに注意してください。CAPTCHAの興味深い形式は、質問をすることです。
2と2の合計は何ですか？
また、最後のログイン失敗を記録する場合、十分に古い場合はCAPTCHAをスキップできます。最後の障害が過去10分間であった場合にのみ、CAPTCHAテストを実行します。
私がオンラインでログインする多くのオンライン掲示板では、アカウントへのログインを5回試行しますが、5回試行した後、アカウントは1時間または15分間ロックされます。きれいではないかもしれませんが、これは確かに1つのアカウントに対する辞書攻撃を遅くします。現在、複数のアカウントに対する辞書攻撃を同時に阻止するものは何もありません。つまり、5回試行し、別のアカウントに切り替えて、さらに5回試行してから、元に戻します。しかし、それは確かに攻撃を遅くします。
辞書攻撃に対する最善の防御策は、パスワードが辞書にないことを確認することです!!! 基本的に、辞書を文字と照合し、パスワードに数字または記号を要求する、ある種のパスワードポリシーを設定します。これはおそらく辞書攻撃に対する最善の防御策です。
.NET 環境の場合
IIS 用の動的 IP 制限拡張機能は、IT プロフェッショナルおよびホスティング事業者に構成可能なモジュールを提供します。このモジュールは、サービス拒否攻撃またはブルート フォースによるパスワードのクラッキングを軽減またはブロックするのに役立ちます。パターンに従う HTTP クライアントのインターネット プロトコル (IP) アドレスを一時的にブロックします。そのような攻撃の 1 つを助長すること。このモジュールは、分析とブロックを Web サーバーまたは Web サイト レベルで実行できるように構成できます。
IIS の動的 IP 制限を使用すると、要求の送信元 IP を検査し、攻撃の兆候となる可能性のあるパターンを特定することで、Web サーバーがサービス拒否攻撃を受ける可能性を減らすことができます。攻撃パターンが検出されると、モジュールは問題のある IP を一時的な拒否リストに入れ、所定の時間、要求への応答を回避します。
IIS の動的 IP 制限は、Web サーバーのパスワードの解読が試みられていることを示す要求パターンを検出できます。モジュールは、所定の時間アクセスを拒否されたサーバーのリストに問題の IP を配置します。Active Directory サービス (ADS) に対して認証が行われる状況では、モジュールは ADS に認証チャレンジを発行する必要がないようにすることで、Web サーバーの可用性を維持できます。
IIS 7.0 マネージャーへのシームレスな統合。
次の基準のいずれかに基づいて、IP アドレスからの要求を動的にブロックします。
同時リクエスト数。
一定期間のリクエスト数。
動的 IP 制限フィルタリングをバイパスできる IP リストのサポート。
要求のブロックは、Web サイトまたは Web サーバー レベルで構成できます。
構成可能な拒否アクションにより、IT 管理者はクライアントに返される応答を指定できます。モジュールは、戻りステータス コード 403、404、または接続の終了をサポートします。
IPv6 アドレスのサポート。
クライアント IP アドレスを変更する可能性があるプロキシまたはファイアウォールの背後にある Web サーバーのサポート。