ログイン試行の失敗をログに記録するとパスワードが公開されます

次のようなメッセージで、失敗したログイン試行をWebサイトに記録し始めました

Failed login attempt by qntmfred

これらのログの一部が次のように見えることに気づきました

Failed login attempt by qntmfredmypassword

ユーザー名フィールドにユーザー名とパスワードを入力したためにログインに失敗した人もいると思います。パスワードはデータベース内でハッシュ化されますが、何らかの理由でdbが危険にさらされた場合、これらのログメッセージは、攻撃者がこのようなログインに失敗する少数の人々のパスワードを把握する方法になる可能性があります。

これを処理するより良い方法はありますか？この可能性についても心配する必要がありますか？

このようにしてみてください：

ユーザー名が存在する場合、「ログインに失敗しました」を記録しますusername。そうでない場合は、123.45.67.89代わりに「IPによるログイン試行の失敗」を記録します。これで、誤ってパスワードがログに表示されるという問題に対処できます。

そのようなユーザー名がデータベースに存在するかどうかを単純にチェックしないのはなぜですか？これにより、2つの可能な結果が得られます。

1. ユーザーが正しいユーザー名を入力しました。これで、今記録した内容を簡単に記録できます。

2. ユーザーがユーザー名フィールドにパスワードを入力したため、ユーザー名が無効です。正体不明のユーザーによるログイン試行の失敗があったことを示すログエントリを入力するだけですか？

そしてもちろん、IP、日付などを記録するための追加フィールドを持つことができますか？

考慮事項：

1. ユーザー名の入力ミスとは対照的に、これが発生したことを検出できますか？入力ミスしたユーザー名を記録することは、サポートの目的で役立ちます。たとえば、「ログオンできない理由」という質問に「ユーザー名を間違えました。ドットではなくダッシュである」または「先頭にコロンがあります」空白-切り取って貼り付けてください」。少数の高価値の有料ユーザー（つまり、まだ別のソーシャルネットワーキングサイトではない）がいる場合は、おそらくこの種のサポートを提供する必要があります。

2. 誰かがこれを行うべき適切なアクションは何ですか？ユーザー名は、ハッキングの試みの指標になる場合があります。ユーザー名がリストに表示されないという事実は、それが何であるかを知る必要がないという意味ではありません。ただし、これが重大な懸念事項であると思われ、パスワードが誰であるかを検出できた場合、これが発生した後にユーザーにパスワードの変更を要求できます。

3. 業界の慣行とは何ですか？ 業界では、ユーザー名フィールドは記録しますが、パスワードフィールドは記録しません。あなたはこれを行うために解雇されることはほとんどありません。

通常とは異なる考慮事項がない限り、業界の慣習に従って、ユーザー名フィールドを記録することをお勧めします。不十分だと思われる場合は、提案2としてパスワードの強制変更を検討してください。

念のため、現在のアプリのログインでは、ログインメソッドまたはパスワードリセットメソッドに渡されるパラメーターは保存されません。ログ呼び出しにはこれを制御するオプションのパラメーターがあり、trueに設定すると、保存されているパラメーターオブジェクトがに置き換えられます[Redacted]。確かに、私は少しのデータを見逃しますが、私はそれらのIPアドレスを持っています。

この種のことを本当に記録したい場合は、ログイン試行を記録するときに、ユーザー名フィールドにある名前と一致する名前を持つユーザーのデータベースを確認し、一致する場合にのみ保存することをお勧めします。それ以外の場合は、単に「不明なユーザー」として保存します。この値に何かが含まれているかどうかを確認することもできますが、[User] [Password]と[UserPas] [sword]のような組み合わせを取得するリスクが常にあります。この場合、IPをチェックして、誰かのパスワードの開始を誤って平文で保存してしまった。これを可能性の低い[ユーザー] [パスワード]および[ユーザーパスワード] [??]に拡張することができます。この場合、「UserPasswordによるログイン失敗」に続いて「ユーザーによるログイン成功」が表示され、ユーザーのパスワードの。一般的に、安全のために、ログインが成功しない限り、ユーザー名を記録しないようにします。

追加して編集：

私の意見では、失敗したログイン試行のユーザー名を記録するために人々が投稿している引数のほとんどは、他の方法でより適切に処理されます。

たとえば、顧客が「なぜログオンできないのか？」と尋ねると、ログに記録されたユーザー名によってタイプミスを指摘できると言われています。これは事実ですが、パスワードを取得するリスクもありません。その代わりに、失敗時にユーザーをログインフォームにリダイレクトし、ユーザー名フィールドを強調表示し、入力した内容を再入力して、自分で確認できるようにします。

別の議論は、ハッキングの試みを特定できるということです。1つのユーザー名に対する一連の失敗は、パスワードを総当たりする試みである可能性があります。Usersテーブルに「BadLogins」列を設定して、このユーザーに一致するユーザー名でログインが失敗するたびに増加し、「成功した」ことをユーザーに通知した後、ログインが成功すると0にリセットされます。 x最後のログイン以降のログイン試行の失敗」および試行がそれらからのものであると思わない場合の対処方法についてアドバイスします。本当に徹底したい場合は、ログインに成功した後でもBadLogins列の最後の値を保存する別の列、および/またはこの列の史上最高の値を保存する列、および/またはこのアカウントが過去に失敗したログインの総数を保存します。