ほとんどの場合、問題は比較的簡単に解決されます。 ユーザーがパスワードを誤って数回入力した場合、アカウントはしばらくの間ブロックされます。 別の解決策は、キャプチャを表示することです。 すぐに、または複数回失敗した後。 まあ、ほとんど不死身である2F認証について忘れないでください。 それは思われる-利益！ しかし、すべてがそれほどバラ色ではありません...
解決策を説明した問題のいくつかを見てみましょう。
一時的なブロック -ユーザーアカウントは一時的にブロックされており、システムにアクセスできません。 攻撃中の実際のユーザーは、心痛と苦痛を経験します。 彼はシステムに入ることができません。 そして、ほとんどの場合、サポートがロードされます。 そして、最も興味深いのは、おそらくこれが攻撃者の目標であることです。
Captchaは比較的優れた効果的なソリューションです。 真実はユーザーにとって不便であり、そこに何かを追加で入力する必要があります。 デザインに組み込むのは非常に「不快」です。 そうそう...それでも、実装によっては、このことはDoS攻撃の対象になる可能性があります。
2F認証 -すべてが素晴らしいです。 本当です...ほとんどの場合、これはオプションです。 オンにすると、攻撃に対抗できなくなります。 彼女はそこにいるか、そうではありません。 そして、いくつかのリソースで、2Fの承認を入力します。たとえば、戦車からスズメを撃ちます。
便利で信頼できるサービスを作成しようとしています。 したがって、私は私の脳を少し緊張させることにしました。 そしてそれが起こったのです。
mail.ruなどのメールを使用していて、2F認証がインストールされている場合、最初のログイン時に新しい「デバイス」に対してのみ2F認証が要求されることに気づいたかもしれません。 さらに、デバイスは信頼できると見なされます。 そして、ログイン名とパスワードを入力するだけです。
便利なこと。 使いやすい、いわば。 これは2つのトークンによって実装されます。 最初の識別子は「デバイス」（devidとして定義）であり、2番目はセッション識別子（sessionとして定義）です。 Devidは、セッションとは異なり、ユーザーがセッションを終了した後でも関連性を失うことはありません。 次のログイン試行で送信され、ユーザー名/パスワードが正しく、devidが信頼されている場合、2Fは要求されなくなります。 ただし、次のログイン試行が失敗した場合、デビットトークンはすぐに無効になります。 そして今、あなたは認可の完全な道を行く必要があります。
このパラダイムは基礎として採用されました。 つまり もちろん、リクエストにない場合は、WEBリソースからの応答とともに、常に発行されるdevidトークンを入力してください。
認可ケース2Fの場合、上記のアルゴリズムが実際に実装されました。 そしてすぐに誰もが幸せになりました。 T.ch. 詳細に調べることは意味がありません。 しかし、「添えもの」については、説明とともに図を検討することをお勧めします。
2F認証がインストールされていなくても、ログインが成功した場合でも、devidトークンは信頼済みとしてマークされます。 2Fの許可なしにこれを行うことはほとんど意味がないように思われます。 しかし、すべては少し複雑です。 devidが信頼できることがわかっている場合、つまり 彼はログインに成功しました。少なくとも実際のユーザーが入ったのはこのデバイスからであると想定しています。 これは、説明したアルゴリズムが攻撃リフレクションモードでの作業で使用する非常に重要な情報です。
戦略が採用されました。有効なdevidトークンが存在する場合にのみ、許可が発生します。 有効なデビッドは、まだ信頼されていないという点で信頼できるものと異なります。 ログインに成功していませんが、システムはそれを使用して認証リクエストを処理する準備ができています。 試行回数は、有効なトークンごとにN回に制限されています。 承認エラーが連続してN回以上発生すると、トークンは「侵害された」とマークされます。 選択統計を含む別のジャーナルに転送されます。 彼の参加を伴うリクエストは引き続き処理されますが、...彼と一緒にログインすることはできなくなりました。 起こるのは、アクティビティ統計の蓄積だけです。
したがって、最も愚かな攻撃は反撃します。 たとえば、攻撃者がdevidを無視してシステムにログインしようとした場合、または攻撃者がdevidのロジックを理解できなかった場合（同じdevidで何回ログイン試行が行われたかをどのようにして知ることができますか？）、彼の要求は終了します。
自分のフロントは、あるデバイスからのログイン試行がN回失敗した後、すでに「腐敗」していることを知っています。 次のログイン試行の前に、新しいトークンを取得する必要があります。
どのような愚かさのように思えますか？ 入ろうとする試みを遂行するための前線...しかし、私が上で言ったように、すべてがトリッキーです。 ユーザーが標準的な方法で作業している場合、ユーザーが実際にシステムを攻撃しようとしている可能性は無視できます。 ユーザー登録中にパスワードの複雑さを制御するシステムとともに、これは完全に無駄です。 ほとんどの場合、実際のユーザーは本当に自分のパスワードを思い出そうとしています。
だから、トリックは何ですか？ 事実上、特定の時間制限を持つ非常に有効なデビットを生成します。 たとえば、1分あたり1000個以下です。 突然この制限を超えた場合、攻撃モードは切断されます。 そしてここでは、攻撃者の熱意を冷やすために、徹底的にデビッド放出をしばらく停止するか、有効なデビッドの生成を減らすことができます。 また、有効だが信頼されていないすべてのデバイスに対して同じキャプチャを有効にすることができます。
したがって、攻撃を制御および管理するための柔軟なシステムが得られます。 信頼性の高いメトリックが生成され、それによって監視がトリガーされ、アラームが発生します。 蓄積された統計は、ブロッキングルールなどに変換できます。
フレンドリーなシステムは、以前にログインしたユーザー、つまり 攻撃に気付かないでも信頼できるデバイスを提供しています。 それらはシステムによって問題なくスキップされます。
今利益。 このアルゴリズムは、非常に高い負荷のリソースで非常によく確立されています。 特に、アルゴリズム自体に対するDoSの試みがありましたが、ここでも価値があることが証明されました。