アプリケーション層の認証に関しては、既存のユーザーアカウントへの失敗したログイン試行を追跡するのが一般的です。ただし、存在しないユーザーアカウント(電子メールなどの公開識別子を使用して識別できないもの)のログイン試行の失敗を追跡する人を見たことはありません。
あなたはさまざまな種類の攻撃を見ています。既知のユーザーの失敗した試行のロギングは、特定のユーザーに対する攻撃です。定義上、一致するパスワードがないため、存在しないユーザーに対して失敗したログイン試行は常に失敗します。これは、ユーザーを列挙する試みを示している可能性があります。または、アプリケーションをプロファイルする試みを示している可能性があります。
上記のいくつかのフォローアップから、各エントリをログに記録したいようですが、ログがセキュリティ上の問題につながる可能性があることを懸念しています。たとえば、実際のユーザーがIDを誤って入力し、実際のパスワードを入力した場合、タイプされたパスワードまたはバリエーションを使用して、ユーザー名のバリエーションを使用して標的となる試み(誤ったユーザー名を使用して実際のユーザー名に到達しようとする試み)が発生する可能性があります。
ヒューリスティックを実行し、ブロックルールを作成するためにIPとユーザー名をログに記録することをお勧めします(一定期間IPをブロックしたり、CAPTCHAを要求したりするなどして、IPから総当たり攻撃をやめます)。ユーザー名とパスワードを組み合わせると、攻撃者の方法を特定するのに役立つ場合があります(たとえば、デフォルトのユーザー名XとデフォルトのパスワードYを持つアプリケーションバックエンドAを使用していると考えます)。ただし、通常は、攻撃をブロックして発信元を特定するためのアクションを実行します。ハッシュされていても、パスワードを記録することには、これらのパスワードまたはハッシュを分析することで得られる値よりも大きなリスクがあります。パスワードを知ることは、将来の攻撃をブロックするのに適したキーではないためです。ユーザー。
失敗したユーザーの試行をログに記録することの1つの欠点は、一部のユーザーがユーザー名フィールドにパスワードを入力して送信を押すことです。ばかげているように聞こえますが、それは懸念されるほど十分に起こっています。
これは、入力が速すぎる、パスワードマネージャー、またはその他の自動化された手段で発生する可能性があります。