Webサイトでのブルートフォースログインの防止
最近の Twitterハイジャック および 辞書攻撃に関するJeffの投稿 への応答として、ブルートフォースログイン攻撃からWebサイトを保護するための最良の方法は何ですか？
Jeffの投稿では、ログインを試行するたびに遅延を増やすことを提案しています。コメントでの提案は、2回目の試行の失敗後にキャプチャを追加することです。
これらはどちらも良いアイデアのように思えますが、それが「試行回数」とは何かをどうやって知るのでしょうか。セッションID（攻撃者が毎回変更する可能性があるため）またはIPアドレス（より良いが、ボットネットに対して脆弱）に依存することはできません。ユーザー名に対してログを記録するだけで、delayメソッドを使用して、正当なユーザーをロックアウトできます（または、少なくともユーザーのログインプロセスが非常に遅くなります）。
考え？提案？
これを処理する唯一の方法は、特定のアカウントのデータベースに永続的な短いロックアウト期間（1〜5分）だと思います。データベース内の各useridには、timeOfLastFailedLoginとnumberOfFailedAttemptsが含まれています。いつ numbeOfFailedAttempts > X数分間ロックアウトします。
これは、問題のuseridをしばらくの間ロックしていることを意味しますが、永続的にはロックしていません。また、ログインを試行するたびにデータベースを更新していることも意味します（もちろん、ロックされていない場合）。これにより、他の問題が発生する可能性があります。
アジアには少なくとも1つの国全体がNATされているため、IPは何にも使用できません。
私の目にはいくつかの可能性があり、それぞれに短所と長所があります。
安全なパスワードの強制
- Pro：辞書攻撃を防ぎます
- Con：ほとんどのユーザーは複雑なパスワードを覚えることができないため、説明しても簡単に覚えることができるため、人気が失われます。たとえば、次の文を覚えておくと、「モールで5セントで1 Appleを購入しました」は「Ib1Af5CitM」になります。
数回の試行後のロックアウト
- Pro：自動テストの速度が低下します
- Con：サードパーティのユーザーをロックアウトするのは簡単です
- Con：データベース内で永続化すると、Twitterや同等のサービスなどの巨大なサービスで多くの書き込みプロセスが発生する可能性があります。
キャプチャ
- Pro：自動テストを妨げます
- Con：計算時間を消費しています
- Con：ユーザーエクスペリエンスを「遅く」します
- HUGE CON：バリアフリーではありません
簡単な知識チェック
- Pro：自動テストを防止します
- Con：「シンプル」は見る人の目にあります。
- Con：ユーザーエクスペリエンスを「遅く」します
別のログインとユーザー名
- Pro：これはほとんど見られないテクニックの1つですが、私の目にはブルートフォース攻撃を防ぐためのかなり良いスタートです。
- Con：2つの名前のユーザーの選択に依存します。
全文をパスワードとして使用する
- Pro：検索可能な可能性のあるスペースのサイズを増やします。
- Pro：ほとんどのユーザーにとって覚えやすいです。
- Con：ユーザーの選択によって異なります。
ご覧のとおり、「優れた」ソリューションはすべてユーザーの選択に依存します。これにより、ユーザーがチェーンの最も弱い要素であることがわかります。
他に何か提案はありますか？
あなたはグーグルがすることをすることができます。これは、一定回数試行した後、captachaが表示されます。 captachaを数回使用した後よりも、数分間ロックアウトします。
私は他のコメントのほとんどに同意する傾向があります：
- Xがパスワードの試行に失敗した後にロックする
- ユーザー名に対する失敗した試行をカウントします
- 必要に応じて、CAPTCHAを使用します（たとえば、試行1〜2は通常、試行3〜5はCAPTCHAで、それ以上の試行は15分間ブロックされます）。
- オプションで、アカウント所有者に電子メールを送信してブロックを削除します
私が指摘したかったのは、「強力な」パスワードを強制することには十分注意する必要があるということです。これは、多くの場合、パスワードが机の上のポストイットに書き込まれるか、モニターに添付されることを意味します。また、一部のパスワードポリシーは、more予測可能なパスワードにつながります。例えば：
パスワードを以前に使用したパスワードにすることができず、番号を含める必要がある場合は、その後に連続した番号が付いた一般的なパスワードになる可能性が高くなります。 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を読み取ることができず、[〜＃〜]可能性があります[〜＃〜]ボットが生成する迷惑な遅延の影響を受けます[〜＃〜] if [〜＃〜]自動ログイン機能を使用していません。
欠点ではありません。自動ログインCookieには、同様のセキュリティ対策が組み込まれていません。なぜこれが欠点ではないのですか？賢明に実装している限り、ログインCookieのセキュアトークン（パスワードに相当するもの）はパスワードの2倍のビット数（つまり、10倍のビット数になります！）であるため、ブルートフォース攻撃になります。事実上非問題。しかし、あなたが本当に妄想的であるなら、念のために、自動ログイン機能にも1秒の遅延を設定してください。
この目的のために、バックエンドデータベースに関連付けられたアプリケーションにキャッシュを実装する必要がありますnot。
何よりもまず、正当なユーザー名のみを遅らせると、有効な顧客ベースを「あきらめる」ことになります。これは、ユーザー名が厳重に保護された秘密でなくても、それ自体が問題になる可能性があります。
次に、アプリケーションによっては、データをDBに保存する場合よりも、アプリケーション固有の遅延対策を使用する方が少し賢くなります。
DOS状態をバックエンドデータベースにリークする高速試行に対して耐性があります。
最後に、IPに基づいていくつかの決定を下すことは許容されます... 1つのIPからの単一の試行が正直な間違いであるのに対して、神からの複数のIPは、他の予防策を講じるか、エンドユーザーに通知するシステムの数を知っています。日陰の活動。
その真の大規模なプロキシフェデレーションでは、使用するために大量のIPアドレスを予約できますが、一部のサイトにはCookieデータをIPに関連付ける習慣があるため、ほとんどの場合、レガシー目的で一定期間ソースアドレスを維持するために合理的な努力をします。
ほとんどの銀行と同じように、Xログインが失敗した後にユーザー名/アカウントをロックアウトします。ただし、アカウントのロックを解除するには電話をかける必要があるという点で、銀行ほど厳格ではありません。 1〜5分で一時的にロックアウトします。もちろん、Webアプリケーションは銀行と同じくらいデータに敏感です。 :)
ユーザー名を再度記録する必要があると思います。これが唯一の定数です（他のものはすべてなりすまし可能です）。そして、はい、それは正当なユーザーを1日締め出す可能性があります。しかし、ハッキングされたアカウントと閉鎖されたアカウント（1日）のどちらかを選択する必要がある場合は、間違いなくロックを選択しました。
ちなみに、（一定時間内に）3回失敗した後は、アカウントをロックして、所有者にリリースメールを送信できます。メールには、アカウントのロックを解除するためのリンクが含まれています。これはユーザーのわずかな負担ですが、クラッカーはブロックされています。また、メールアカウントがハッキングされた場合でも、1日あたりのロック解除回数に制限を設けることができます。
これは古い投稿です。ただし、将来の開発者に役立つように、ここに調査結果を入れることを考えました。
攻撃者がWebサイトのログインのユーザー名とパスワードを取得できないように、ブルートフォース攻撃を防ぐ必要があります。多くのシステムでは、認証に認証トークンやAPIキーを必要としないオープンエンドのURLがいくつかあります。これらのAPIのほとんどは重要です。例えば;サインアップ、ログイン、およびパスワードの忘れのAPIは、多くの場合開いています（つまり、認証トークンの検証は必要ありません）。サービスが悪用されないようにする必要があります。先に述べたように、ブルートフォース攻撃を効率的に防ぐ方法を研究している間、私はここに私の発見を置いています。
一般的な予防手法のほとんどは、この投稿ですでに説明されています。アカウントのロックとIPアドレスのロックに関する懸念を追加したいと思います。アカウントをロックすることは、防止策としては悪い考えだと思います。私は私の目的をサポートするためにここにいくつかのポイントを置いています。
アカウントのロックが悪い
- 攻撃者は、多数のアカウントをロックアウトすることにより、サービス拒否（DoS）を引き起こす可能性があります。
- 存在しないアカウントはロックアウトできないため、有効なアカウント名のみがロックアウトされます。攻撃者は、エラー応答に応じて、この事実を使用してサイトからユーザー名を収集する可能性があります。
- 攻撃者は、多くのアカウントをロックアウトし、ヘルプデスクにサポートコールを殺到させることで、迂回を引き起こす可能性があります。
- 攻撃者は、管理者がアカウントのロックを解除してから数秒後でも、同じアカウントを継続的にロックアウトして、アカウントを事実上無効にすることができます。
- アカウントのロックアウトは、1時間に数個のパスワードしか試行しない低速の攻撃に対しては効果がありません。
- アカウントのロックアウトは、多数のユーザー名に対して1つのパスワードを試す攻撃に対しては効果がありません。
- 攻撃者がユーザー名とパスワードの組み合わせリストを使用していて、最初の2、3回の試行で正しく推測している場合、アカウントのロックアウトは効果がありません。
- 管理者アカウントなどの強力なアカウントは、ロックアウトポリシーをバイパスすることがよくありますが、これらは攻撃するのに最も望ましいアカウントです。一部のシステムは、ネットワークベースのログインでのみ管理者アカウントをロックアウトします。
- アカウントをロックアウトした後も、攻撃が継続し、貴重な人的およびコンピューターリソースを消費する可能性があります。
- たとえば、複数の入札者が同じアイテムをめぐって争っているオークションサイトについて考えてみます。オークションのWebサイトでアカウントのロックアウトが強制された場合、1人の入札者は、オークションの最後の最後に他の入札者のアカウントをロックするだけで、落札を送信できなくなります。攻撃者は同じ手法を使用して、重要な金融取引や電子メール通信をブロックする可能性があります。
アカウントのIPアドレスロックも悪い考えです
別の解決策は、複数のログインに失敗したIPアドレスをロックアウトすることです。このソリューションの問題は、ISPまたは大企業が使用するプロキシサーバーをブロックすることにより、ユーザーの大規模なグループを誤ってブロックする可能性があることです。もう1つの問題は、多くのツールがプロキシリストを利用し、次のIPアドレスに移動する前に各IPアドレスからわずかな要求しか送信しないことです。 http://tools.rosinstrument.com/proxy/ などのWebサイトで広く利用可能なオープンプロキシリストを使用すると、攻撃者はIPブロックメカニズムを簡単に回避できます。ほとんどのサイトは、パスワードが1つ失敗しただけではブロックされないため、攻撃者はプロキシごとに2〜3回の試行を使用できます。 1,000個のプロキシのリストを持つ攻撃者は、ブロックされることなく2,000個または3,000個のパスワードを試みることができます。それにもかかわらず、この方法の弱点にもかかわらず、攻撃の数が多いWebサイト、特に成人向けWebサイトは、プロキシIPアドレスをブロックすることを選択します。
私の提案
- アカウントをロックしていません。代わりに、連続した間違った試行のログイン/サインアップ試行にサーバー側からの意図的な遅延を追加することを検討する場合があります。
- ログイン試行時のIPアドレスに基づいてユーザーの場所を追跡します。これはGoogleやFacebookで使用される一般的な手法です。 GoogleはOTPを送信しますが、Facebookは写真からユーザーの友達を検出するなどの他のセキュリティ上の課題を提供します。
- ウェブアプリケーション用のGoogleの再キャプチャ、Android）用のSafetyNet、およびiOS用の適切なモバイルアプリケーション認証技術-ログインまたはサインアップリクエスト。
- デバイスCookie
- 特定のAPIエンドポイントの異常な呼び出しを検出するためのAPI呼び出し監視システムの構築。
提案の説明
応答の意図的な遅延
攻撃の成功は時間に依存するため、パスワード認証の遅延は攻撃者の速度を大幅に低下させます。簡単な解決策は、パスワードを確認するときにランダムな一時停止を挿入することです。数秒の一時停止を追加しても、ほとんどの正当なユーザーが自分のアカウントにログインするときに煩わされることはありません。
遅延を追加するとシングルスレッド攻撃が遅くなる可能性がありますが、攻撃者が複数の同時認証要求を送信する場合は効果が低くなることに注意してください。
セキュリティの課題
この手法は、以前にシステムを使用する際にユーザーが実行したアクションに基づく適応型セキュリティの課題として説明できます。新規ユーザーの場合、この手法はデフォルトのセキュリティ上の課題を投げかける可能性があります。
セキュリティ上の課題をいつ投げるのかを検討するかもしれません。できる点がいくつかあります。
- ユーザーが以前近くにいなかった場所からログインしようとしたとき。
- ログインの試行が間違っています。
ユーザーが直面する可能性のあるセキュリティ上の課題は何ですか？
- ユーザーがセキュリティの質問を設定する場合、それらの回答をユーザーに尋ねることを検討する場合があります。
- Whatsapp、Viberなどのアプリケーションの場合、電話帳からランダムな連絡先名を取得して、それらの番号を入力するか、またはその逆を検討することがあります。
- トランザクションシステムの場合、最新のトランザクションと支払いについてユーザーに尋ねることを検討する場合があります。
API監視パネル
API呼び出しの監視パネルを構築します。
- API監視パネルで、ブルートフォース攻撃またはその他のアカウントの悪用を示す可能性のある条件を探します。
- 同じIPアドレスからの多くの失敗したログイン。
- 同じIPアドレスから複数のユーザー名でログインします。
- 多くの異なるIPアドレスからの単一アカウントへのログイン。
- 1回の使用による過剰な使用と帯域幅の消費。
- アルファベット順に並んだユーザー名またはパスワードからのログイン試行の失敗。
- Ownsyou（ownzyou）、washere（wazhere）、zealots、hacksyouなど、ハッカーが一般的に使用する疑わしいパスワードを使用したログイン。
内部システムアカウントの場合、特定のIPアドレスからのログインのみを許可することを検討する場合があります。アカウントを完全にロックアウトするのではなく、アカウントのロックを設定する必要がある場合は、機能が制限されたロックダウンモードにします。
ここにいくつかの良い読み物があります。
なんらかの形式のCAPTCHAテストを追加できます。しかし、それらのほとんどは、目や耳の障害のある人々へのアクセスをより困難にすることに注意してください。 CAPTCHAの興味深い形式は、質問をすることです。
2と2の合計は何ですか？
また、最後のログイン失敗を記録する場合、十分に古い場合はCAPTCHAをスキップできます。最後の障害が過去10分間であった場合にのみ、CAPTCHAテストを実行します。
私がオンラインでログインする多くのオンライン掲示板では、アカウントへのログインを5回試行しますが、5回試行した後、アカウントは1時間または15分間ロックされます。きれいではないかもしれませんが、これは確かに1つのアカウントでの辞書攻撃を遅くします。現在、複数のアカウントに対する辞書攻撃を同時に阻止するものは何もありません。つまり、5回試して、別のアカウントに切り替え、さらに5回試してから、元に戻します。しかし、それは確かに攻撃を遅くします。
辞書攻撃に対する最善の防御策は、パスワードが辞書にないことを確認することです!!!基本的に、辞書を文字と照合し、パスワードに数字または記号を要求する、ある種のパスワードポリシーを設定します。これはおそらく辞書攻撃に対する最善の防御策です。
古い投稿ですが、2016年の終わりに私が持っているものを投稿させてください。それでも役立つことを願っています。
簡単な方法ですが、ログイン攻撃を防ぐのに強力だと思います。少なくとも私はいつも私のすべてのウェブでそれを使用しています。 CAPTCHAやその他のサードパーティのプラグインは必要ありません。
ユーザーが初めてログインするとき。次のようなセッションを作成します
$_SESSION['loginFail'] = 10; // any number you prefer
ログインに成功すると、それを破棄してユーザーにログインさせます。
unset($_SESSION['loginFail']); // put it after create login session
しかし、ユーザーが失敗した場合、通常はエラーメッセージをユーザーに送信するため、同時にセッションを1つ減らします。
$_SESSION['loginFail']-- ; // reduce 1 for every error
また、ユーザーが10回失敗した場合は、他のWebサイトまたは任意のWebページに誘導します。
if (!isset($_SESSION['loginFail'])) {
if ($_SESSION['login_fail'] < 1 ) {
header('Location:https://google.com/'); // or any web page
exit();
}
}
このようにして、ユーザーは他のWebサイトにリダイレクトされたため、ログインページを開いたりアクセスしたりすることができなくなります。
ユーザーはブラウザを閉じて（作成したセッションloginFailを破棄するために）、ブラウザを「もう一度」開いて、ログインページを「もう一度」表示する必要があります。
役に立ちましたか？
.NET環境の場合
動的IP制限
IISの動的IP制限拡張機能は、インターネットプロトコル（IP）アドレスを一時的にブロックすることにより、ブルートフォースによるサービス拒否攻撃またはパスワードの解読を軽減またはブロックするのに役立つ構成可能なモジュールをITプロフェッショナルおよびホスティング業者に提供します。このような攻撃の1つを助長する可能性のあるパターンに従うHTTPクライアントの数。このモジュールは、分析とブロックをWebサーバーまたはWebサイトレベルで実行できるように構成できます。
悪意のあるIPアドレスからの要求を動的にブロックすることにより、サービス拒否攻撃の可能性を減らします
IISの動的IP制限により、要求の送信元IPを検査し、攻撃を示す可能性のあるパターンを特定することで、Webサーバーがサービス拒否攻撃を受ける可能性を減らすことができます。攻撃パターンが検出されると、モジュールは問題のあるIPを一時的な拒否リストに入れ、所定の時間、要求への応答を回避します。
Webサーバーのパスワードのブルートフォースクラッキングの可能性を最小限に抑えます
IISの動的IP制限は、Webサーバーのパスワードがデコードされようとしていることを示す要求パターンを検出できます。モジュールは、アクセスを拒否されたサーバーのリストに問題のあるIPを配置します。 Active Directory Services（ADS）に対して認証が行われる状況では、モジュールはADSに認証チャレンジを発行する必要をなくすことにより、Webサーバーの可用性を維持できます。
特徴
IIS 7.0Managerへのシームレスな統合。
次のいずれかの基準に基づいて、IPアドレスからの要求を動的にブロックします。
同時リクエストの数。
一定期間におけるリクエストの数。
動的IP制限フィルタリングのバイパスが許可されているIPのリストのサポート。
要求のブロックは、WebサイトまたはWebサーバーレベルで構成できます。
構成可能な拒否アクションにより、IT管理者はクライアントに返される応答を指定できます。モジュールは、戻りステータスコード403、404、または接続の終了をサポートします。
IPv6アドレスのサポート。
クライアントのIPアドレスを変更する可能性のあるプロキシまたはファイアウォールの背後にあるWebサーバーのサポート。
ブルートフォースを防ぐために考慮すべきいくつかの側面があります。与えられた側面を考慮してください。
パスワードの強さ
特定の条件を満たすためにユーザーにパスワードの作成を強制する
- パスワードには、大文字、小文字、数字、記号（特殊文字）を少なくとも1つ含める必要があります。
- パスワードには、基準に従って定義された最小の長さが必要です。
- パスワードには、ユーザー名またはパブリックユーザーIDを含めることはできません。
最小パスワード強度ポリシーを作成することにより、ブルートフォースはパスワードを推測するのに時間がかかります。その間、アプリはそのようなものを識別して移行できます。
reCaptcha
ReCaptchaを使用して、ブルートフォース機能を持つボットスクリプトを防ぐことができます。 WebアプリケーションにreCaptchaを実装するのはかなり簡単です。 Google reCaptcha を使用できます。 InvisiblereCaptchaやreCaptchav3などのreCaptchaにはいくつかの種類があります。
動的IPフィルタリングポリシー
リクエストのパターンを動的に識別し、パターンが攻撃ベクトルの基準に一致する場合はIPをブロックできます。ログイン試行をフィルタリングするための最も一般的な手法の1つは、
Throttlingです。詳細については、 phpを使用したスロットリングテクニック をお読みください。優れた動的IPフィルタリングポリシーは、DoSやDDosなどの攻撃からも保護します。ただし、DRDosを防ぐことはできません。CSRF防止メカニズム
csrfはcross-site request forgeryとして知られています。他のサイトがあなたのPHPスクリプト/コントローラーでフォームを送信していることを意味します。Laravelにはcsrfを防ぐためのかなり明確なアプローチがあります。ただし、このようなフレームワークを使用しない場合は、独自のJWTベースのcsrf防止メカニズムを設計する必要があります。サイトがCSRFで保護されている場合、Webサイトのどのフォームでもブルートフォースを起動する機会はありません。あなたが閉じた正門。