ログインリクエストスロットリングの欠点は何ですか？

Question

Webアプリケーションで、パスワード推測攻撃から保護する1つの方法は、設定された回数のログイン失敗後にアカウントをロックアウトすることです。これは、送信元IPアドレスとユーザー名の両方で実行できます。

たとえば、次の表は、繰り返し試行が検出されたときに何が起こるかを示しています。システムは、5分間に5分間、ログインに3回失敗するとアカウントをロックするように設定されています。

IP Time Username Creds Correct? Message Given 203.0.113.1 10:00:00 foo@example.com N Bad username or password 203.0.113.1 10:00:01 foo@example.com N Bad username or password 203.0.113.1 10:00:02 bar@example.com N Bad username or password 203.0.113.2 10:00:03 foo@example.com N Bad username or password 203.0.113.1 10:00:04 foobar@example.com N Login locked from your location 203.0.113.2 10:00:05 foobar@example.com Y Welcome! 203.0.113.2 10:00:06 foo@example.com N Account locked 203.0.113.2 10:00:07 bar@example.com Y Welcome! 203.0.113.1 10:01:00 foobar@example.com Y Login locked from your location 203.0.113.1 10:05:03 foobar@example.com Y Welcome!

ログイン試行は、資格情報が検証されるときにのみカウントされます（プロセスは、資格情報を検証する前にロックアウトを最初に確認することです。ロックされている場合、資格情報は検証されません）。

以下からわかるように、悪意のあるユーザー（IP 203.0.113.3）は、意図的に誤ったパスワードを繰り返し推測することにより、アカウントをロックアウトし、サービス拒否を引き起こす可能性があります。

IP Time Username Creds Correct? Message Given 203.0.113.3 10:06:00 foo@example.com N Bad username or password 203.0.113.3 10:06:01 foo@example.com N Bad username or password 203.0.113.3 10:06:02 foo@example.com N Bad username or password 203.0.113.3 10:06:03 foo@example.com N Account locked 203.0.113.10 10:07:00 foo@example.com Y Account locked 203.0.113.10 10:07:04 foo@example.com Y Account locked 203.0.113.10 10:07:08 foo@example.com Y Account locked 203.0.113.10 10:07:15 foo@example.com Y Account locked 203.0.113.10 10:07:25 foo@example.com Y Account locked

...203.0.113.10の実際のユーザーがログインできないようにします。

これの代替手段は、HTTP応答を人為的に遅延させることです。最初に失敗したログインの遅延が1秒、2秒が3秒、3番目が4秒というように、合計で最大16秒になります。アカウントが攻撃されている場合、ユーザーはログインリクエストに対するHTTP応答を待つ間、ブラウザに回転する円が表示されます。

これには欠点がありますか？上記は、次のようになります（bcryptの反復により、デフォルトで1秒の遅延があるとします）。

IP Req Time Resp Time Username Creds Correct? Message Given 203.0.113.3 10:06:00 10:06:01 foo@example.com N Bad username or password 203.0.113.3 10:06:01 10:06:03 foo@example.com N Bad username or password 203.0.113.3 10:06:03 10:06:08 foo@example.com N Bad username or password 203.0.113.3 10:06:08 10:06:17 foo@example.com N Bad username or password 203.0.113.10 10:06:18 10:06:35 foo@example.com Y Welcome!

人工的な遅延（アクティブな場合）はスレッド間で発生することに注意してください。これは、攻撃者が単一のIPから要求をこれ以上高速に送信できないことを意味します。別のIPからのログインはキューに入れられませんが、ユーザー名の不正な試行によって構築された人為的な遅延は引き続き発生します。

ご覧のように、203.0.113.10のユーザーはアクセスを拒否されていません。攻撃者が攻撃を遅らせる一方で、ログインが完了するまで17秒間待つ必要があります。したがって、パスワード推測攻撃の防止に効果的です。

私の質問は、このアプローチの欠点は何ですか？そして、ユーザーにサービス拒否を引き起こす可能性のある包括的なロックアウトよりも、このタイプのアプローチをより頻繁に見ないのはなぜですか？

Chris Murray · Answer

