多要素認証を採用する場合、ログイン制限はまだ必要ですか？
現状では、一部の攻撃者が大量のIPアドレスを所有しているため、ほとんどのオンラインWebサイトは、IPアドレスごと、またはアカウントごとのログイン試行を制限しています。
ログイン制限を削除すると、攻撃者がIPアドレスまたはアカウントを問わず、正当なユーザーへのアクセス（ 可用性 ）を不正に拒否できなくなるという利点があります。 OWASP宣言 ：
多要素が実装されてアクティブになると、アカウントロックアウトが不要になる場合があります。
この声明はどのくらい本当ですか？それは、当社のWebサイトが必須の多要素認証（例 Google Authenticator ）を採用している場合、「IPアドレスのログイン制限」および「アカウントごとのログイン制限」メカニズムを安全に削除できることを意味しますか？
ログイン制限がない場合でも、多要素認証を介してブルートフォースを実行することは可能ですか？
ログインレート制限が適切に実装されている場合、欠点はなく、2FAの有無にかかわらず（実際には2FAの試行自体で）使用する必要があります。そして、 account lockout is notログインをレート制限する適切な方法です。
レート制限とは、特定のソースが実行できる試行回数を制限することを意味します。通常、これは特定のIPアドレスを意味しますが、「ソース」を定義することはできますが、状況によっては理にかなっています。
ここで防御しようとしている攻撃には、実際には3つのタイプがあります。
（a）攻撃者はパスワードを知っています-この場合、ロックアウトは少しでも役に立ちません。
（b）「123456」、「passw0rd」、「zxcvbn」のように、パスワードは簡単に推測されます。繰り返しますが、これらの攻撃者は、次のアカウントに移動する前に、最大で5または10を超えるパスワードを試行しないため、アカウントロックアウトは役に立ちません。多くの場合、1つだけ試してみます。 account ではなく、 attacker をブロックする必要があります。 （c）攻撃者は、1つの高価値のアカウントに断固たる道を歩み、辞書全体といくつかを試します。パスワードは簡単には推測できないかもしれませんが、攻撃者は1か月間持っています。
上記の条件（a）についてできることはあまりありませんが、2FAが役立ちます。条件（b）は非常に一般的ですが、（c）は、成功率が非常に低いため、少しまれです。しかし重要なことに、攻撃者の速度を遅くすることで両方を阻止できます。
理想的には、これが15のハード制限を意味するのではなく、10分間待機します。理想的には、指数バックオフを実行します。つまり、2回試行した後、数秒間待機します。 3番目以降は、少し長く待機します。そして、4番目以降も長くなります。制限はバックエンドで適用され、フロントエンドでは、JavaScriptのタイマーなどのクライアント側ロジックを使用して、ユーザーが待機期間中に試行を送信しないようにします。
このテクニックについてはここで何度か説明したので、詳細にはあまり触れません。しかし、重要なことは、構築が簡単で、正当なユーザーに著しく不便を感じさせないことですが、決定的な攻撃者に対して does は非常にうまく機能します。それらを遅くすることにより、特定のタイムスパンで何回試行できるかについてハード制限を効果的に設定しますが、試行間でその制限を段階的に実行します。さらに良いことに、待機期間中に試行を送信し続けているユーザーを検出できます。これにより、特別なソフトウェアを使用してクライアント側のレート制限を回避しているというフラグが立てられます。涼しい！
このように設定した場合、レート制限を無効にする理由はありません。実際の欠点はなく、ユーザーにはほとんど見えず、ブルートフォース攻撃者に対する合理的な最前線の防御を提供します。
これは、大きなボットネットからの単一のログインに対する分散型攻撃のシナリオのみを残します。これはほとんどのサイトで実際に発生することはほとんどありませんが、簡単に検出して対処できるので、読者への演習として残しておきます。
ユーザーベースの100％がすべてのログインで2FAを使用している場合、それほど重要ではない可能性がありますが、最低でも2FAの試行をレート制限する必要がある場合があります。一部のサービスは、SMSを介して送信された4桁のコードを5分のウィンドウでのみ使用します。この場合、攻撃者がコードをブルートフォースで攻撃する可能性があります。言い換えれば、おそらくレート制限が必要です- どこか安全性が低下するのを避けるため。
ただし、ログインと2FAの両方をレート制限することをお勧めします。
- 暗号化機能は通常、計算コストが高いため、攻撃者は大量の無効なログイン要求を実行することにより、DOS攻撃を仕掛ける可能性があります。
- ユーザーのデバイスが侵害されたのか、盗まれたのかはわかりません。攻撃者は、引き続きブルートフォース攻撃を試みる可能性があります。
- 通常、2FAはオプトインであるため、100％の登録が行われることはまれです。それ以外の場合は、2FAのないユーザーをレート制限する必要があります。
レート制限もお勧めします。物事から目を離さないほうがいい。
これがWiKIDサーバーで行うことです。サーバーは、（管理者が構成可能な）何度も不正なパスコードを試行した後、ユーザーをロックアウトしますが、数値以外のパスコードは無視します。これにより、ユーザーは単純なブルートフォース攻撃によってロックアウトされることはありませんが、コードを推測する誰かから保護されます。
数値以外のパスコードが試行されたことを示すログエントリを作成します。これらを確認して、攻撃者が有効な盗まれた資格情報を使用しているかどうかを確認することをお勧めします。
（時間ベースまたはトークンベースのトークンを構成して、特定の時間に複数のパスコードを有効にして、クロック/カウンタードリフトの再同期を可能にすることができます。）