ログインスロットリングと一時的なアカウントロックアウトの違いは何ですか？
現在、ログインページの再設計に取り組んでいます。私は最初に、ログインをスロットルすることを提案しました。これにより、失敗した各ログイン試行の間に一時停止（増分-秒数）が導入されます。これにより、アカウントのロックを回避し、ユーザーにパスワードのリセットについて考える時間を与え、ブルートフォース攻撃に対抗することができます。
開発チームは、ログインスロットリングはブルートフォース攻撃の防止には役立ちませんが、一時的なロックアウトは役立つことを示唆しました。一時的なロックアウトは、導入された一時停止が（増分-分と時間の数）であることを除いて同じように機能します。そのため、少し混乱しています...以下はIBM QuickFileでは、ログインを構成できます。
だから私はいくつかの質問があります：
一時的なロックアウトはログインスロットリングの別の用語ですか？
login throttling と temporary lockout の違いは何ですか？それらは同じですが、異なる構成パラメーターを使用していますか。たとえば、3-6-12秒vs 5-10-20分？
一時的なロックアウトメカニズムを採用するときに考慮する必要がある interaction design implications とは何ですか？いつ再試行できるかをユーザーに通知できますか？おそらく何らかの形の視覚的インジケータを使用していますか？
失敗したログイン試行の間の一時停止に最も適したタイムフレームは何ですかエンドユーザーを苛立たせませんか？ このstakoverflowに関する投稿は、分ではなく秒を示唆しているようです
Denial of Service にどのような影響がありますか？
更新：明確化
もう少し明確にします！ログインに失敗すると、「再試行」ボタンが無効になり、その後3秒間有効になります。ユーザーが再度ログインを試みて失敗すると、「再試行」ボタンは6秒間非アクティブになります。
このプロセスは5回連続して繰り返され、エラーメッセージによってユーザーはパスワードをリセットするように指示されます。5回目の試行では、ユーザーにパスワードリセット画面が表示されます。
一方、ユーザーはログインを試行し、指定された回数の試行が行われた後、一定期間アカウントが「ロック」されます。たとえば、5分間は、別の一連の試行の後、10分間に増加します。
ありがとう
A）そうだね。どちらもログイン試行の失敗が原因で発生するという点は同じですが、ロギング、結果としてのUX実装、および使用時などの点で異なります。
ユーザーが一時的にロックアウトされた場合、これはメールに値します。メールまたはテキストメッセージを送信して、一時的なロックアウトを保証するために十分な試行が失敗したことを通知する必要があります。これは、ユーザーがログインを試みていない場合にユーザーが介入できるようにする機会です。
または、数分でロックアウトタイマーを使用することもできますが、ユーザーがアカウントのロックを解除するアクションを要求する方が理想的です。
スロットルは、ペーシングに適しています。 「馬を止めて息をして」、ユーザーに通知することなく実行できます。シンプルなUIスピナー要素を使用して、ユーザーが誤って二重フォームを送信するのを防ぎ、数分や数時間ではなく、数秒で急激な試行を防ぐことができます。
これは、攻撃者がUIを通過していない場合にブルートフォース攻撃を検出する機会としても使用できます。 1秒あたり3回の試行が行われているが、UIが3秒ごとに1回しか試行できない場合、何かがおかしいです。
「スロットル」と「一時的なロックアウト」はまったく同じものです。
ただし、開発チームは概念を誤解しており、ここで他のほとんどの回答と同様に「スロットル」を意味していると想定している可能性があります（ただし @ R15 を除いて、それは回答ではありません）その他の重要な考慮事項）。
それらが欠けているという重要な点は単にこれです：
一時的なロックアウトの全体Raison d'être[〜＃〜] is [〜＃〜]ログインスロットル。
アカウントのロックアウトはユーザーを罰するものではありません。また、アカウントがロックされている間、すべての攻撃からアカウントにMagik Power of Immunityを自動的に付与するものでもありません。
一時的なロックアウトが機能する理由は、X回のログイン試行を行う最小時間を効果的に設定しているためです。
つまり、Y期間内のログイン試行の最大数。
例を挙げましょう：
ブルートフォース保護がない場合、攻撃者が1000パスワード/秒を試行できるとしましょう。 この古典的なXKCD によると、ほとんどの「複雑な」パスワードには最大28ビットのエントロピーがあります。 1000推測/秒の場合、総当たりするには約3日かかります。
ここで、ブルートフォース保護が設定されていると仮定します（スロットリング/アカウントロックアウト）：After X passwords, lock the account for Y amount of time。または、スロットリングと言います：Allow only X passwords every Y amount of time.
明らかにこれらは同じです... Yが30秒であるか30分であるかにかかわらず。 そして、どちらも機能します。
しかし、遊びをしましょう...
- 簡単にするために、上記のX = 10（間違ったパスワードを許可）、Y = 10分（ロックアウト時間）を設定します。そのレートで（実際には、物事を簡単にするために、平均して1分あたり1回の推測です）-（平均して）推測するのに500年ほどかかります。
- さて、パラメータを下げましょう... X = 5推測、Y = 30秒。同じパスワードを使用すると、50年以上かかります（平均して、スロットル率は1分あたり10推測です）。
- または、意図したように、X = 1はY = 10秒ごとに推測します（？）：1分あたり平均6回の推測では、パスワードをブルートフォースするのに約85年かかります...
もちろん、これらのパラメーターをシステムに合わせて調整できます。特に、@ R15が以前に言ったように、これはユーザーのパスワードの強度に関連しているはずです。
ただし、これは「アカウントロックアウト」と見なすか「アカウントスロットリング」と見なすかはまったく同じです。1つ目は2つ目を実現するための単純な実装にすぎないためです。
他に考慮すべきことの1つは、理論的には（スロットリングまたはロックアウトのいずれかによって課せられる）平均許容試行率は、ユーザーのパスワードの有効カバー時間に関連付けられるべきであるということです。
つまり、スロットル/ロックアウトは、ユーザーが次にパスワードを変更する前に、Webインターフェースを介したブルートフォース攻撃が成功するのを防ぐのに十分なはずです。
または、時間に関する決定がパスワードの複雑さと変更頻度に関連していると言い換えます。
もちろん、ログを監査している場合は、特定のアカウントに対する遅い攻撃を特定し、パスワードの推測が成功する可能性が生じる前に、それに対して何かを行うことができるはずです。
スロットルは、ロックアウトが選択できない場合に使用されます。これは特に、サポート操作（ユーザー数の多い新規スタートアップ）の関与を回避する必要がある場合に発生し、ビジネスの継続性、コンプライアンス、または安全上の理由よりもセキュリティを重視します（ロックアウトは誰かの安全を危険にさらす可能性があります）。
主な違いは、「アカウントロックアウト」はユーザーアカウントに基づいており、ログイン試行の抑制はクライアントごとの試行を制限することでも実行できることです。
クライアントごとのログイン試行のスロットルは、たとえば、1つの悪意のあるクライアントが特定のアカウントをターゲットにせず、試行のたびに（またはアカウントがロックされるまで）別のアカウント名を試行する場合に役立ちます。
アカウントごとにログイン試行を抑制する場合、それは基本的に一時的なロックアウトと同じです。