攻撃シナリオを90度回転させること。単一のユーザーに対してパスワードのリストを使用する代わりに、ユーザーのリストに対して単一のパスワードを使用する攻撃者を考慮してください。私が（攻撃者として）どのアカウントにアクセスできるかを気にしていないと想像してください。単に任意のアカウント（たとえば、銀行口座）にアクセスしたいだけです。（失敗する可能性が高い）1人のユーザーをブルートフォースで強制する代わりに、以前に保持していたユーザーのリストに対して同じパスワード（一般的なもの、たとえば「CorrectHorseBatteryStaple」）を試します（ほとんどのサイトは電子メールを使用します）ユーザー名のアドレス。これは決して秘密にされていません）。

このシナリオでは、各ユーザー名に対して1回のヒットしか得られませんが、それでも私の試みを抑制しているはずです。提案されている防御策はどちらも、このシナリオをそのまま保護するものではありません。

防御は他の方法で集中する必要があります。ユーザー名に対するログイン試行を抑制するのではなく、IPアドレスに対する試みを抑制する必要があります。現在Googleがこれを行っていると思います。たとえば、アカウントをロックアウトした場合でも、通常のIPアドレス（つまり、攻撃者とは異なります）からログインできます。

SilverlightFox · Answer

このアプローチから私が見る欠点は次のとおりです。

特にスケーラブルなプラットフォームでは、クロススレッドを実装するのがより複雑です。
負荷分散されたサーバー間では効果がない場合があります。
ユーザーは我慢する必要があるかもしれません。

上記の理由により、広く実装されていません。

Steve Sether · Answer

なぜアカウントをロックするよりも実装が難しいのか、なぜ負荷分散rsが効果を持つのかはわかりません。どちらのアプローチでも、何をすべきか（ロックか遅延か）を一元的に調整する必要があります。

主な理由は、それが奇妙な動作であり、Webサイトが壊れているように見えることです（これは単に忍耐力ではないと思います）。遅延は一般的であり、人々は「ウェブサイトが壊れている」と考えるように訓練されています。これは通常、「ああ、間違ったパスワードを入力したためにログインが遅れるだけ」ではなく、非常に珍しいことです。言い換えれば、誰もがWebサイトの一般的な動作の規範によって、Webサイトの動作に何を期待するかについて訓練を受けます。

もう1つの理由は、実際には人々が単に異なるパスワードを再試行する可能性が限られていることです。サイトに10回ログインしようとして失敗した場合は、その時点でパスワードを忘れており、11回目、12回目、13回目の試行が役に立たない可能性があります。ほとんどの人は多分5-7で諦めるでしょう。つまり、その時点ではリセット時間であり、さらに17秒間待機しても攻撃者以外には何の役にも立ちません。

WoJ · Answer

ソリューションは、認証システム（AD、LDAPなど）にアクセスする場所がどの程度可変かによって異なります。

あなたが言及するアプリケーションは、認証サービスを使用する唯一のアプリケーションですか？

yesの場合：スロットルは正常に機能します。アプリケーションの速度が遅いことに驚いたユーザーがいるかもしれませんが（これはユーザーに知覚されます）、それほど重要ではないかもしれません（スロットルは非常に指数関数的であるべきです）最初の3〜5回の試行は時間的にほぼ同じであり、急な遅延曲線を挿入します）
notの場合：関係するすべてのシステムに対して同じ仮定を行う必要があります。これは、制御していないアプリケーションの一部が、言及した遅延メカニズムを備えていない可能性があることを意味する場合があります。これはまた、どのアプリケーションが認証メカニズムを使用するかを厳密に制御する必要があることも意味します（たとえば、すべてのDMZ環境としてDMZサービス）

アプリケーションの場合は、認証メカニズムにコーディングする必要がある（単純なままにする必要がある）か、ファイアウォールスロットリングに依存する必要があるため、スロットリングが嫌いです。これは、通常、さまざまな場所から認証サービスにクエリを実行するアプリケーションがたくさんあり、スロットルが実用的でも強制的でもないためです。その場合、ブルートフォース攻撃を受けやすいので、絶対に良いパスワードが必要です。