無効なユーザー名をログに記録する必要がありますか？
認証中に、無効なユーザー名での試行をログに記録する必要がありますか？ OWASPロギングチートシート は、認証の失敗を常にログに記録する必要があることを示しています。 Linuxのloginを含む、これを行ういくつかのプログラムを観察できます。
login[1234]: FAILED LOGIN 1 FROM tty2 FOR foo, Authentication failure
ユーザー名フィールドに誤ってパスワードを入力して、ログに記録されることがありました。 （ウェブ）アプリケーションは常に無効なユーザー名をログに記録する必要がありますか？認証システムが有効なユーザー名に対して無効な認証試行のみをログに記録するだけでは不十分なのはなぜですか？
はい。ただし、一方で、ログファイルにパスワードが含まれる可能性はありません。これは、誰かがログインを悪用し、ユーザー名ではなくパスワードを送信した場合に発生します。
私が実行可能な妥協かもしれないと思うのは、ログを取ることかもしれません：
- 有効なユーザー名と無効なパスワードで試行し、ユーザー名をログに記録しますが、パスワードはログに記録しません。
- 無効なユーザー名（パスワードなど）を使用して試行し、ユーザー名を「INVALID」としてログに記録します。
理論的根拠は、単一の有効なユーザー名を使用して数回試行すると、thatユーザー名に対するブルートフォースの可能性があることを通知することです。 INVALIDユーザー名に対する試みの群れは、大規模な「明らかなパスワードを持つユーザー名」攻撃を警告します。これは、適切なパスワードポリシーがある場合、苛立たしくは無害です。さらによく知られたユーザーに対する試み。
誰かが単一の無効なユーザー名をブルートフォースにしようとしている可能性があります。これが問題になる場合は、無効なユーザー名を（部分的またはソルト化された）ハッシュとして記録する可能性があります。この平文の情報の価値は、たとえ敵対的な政党によって捕らえられたとしても、本質的にはゼロです。
INVALIDユーザー名の試行回数が非常に少ないのは、ユーザーが自分の名前のスペルを間違えているか、名前の代わりにパスワードを入力しているためです。または、資格情報の取得を防ぐためにこれを信じて最初のログインを故意に妨害する偏執狂。
特に、同じアドレスからの有効なログインがすぐに続く場合（大規模なネットワークを装っているシステムでない限り...）、この種の認証エラーが時々発生すると、ノイズと見なされ無視されます。
（必要に応じて、info、admin *、Administrator、guestなどの「有効な無効な名前」の小さなセットをさらに区別することができます。しかし、それはおそらくやり過ぎです）。
また、本当に偏執狂の場合、すべての有効なユーザー名と文字列 "INVALID"を同じ固定長（たとえば... 20文字？）になるように埋め込むことができます。万が一、攻撃者がログファイルの増加をリモートで監視できる場合、ユーザー名がシステムに存在するかどうかを確認することはできません。
無効なユーザー名をログに記録する必要があります。
ユーザー名とパスワードのディクショナリを使用して、攻撃者がサービスに対してオンラインのブルートフォース攻撃を実行しているシナリオを考えます。攻撃者は、システム上の特定のアカウントに対して標的型攻撃を実行するのではなく、ランダムなユーザー名を試します。
無効なユーザー名をログに記録しない場合、ブルートフォース攻撃が気付かれない可能性があります。無効なユーザー名やIPアドレスなどの情報をログに記録すると、システムに対するブルートフォース攻撃を認識できる可能性が高くなり、適切なアクションを実行して攻撃を阻止できます。
無効なユーザー名の暗号化された値をログに記録できます。
誰かが複数のIPアドレスからブルートフォース攻撃を実行している場合、ログに記録されたユーザー名ではなく、Webサーバーのトラフィックを分析することで、IPアドレスを特定する必要があります。これはアプリケーション層で実行できます。 IPアドレスから異常な数のログイン要求を受け取った場合は、そのIPアドレスをブロックするだけです（適切と思われる期間）。そうしないと、ログに記録されたユーザー名/パスワードを見る機会が得られるずっと前に、Webサーバーが危険にさらされていることに気付く可能性があります。
ただし、正当なユーザーが誤ってユーザー名ボックスに自分のパスワードを入力したとします。未加工のテキストを保存すると、ログに記録されたsername（password）が侵入者によって読み取られます（侵入者が何らかの方法でデータファイルにアクセスしたと想定します）。あなたの目標は、この状況で侵入者がデータを読み取れないようにすることです。これが暗号化が便利になるときです。
DBMSを使用している場合、暗号化はデータベースシステムで実行できます。たとえば、ユーザー名を格納するテーブルや列を暗号化し、パスワードをハッシュ化できます。
この情報をCSVファイルなどに保存している場合、この暗号化はアプリケーションレイヤーで実行できます。公開鍵暗号を使用できれば、あなたの人生は簡単になります。アプリケーションは、公開鍵を使用して入力された値を単純に暗号化でき、あなた（または秘密鍵を知っている人）は、秘密鍵を使用して値を復号化できます-秘密鍵を安全に保つことはかなり簡単です。対称鍵暗号化を使用する必要がある場合、秘密鍵を安全に保管する方法がいくつかあります（オンラインで検索してください）。公開鍵暗号化を使用する場合ほど安全で簡単ではないかもしれませんが、生のテキストを保持するよりもはるかに優れていますよね？
目標は侵入を高価にすることであり、システムを100％免疫化することではないことを覚えておいてください...それは単に実用的ではないからです。
コメントとして提供されたmakerofthings7リンクをたどってください。そもそもそれを止める方法については多くの詳細がありましたが、すべての試みをログに記録する必要があります。
認証システムが有効なユーザー名に対して無効な認証試行のみをログに記録するだけでは不十分なのはなぜですか？
無効なログオン試行は、攻撃の可能性を示している可能性があります。有効なユーザー名でのみログに記録すると、攻撃のすべてが表示されないため、配布された場合の攻撃への対抗や、その他の有用な情報が得られる可能性があります。
まれに、ログが公開されている/アクセス可能な場合、攻撃者はこれを使用して有効/無効なユーザー名を列挙することができます（ログオンごとにA/Bテスト、ログが公開されている場合...）。
根本的な問題は、パスワードがログに記録される可能性があることです。これは、ユーザーがユーザー名フィールドにパスワードを入力したにもかかわらず、一部のコンテンツをパスワードフィールドに入力した場合にも発生する可能性が低くなります。
保存時に、ログ全体または少なくともユーザー名部分（または含まれるその他のPII）を暗号化するのが最善の場合があります。特定の値の暗号化が常に同じである場合、SIEMなどは引き続き相互に関連付けることができます。すべての無効な試行を保存することは良い考えであるため、暗号化を使用すると、パスワードの露出を制限することができます。
この問題は、ケースの定義に基づいており、分析の要件によって異なります。このことを考慮、
辞書の総当たり攻撃を使用する攻撃者。正当なユーザーをロックできます（考慮）、攻撃環境向けに設計された十分にソーシャルな辞書を保持しています。この攻撃では、アカウントロックアウトポリシーを悪用しています。
さて、上記のシナリオにはハニーポットシステム（脆弱なTelnetサービスを実行）があり、攻撃者が辞書を使用する方法について多くを学ぶことができます。辞書のユーザーが組織リストと一致する場合は、システム管理者にユーザー名を変更するよう警告することができます。
一部の数学や統計のように傾向を分析するのに役立ちます。たとえば、攻撃者は5分ごとに80％の試行が失敗した後に攻撃者が適切なユーザー名を攻撃していると言っています。この数値は、アクションの安全期間または猶予期間を与えます。