3-Strike Securityの弱点

私はセキュリティ、特にパスワードセキュリティ/暗号化に関するいくつかの文献を読んでいて、疑問に思っていることが1つあります。3ストライクルールは、パスワードセキュリティの完璧なソリューションですか？つまり、パスワードの試行回数がいくつかの限られた数に制限されている場合、すべての認証要求が受け入れられなくなると、ユーザーの侵入を防ぐことができませんか？何かへのアクセスや制御を得ることは、常に認証システムを通過することを意味するわけではありませんが、この機能は辞書/総当たり攻撃を時代遅れにしないのですか？行方不明のものはありますか？

はい、ログインメカニズムを通じて辞書攻撃を不可能にします。（ただし、データベースへのアクセスを取得してもそれほど意味はありません。セキュリティを確保するために、パスワードを適切にハッシュおよびソルトする必要があります。）

また、特定のユーザーに対するDOS攻撃の可能性もあります。ログインを禁止したいとしましょう。アカウントに対して偽のログイン試行を3回実行し、ログインをリセットするために必要なことをするたびに、もう一度実行する必要があります。その問題への対処は少しトリッキーです。

また、適切な権限なしにアカウントへのアクセスを取得する方法として、辞書攻撃の効果が低下することにも同意します。しかしながら：

• このアプローチは、適切に実装されていないと、辞書攻撃をシステムに対するDOS攻撃に変えて、アクセスを妨げる可能性があります。たとえば、サーバーが認証試行で溢れる可能性があります。これを回避する1つの方法は、ロックアウトされたアカウントへの以降のアクセスのフローを認証サービスに制御させることです。たとえば、アカウントがロックアウトされている場合、後続の各ログイン試行の前に遅延を提示します。しかし、ログイン試行と「アクセス拒否」の間に遅延を設けることもできますが、これにより、攻撃者が多数の同時認証試行を開始する分散型サービス拒否攻撃への扉が開かれたままになります。

• 他の回答で述べたように、これは、攻撃されているアカウントの正当な所有者に対する辞書攻撃を粗雑なDOSに変える可能性もあります。正当な所有者への影響を緩和する方法は次のとおりです。

  • ユーザー名とパスワードのどちらが間違っているかについての手掛かりを提供しないことにより、ユーザー名に対する実行を遅くします。これにより、犯人がユーザー名を推測している攻撃は、管理者に見えやすくなり、効果が低下します。
  • 試行が一定回数失敗した後でアカウントをロックダウンする代わりに、その認証モードをロックアウトするだけです。言い換えると、アカウントが攻撃されているユーザーに、別の（おそらくより複雑で攻撃されにくい）メソッドを使用して認証を要求することです。良い例は、画面ロック解除パターンまたはPINを使用して認証に失敗した後、AndroidスマートフォンでユーザーがGoogleログイン情報を使用する必要がある方法です。理論的には、これは攻撃されたユーザーがアカウントのロック解除を要求することを要求するようなものですが、システム管理者からの即時の介入を必要としません。
  • アカウントをロックダウンする代わりに（または、アカウントのロックダウンに加えて、この特定の認証モード（上記を参照）の場合）、攻撃が発生している場所から認証を試みます。たとえば、ネットワーク経由でユーザー名とパスワードを使用して認証を行う場合、3回認証に失敗した後、同じIPまたはサブネットからのユーザーがユーザー名またはパスワードでログインできないようにすることができます。複数のユーザー（攻撃者を含む）が同じIPまたはサブネットを使用している可能性が高い場合、IPまたはサブネットのユーザー名/パスワード認証を一定期間無効にして、より複雑な認証方法を無害に残しておくことができます。攻撃者の近くにいるユーザー。

• 忘れがちなユーザーを不注意に攻撃者のように不注意にペナルティを課す場合、一定回数の失敗したログイン試行のフローを制御する代わりに、アカウントが攻撃されている証拠としてログイン試行の頻度を使用できます。たとえば、1秒の間に10回の認証試行があった場合、上記の方法のいずれかを使用して、同様の認証試行をさらに防ぐことができます。代わりに、フローの制御を開始するシグナルとして、このログイン試行の急激なフラッドを使用できます。この方法は、フォーラムでますます人気が高まっていますが、特定のIPからのログイン試行が一定の回数失敗すると、そのIPは短時間認証されなくなります。

• 最後に、ユーザーが繰り返しDOS攻撃の標的となるのを防ぐ良い方法は、ユーザーにパスワードとユーザー名の両方をリセットさせることです。つまり、ユーザー名とパスワードの両方をシークレットとして扱います。ユーザー名が他の場所で使用されている場合（たとえば、ユーザー名がユーザーの表示名である場合、フォーラム内）、この表示名を別のものとして扱います。このアプローチは通常、認証で使用されるユーザー名が自分の電子メールアドレスであるソーシャルネットワークで使用されます-変更できるが、ほとんど共有されません-サイトで使用される表示名はユーザー定義のものであり、ユーザー定義ではない場合があります変更されます。

とにかく、これらのアプローチの1つまたはいくつかの組み合わせが役立つことを願っています。