WebサイトまたはWebサービスに誤ったパスワード遅延を実装する必要がありますか？
引数が この答え で表されている場合、ユーザーが誤ったパスワードを入力してから実際に学習したときに、そのパスワードが正しくなかった場合、数秒の遅延があります。このセキュリティソリューションは オペレーティングシステム （ここでは基本OS）と Sudoのようなコンソールコマンドに実装されています。など
WebサイトまたはWebサービスに同じメカニズムを実装する必要がありますか？または、ブラウザとサーバー間で情報を交換する際の一般的な遅延は、ブルートフォース攻撃の増大をブロックするのに十分であると簡単に想定できます（ローカルシステムでも、サイトのLoginボタンを押すまでの間、1秒以上かかります。不正なパスワードが返されます;これは十分に長いと思われます）。
この件に関しては 同様の質問 があります。ただし、両方の回答（ this および this ）は私の質問を満たしていません、または少しずれたトピックですらあります。ログインに失敗するたびにユーザーaccountを一時停止または一時的にロックすることについては質問していません（したがって、実際のユーザーがログインできないようにする攻撃者のロックに関する引数はオフです） 。私はログインフォームを再度表示する間の可能な遅延についてのみ話しています。
失敗の遅延については、ブルートフォース攻撃を防ぐことが目的であると思います。攻撃者がユーザーのパスワードを推測しようとすると、最初に何度も失敗します。これらの失敗にかなり長い時間をかけることができる場合、攻撃を1桁難しくし、したがって（妥当な時間枠で）成功する可能性が低くなります。
しかしながら。
これは、攻撃者がログイン試行の間に辛抱強く待機することを前提としています。そして、誰もが知っているように、サイバーハッカーはとても丁寧で忍耐強い人々です。
とはいえ、一部の攻撃者は待機しないことを選択し、単純に多数の要求を並行して送信する場合があります。ログイン試行がすぐに応答を受信しない場合、攻撃者はそれを失敗した試行と解釈し、その要求を強制終了して、次の要求に進むことができます。
このスキームの追加の利点は、攻撃者がサーバーに不当な負荷をかけることがはるかに容易になることです（失敗したログイン要求を大量に送信するだけで、それぞれが数秒間スレッドを占有します...）。サーバーのDoSingにも成功します。
実際、このソリューションの主な問題は、多くの並列リクエストを正確に防止しないことです。攻撃者がオンラインのブルートフォース攻撃を試みている場合、ヒュージャックマンが可能な限り高速で多くのパスワードを次々と入力するキーボードの前に座るつもりはありません。ユーザーが単純なパスワードを使用すると危険にさらされます。
実際には、サーバーが処理できる数のリクエストを（ほぼ）スクリプトまたは自動化ツールで送信し、続行します。リスクは、誰かが1分間に30の異なるパスワードを試すことではなく、1分間に1000のパスワード、つまり10,000です。
onlyこれを防止する方法は、ユーザースロットル/アカウントロックアウト/インクリメンタルサスペンションです-これを何と呼んでも、これは基本的にX回のログイン試行を許可するという同じ考え方ですアカウントごと所定の期間内。
したがって、これは「一度に1回のログイン試行」に削減されませんが、十分に近づきます。
問題の一部は、遅延の期限が切れるまで接続を開いたままにしておくと、特に許可される同時接続の数がかなり少ない特定の一般的な構成で、貴重なリソースを使用することです。
理想的なソリューションは、次のようにシステムを構築することです。
まずロジックをUIに設計します。ログインに失敗するとすぐに失敗ステータスが返されますが、追加のログイン試行を許可するためにUIがリセットされるまでには遅延があります。これはenforceルールではなく、行儀の良いユーザーにエラーメッセージが表示されないようにするためです。
「クールダウン」期間中にログイン試行のエラーステータスをすぐに返すことにより、バックエンドにロジックを適用します。パスワードが正しいかどうかを確認することもせず、できるだけ少ないリソースを消費している間はすぐに失敗します。
ログインの試行がまだ許可されているかどうかをテストするための最良の解決策は、memcachedなどの軽量なものを使用することです。たとえば、特定のユーザー名での試行に失敗した後、クールダウンの期限が切れる時間をmemcachedに保存します。次に、新しいパスワードの試行を処理するときに、memcachedのエントリをチェックして、クールダウン期間がまだ経過しているかどうかを確認します。
ユーザー名ごとだけでなく、IPごとに同じロジックを適用します。ユーザー名をローテーションするだけで、1秒間に数千ものパスワードを推測することはできません。
指数バックオフを実装します。これは少し余分なクレジットですが、1秒に2回の試行は大した問題ではありませんが、5分間に50回の試行は大きな問題です。これは設計が少し難しいかもしれませんが、障害が繰り返されるとリセット時間が長くなります。これは、失敗のカウンターを（再びmemcachedに）保持し、そのカウンターの関数として次のクールオフを計算するのと同じくらい簡単です。ただし、既知のユーザーの資格情報を送信するだけで攻撃者がカウンターをリセットできないようにするため、IPごとのロジックは少し異なる必要があります。
自分自身でDoSすることを避けるために、サーバーができる限り少ない作業を行うようにします。アカウントロックアウトは、ユーザーのDoSingに最適です。
カウント（ユーザー名Uの認証の失敗）>しきい値の場合、解決されたCAPTCHAを要求
カウント（パスワードPの認証の失敗）>しきい値の場合、解決されたCAPTCHAを要求
cAPTCHAが嫌いなら、要求 Proof of Work
（クライアントに実数の素因数を計算させる）
従来の遅延はWebブラウザーベースの攻撃を軽減します。たとえば、誰かがphantomjsを使用してログイン試行を自動化する場合、通常の遅延（あなたの場合は「1秒以上」）はだれでもパスワードをブルートフォースにしようとするのを止めるのに十分です。時間がかかりすぎます。
ただし、ブルートフォース攻撃のほとんどはWebブラウザでは実行されず、同時に複数のリクエストを発行できるスクリプト環境で実行されます。
私がそれを実装する方法は、ログインに失敗した後、サーバー側で意図的に遅延させることと、スロットルメカニズム（ this のようなもの）とフロントエンドメッセージまたはスピナーをユーザーに通知することです資格情報がチェックされています（リロード用の空白ページまたはシステムが長い間時間ハングしているように見えます）