brute forcingを防ぐために失敗したログインを記録するデータベースの設計

Question

ログイン試行の制限についていくつかの質問がありましたが、ログイン試行の記録の長所や短所、例えば、私が興味を持っていないCaptchas対スロットルの問題）。代わりに、私は、この情報をデータベースに記録するのに役立つがパフォーマンスにはあまり影響を与えない最良の方法を見つけようとしています。

アプローチ1）IPアドレス、試行したユーザー名、および試行時間を記録するテーブルを作成します。ユーザーがログインしようとすると、selectを実行して、最後の5分間にユーザー名が試行された回数（または特定のIPアドレスが過去5分間に何回試みられたか）を判断します。一定量以上の場合は、ログイン試行を抑制するか、キャプチャを表示してください。

これにより、ユーザ名とIPアドレスの両方に基づいた絞り込みが可能です（攻撃で複数のユーザ名が1つのパスワードで試されている場合）。また、監査の記録を簡単に作成できますが、ログイン試行ごとにINSERTが必要です。少なくとも1つの余分なSELECT。

アプローチ2）失敗した試行の回数と最後のログイン時間を記録する同様のテーブルを作成します。これにより、データベーステーブルが小さくなり、SELECTステートメントが高速になり（COUNTは必要ありません）、制御が少ししかなく、分析するデータも少なくなります。

アプローチ3）アプローチ2と同様ですが、この情報をユーザーテーブル自体に格納します。つまり、追加の、おそらく不要な情報をusers表に追加しますが、追加のSELECT文は必要ありません。また、アプローチ1が提供する余分な制御と情報も許可されません。

追加のアプローチ：mysql MEMORYテーブルまたはsqliteインメモリテーブルにログイン試行を保存します。これにより、ディスクのパフォーマンスによるパフォーマンスの低下は軽減されますが、依然としてデータベースの呼び出しが必要となり、データが永続的でないためログイン試行の長期監査ができなくなります。

これを行う良い方法や自分で実装したことについての考えはありますか？

Answer 1

時期尚早に最適化しているようです。

他の開発者が実装することを期待し、パフォーマンスを測定する方法で実装します。その時点で最適化が必要な場合は、測定に基づいていくつかの手順を実行します。

アプローチ1が最も自然な解決策であると思います。

サイドノート：私は、a）誰かがハッキングしているかどうかを判断し、b）どのような行動をとるべきかを決定するコードの部分をきれいに分けます。クエリを最適化するよりも、この部分が正しくなるようにいくつかの試みを行う可能性があります。

Answer 2

2つの余分な簡単なステートメントでは、目立った違いはありません。ログインはまれです - 比較的話しています。あなたが自動化されたログイン試行は、パフォーマンスの問題が発生しないことを確認したい場合は、ちょうど第二の閾値を持っている必要がどのあなたは

• タイムスタンプ虐待をした後
• カウント停止（したがって、挿入停止/更新）
• ipを数時間ブロックします。

このしきい値は、キャプチャを調整/導入するしきい値よりもはるかに高い必要があります。