ユーザー テーブル 'failed_login_attempts' および 'failed_login_time' のいくつかの列を使用します。最初の値は、ログインに失敗するたびに増加し、ログインに成功するとリセットされます。2 つ目では、現在の時刻と前回の失敗時刻を比較できます。
コードはデータベース内のこのデータを使用して、ユーザーをロックアウトするまでの待機時間、許可されたログイン間の時間などを決定できます。
Google が必要なユーザビリティ テストを行い (不当な仮定ではありません)、 captchas を使用することを決定したと仮定すると、それらに従うことをお勧めします。
私が本物のユーザーであり、パスワードを忘れた場合、タイムアウトの増加はイライラします（特に私にとって非常に多くのWebサイトとそれに関連するパスワードが頻繁に発生します）
データベースに試行を保存することは、セキュリティ違反の試行の監査記録を提供するため、IMHO の最良のソリューションです。アプリケーションによっては、これが法的要件である場合とそうでない場合があります。
すべての不正な試行を記録することで、リクエストが 1 つの IP アドレスから送信されているかどうか (つまり、誰か/物がブルート フォース攻撃を試みているかどうか) などのより高いレベルの情報を収集して、IP アドレスをブロックすることができます。これは非常に役立つ情報です。
しきい値を決定したら、メールを自分のメールアドレスに送信するように強制しないでください（つまり、「パスワードを忘れました」のように）、またはCAPCHAアプローチを使用できます.
ヒットしているユーザー ID を把握し、フラグを保持し、しきい値に達したら、そのユーザーの受け入れを停止します。ただし、これは、ユーザーごとに追加のデータ値を保存することを意味します。
試行間隔が指数関数的に増加するという概念が気に入っています [...]
指数関数的に増加する時間を使用する代わりに、実際には、連続する試行の間にランダム化されたラグが発生する可能性があります。
使用しているテクノロジーを説明すると、ここにいる人がより具体的な例を手伝ってくれるかもしれません。
たとえば、3 回失敗してから 10 分後など、しばらくの間ログインをブロックすることができます。指数関数的に増加する時間は、私には良いと思います。はい、サーバー側のセッションまたはデータベースに情報を保存します。データベースの方が優れています。ユーザーが簡単に操作できるため、Cookie ビジネスはありません。
他の誰かが有効なユーザーのパスワードを推測しようとしている間に、有効なユーザーがブロックされたメッセージを受け取る可能性が十分にあるため、このような試行をクライアント IP アドレスに対してマップすることもできます。
サーバー側に情報を保存します。これにより、(複数のマシンからの) 分散攻撃に対する防御も可能になります。