ユーザー名フィールドへのユーザーの入力ミスにより、パスワードがクリアテキストで送信される
さまざまなSIEM（Splunk、HP Logger Trial、およびAlienVaultプラットフォームのSIEM）によって生成されたログを確認したところ、何らかの理由で、かなりの数のユーザーが、OSドメインログオンのユーザー名フィールドにパスワードを入力する間違いを犯す傾向があることに気付きました、またはWebアプリケーション内。私は、キーボードを見ずに入力することができず、そうしようとすると速く入力して、間違ったフィールドにパスワードを入力してしまう人がいると思います。これは、パスワードがネットワーク内のすべての場所でプレーンテキストで送信され、最終的にログに記録され、行に沿って何かを示すイベントが発生することを意味します。
User P@$$w0rd does not exist [...]
または
An account failed to login: P@$$w0rd [...]
（ここでP @ $$ w0rdは実際のユーザーのパスワードです）
パスワードが誰に属しているかを明らかにすることはかなり明白になります。通常、同じログファイルでの前または次の（失敗した）成功したイベントは、同じユーザーによってトリガーされたイベントを通知します。
他のアナリストは、ログを見て、正当な所有者がそれに気づいていなくても、他の誰かの資格情報を取得する可能性があります。最悪のシナリオは、ネットワークの盗聴、または実際のログファイルの侵害です。
これを防ぐための一般的なガイダンスを探しています。ユーザー名をマスクするだけでは実現不可能だと思います。仮に仮にそうしたとしても、だれが何をしたのか分からないために、ログ分析の多くが排除されるでしょう。
注意： 同様の問題に関する投稿はすでにありますが、それを防ぐ方法を検討しています。 ユーザー名フィールドに誤ってパスワードを入力した場合のリスクは何ですか（Windowsログオン）？
受け入れられた回答： リストからいくつかの回答を選択できたらいいのですが。残念ながら私はフォーラムの1つだけに固執する必要がありますが、実際にはそれらを組み合わせることができます。すべての回答をありがとうございました。単一の解決策はないようです。セキュリティホールの可能性を高める「もの」を追加すると複雑さが増すことに同意するので、@ AJHendersonが最初のアプローチとして最もエレガントで最も簡単な答えを持っているというほとんどの有権者に同意する必要があります。間違いなくSSLとサーバー上またはクライアント側での簡単なコード検証。私は悪意のあるユーザーではなく、気が散っているユーザーに対して緩和することを目指しているので、これはうまくいきます。これが整ったら、必要に応じて、意図しないユーザーへの実装の拡大を検討することができます。皆さまのご意見、ありがとうございました。
パスワードボックスに値がない場合、フォームの送信を許可しないことを1つ考えます。一般に、ユーザーが誤ってユーザー名にパスワードを入力した場合、パスワードダイアログには何も表示されません。
これはクライアント側で単純に実行する必要はありませんが、使用されるトランスポートが安全で、パスワードフィールドが空でないかどうかのチェックに合格するまで入力がログに記録されない限り、サーバーで実行することもできます。 。
バックエンドアプリケーションとSIEMがさまざまなアプリケーションへのログイン試行の失敗を表示する必要がある（したがって、「ユーザーP @ $$ w0rdは無効です」というエラーメッセージを表示する）必要があるとすると、これを停止するのは簡単ではありません。
ただし、ユーザー名やパスワードなどの機密データを送信するすべてのアプリケーションがHTTPS（SSLを使用した暗号化されたHTTP）を実装していることを確認することは、ネットワークデバイスやネットワーク上の誰もがユーザー名ボックスに誤って入力したパスワードを取得できないようにするための良い方法です。
したがって、問題は、アナリストに機密ログファイルのパスワードを見せたくないということですか。
注意： JavaScriptを使用しても、ディスクにプレーンテキストで保存されているパスワードデータは処理されません。
より良い解決策は、アナリストがログを見る前にログを前処理し、ログ内の情報を編集することです。
行をホワイトリストに登録したり、他の行をブラックリストに登録したりすると、この行ごとのフィルタリングを実行できます。例えば：
ユーザーがログファイルに表示されるときに、ユーザー名をホワイトリストに登録できます
- パターン（[az] +番号）または（[az] +ピリオド+ [az]）
- aD環境の場合、ドメイン名の後にスラッシュ「\」が続く
- 複数回現れる
- アナリストが見る前に、既知のユーザー名のLDAPディレクトリに対して洗浄できます。
次の方法でもパスワードを識別してブラックリストに登録します
- 多くの場合、パスワードポリシーはパターンに従います（1つの記号、上/下、x文字...）
この知識を使用して、カスタムのログデータクレンザーを構築し、アナリストに見せたくない情報を保護できます。
フィルターされたラインはどのように見えるのですか？
疑わしいユーザー名をハッシュ化し、ヒューマンIDを割り当てて安全な場所に保存することで、疑わしいユーザー名を編集できます。
eb574b236133e60c989c6f472f07827b Redact1
7e67b89a695bfbffc05b7ed2c38f927f Redact2
..etc
分析者は、ハッシュが頻繁に繰り返される場合に、特定のエントリが繰り返し発生しているかどうかを確認できます。
この「ハッシュデータベース」には価値の高い情報が含まれるため、選択した正確なハッシュ方法（または暗号化方法）はリスクにさらされます。また、シードは（その性質上）価値のあるまたはそうでない周波数分析を防止します。
私はあなたが話していることに関して3つの問題しか識別できません。
- ユーザーが情報を正しく入力していない。
- アナリストはログからパスワードを識別できます。
- パスワードは平文で送信されており、影響を受けやすい
真ん中の男盗聴。
私の意見では、これを修正するのはかなり簡単です。
- ユーザーエラーを受け入れます、不本意です。
- 無効なユーザー名を記録せず、失敗した試行とIPを記録します。
- ユーザー名を平文で送信しないでください。 HTTPSなどのテクノロジーを使用or JavaScriptを使用してプレーンテキストをエンコードします（例：ROT13）。
失敗したログインのログの例と、成功した再試行。
[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100
他の答えを読んで、私はこれを含めたいと思います。
- 送信する前にすべてのフィールドを検証してください。
- Eric Gが述べたように、フォームを複数のページに分割することを検討してください。
いくつかの銀行が少なくともWebアプリに実装しているのを見たときの解決策は、2ページのログインを持つことです。
- 最初のページでユーザー名のみを受け入れます
- プロセスの次のページでパスワードを要求し、ユーザー名をエコーバックするだけなので、編集可能なフィールドではありません。
したがって、2ページ目の唯一の入力はパスワードでなければなりません。ユーザーは最初のページをユーザー名でクリアする必要があることを知っているので、そのゲートをクリアする必要があることを知っているので、2番目のページの唯一のオプションはパスワードです。
このワークフローを実装できれば、ユーザーが何をいつ入力するかに集中できます。
また、ログを考慮します。実際の資格情報を含まないようにログを変更できますか？
たとえば、ログインが成功した場合は、入力をエコーバックする代わりに主キーIDを使用します：「IDが「2342342」のユーザーがログオンを試みました」、「IDが「2342342」のユーザーがパスワードを提供しました」。
ルックアップを実行してもユーザー名がそこにない場合は、「ユーザーのIPアドレス '192.168.0.10'が無効なユーザーIDでログオンしようとしました」のようなものです。
これはアプリレベルのログになります。 Webサーバーのログにはクエリパラメータが含まれている可能性があるため、対処が少し難しい場合や、アクションと特定のルールに基づいてログの内容を編集するためにログが書き込まれるタイミングとの間に、ある種のプロキシフィルタを配置できる場合があります。これはプラットフォーム固有ですが、 Apacheで可能 のようです。
セカンダリコントロールとして、処理しているさまざまなログファイルへの読み取りアクセスを制限します。
一般的に言って、すべてのクライアントコードは基本的なエラーを処理するのに十分スマートです
- ユーザーIDまたはパスワードがありません
- ガイドラインに一致しないパスワード
ですから、ログにこれらのエントリがまだ表示されている場合は、
User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]
どのクライアント検証も機能せず、システムは暗号化されていないパスワードをネットワーク経由で送信してしまいました。では、パスワードフィールドには何があったのでしょうか。クライアント検証が失敗するため、間違いなく空白ではありません。パスワードとは違うものに違いない
したがって、2パス認証にします
- 最初のパス、パスワードを含むすべての暗号化された詳細をサーバーに送信します。 [パスワード]フィールドが空かどうかを確認します。
- 最初のパス、パスワードがガイドラインに一致するかどうかを確認します。そうでない場合はエラーになります。
- 最初のパス、次にパスワードがDBに存在するかどうかを確認します。エラーでない場合。
- RPC応答をクライアントに送り返し、ユーザーIDとパスワードを送信させます。
- 次に、認証プロセスを実行します
このプロセスの本質は、
- リスクを最小限に抑えます。注意、あなたはゼロへのリスクを排除することはできません
- クライアントを信頼しない。
そして最後に、UXエキスパートによるインターフェースのレビューを受けてください。インターフェースに欠陥があり、ユーザーがIDフィールドにパスワードを入力する可能性があります。
あなたがあなたのアーキテクチャについて説明したことから、これは実行不可能ですが、私の意見では、正しい解決策は、ユーザー名を平文で送信せず、失敗したログイン試行のユーザー名を記録しないことです。 onlyユーザー名とパスワードを配置する場所は、パスワードをチェックするサブシステムです。それが発生するまで、ユーザー名は非認証、任意のデータです。Webアプリケーションではインターネット全体であるログインフォームにアクセスできる人なら誰でも、好きなだけ好きなものを入力できます—したがって、興味がほとんどないことを伝えます。 （ログインフォームがインターネットに公開されていない限り）。
これにより、だれが何をしたのかわからないために、ログ分析の多くが排除されるでしょう。
正しいパスワードのないユーザー名を指定すると、リクエストが実際にそのユーザーからのものであることがわからないなので、まだわからないwhoがログインを試みた。
一般的な問題は、パスワードベースの認証です。すべてのママポップショップは、パスワードによる独自の認証を要求しています。これは愚かです。
他のIDプロバイダーに、資格情報を安全に保つためのハードワークを任せましょう。 StackOverflowと同じようにします。OpenID、Gmailなどで認証できるようにします。
ユーザーはどこかに別のパスワードをもう必要としないことを感謝します。
クライアント側のJavaScriptは妥当なようです。
送信する前に、パスワードフィールドが空でないことを確認してください。ユーザー名が有効な形式であることを確認してください。特にエレガントなのは、ユーザー名がメールアドレスである必要がある場合です。さらに、パスワード設定/変更メカニズムでのパスワードが電子メールアドレスの形式であることを禁止できます。次に、フォームを送信する前に、ユーザー名が有効なメールアドレスの形式であることを確認してください。これは、たとえば特殊文字や数字を使用して同様に行うことができます。 （たとえば、パスワードには数字/特殊文字が必要ですが、ユーザー名は禁止されています）。
さらに、すべてのフォームの送信に最新のライブラリSSLを使用します（これは、ネットワーク盗聴者が傍受しないようにするために行う必要があります）。これらのログを読み取るには、昇格したアクセス許可が必要です（たとえば、Webサーバーアカウントはこれらのログに書き込むことができますが、ルートのみがそれらを読み取ることができます）。パスワードが認証ステップに失敗したらすぐに、ユーザー名を他のシステムに伝搬しないでください。 （また、ネットワークの盗聴を防ぐために、異なる内部システム間でSSLを使用してください）。
私の現在の会社がこの問題に対して取っているアプローチが好きです。間違ったボックスにパスワードを入力すると、自動システムによってパスワードがすぐに期限切れになります。したがって、ユーザーは自分のパスワードを変更する必要があり、ログにあるパスワードは脆弱ではなくなりました。
もちろん、ユーザーが別のシステムでそのパスワードをまだ使用している場合、これはまだ理想的ではありませんが、パスワードの変更を強制されることで、ユーザーに起こり得るセキュリティリスクを認識してもらうことができます。
ほとんどの場合、最も簡単な答えが正しい答えです。ここで、すべてのメールアドレスにドメイン名の直前に「@」記号が含まれていることがわかります。 「@」をパスワードの受け入れられないキーにすると、解決策が非常に明確になります。ユーザー名に@がなく、すべてのユーザー名がメールアドレスである場合、少なくとも@が含まれているユーザーのみをログに記録します。
ユーザー名に「@」がない場合、一部のユーザーが怒る可能性がありますが、これは適切な解決策です。これは、パスワードの前に来る1つの特殊文字を持つことです。メールアカウントであるすべてのユーザー名と同じように、形式があります。すべての回答には、最初または最後に特別な特徴があります。したがって、ユーザーがパスワードを入力するときに、パスワードを入力する必要があることをユーザーに通知します。
3番目の解決策は、そのカラーコーディングです。ユーザー名フィールドを黄色、パスワードフィールドを赤にします。レッドはデリケートなものに使用されるため、通常は注意を引きます。したがって、キーボードを見ている場合でも、パスワードが赤であることはすぐにわかります。したがって、基本的にテキストフィールドとパスワードのラベルは、別のボックスとユーザー名のラベルとテキストフィールドがすべて黄色であることが望ましいです。
これで応答しないのはなぜですか？
That username does not exist
受信サーバーのこれに対する処理をどの程度制御できますか？ユーザーが上記で提案したユーザー名とパスワードの両方をハッシュ化するソリューションは、いくつかの方法で実行できるようです。
方法1（JavaScriptが必要）：ユーザー名とパスワードの両方をハッシュします。データベースに、ハッシュされたユーザー名を格納し、そのフィールドを使用して認証ルックアップを実行します。これは、サーバーでのデータの処理方法をある程度制御できるが、そのログ容量を制御しない場合に理想的です。
方法2（JavaScriptは不要）：ユーザー名を平文で通常どおり受信しますが、サーバーで受信したら、方法1と同様にハッシュに変換します。試行が失敗した場合は、ユーザー名ではなくハッシュをログに記録してください。各ハッシュは依然としてユーザーを一意に識別するので、ログは依然として有用です（ざっと調べた場合は少し有用ではありません）。これらはどちらも、ここでのトップレスポンスほどエレガントではありません（それを使用することもお勧めします）が、より完全です。
- ユーザー名とパスワード（または同様のハッシュ）のmd5ハッシュの送信のみを許可するため、ログファイルに記録されたものは常に固定長のランダムな文字のように見え、誰もがそれがパスワードまたはユーザー名のmd5。
欠点：データベースのユーザー名と比較するには、2つの列を格納する必要があります。 'username'および 'md5（username）' ORログインのためにユーザー名を照会するたびに動的にハッシュする必要があります。
- ユーザー名がデータベースに存在する場合のみログエントリを作成します。それ以外の場合は、ログIPのみを作成します。
- ユーザーがキーボードではなく、マウスを使用してEnterをクリックすることのみを許可するか、どちらかのフィールドに最後に入力された文字の5秒後にのみキーボードを許可します。これにより、ユーザーは画面を見て間違いを確認できます。
許可されたユーザー名とパスワードにいくつかの制限を加えます：
- パスワードには、！@＃$％^＆*（）のような特殊文字を含める必要があります
- ユーザー名に特殊文字を含めることはできません
このように、入力したユーザー名またはパスワードのどちらであるかをすばやく識別するためにJavaScriptを実行できます。
シンプルでありながら厄介な解決策は、HTMLボタンの画面上のキーパッドレイアウトを用意することです。ユーザーはこれらのボタンを使用してユーザー名のみを入力できます。これにより、間違いを防ぐことができます。 、ただし最初のログイン後、Cookieを使用してユーザー名を記憶し、再度必要としないようにすることができます。もちろんJavaScriptが必要です。偶然にパスワードをプレーンテキストで送信することは今では不可能です。それが役に立てば幸い。
私は別の見方をしています...どのような問題を本当に解決しようとしていますか？
悪いパスワード？つまり人が「パスワード」（またはバリアント）を使用しているのを見たときに、ユーザーまでさかのぼってそれを修正できるようにしたいですか。
パスワードは平文で送信されますか？
または、フォームを入力または読み取ることができないバカ（またはデザインが不適切なUI）の問題？
システムに「追加」するたびに複雑さが増す可能性があり、コードを確実に追加していることを常に覚えておいてください。どちらも、アーキテクチャ全体のどこかに（スタック内にある可能性があり、ウェブ、ネット越しかもしれません...）。したがって、3つのいずれかを解決する場合、それらを解決することの価値が、知らない穴を突くリスクに値するかどうかを測定する必要があります。知っている悪魔は、知らない悪魔より常に優れています。
今それぞれに。
不正なパスワードの解決は、検証ルールを介してパスワードを設定および変更するときに行う必要があります。そしてそこだけ。そのために別の場所を追加することは、検証ルールが混乱したり、同期が取れなくなったりするリスクを伴うだけです。
平文で送信されるパスワード。誰も気にしない？確かに安全ではないように感じるかもしれませんが、これは認証の一部ではないことを忘れないでください。たぶん、アクティブなスニファーがあると、手掛かりが得られるかもしれませんが、ユーザー名フィールドにパスワードが偶発的にランダムにぶつかるのではなく、すでに侵入されていることが本当の問題です。すべての部品が明確で大きな問題で送られている場合は、.
ばかや悪いUIデザインの問題。ユーザーまたはUIを修正します。シンプル。 UIに関するアクティブなヘルプを提供し、部署にトレーニングなどを実施してもらいます。限られた低リスクのコーディング変更を必要とする簡単な修正（またはUIの側面に注意してください）。
私はここで多くの提案を賞賛しますが、それらの多くはその核心に素晴らしいアイデアを持っています。私はKISSをお勧めします。BSアプローチではなく、常にシステムに追加すると、不安につながるリスクがあることを忘れないでください。
ちょうど私の2セント。
現在、バイオメトリクスはかなり安価で、少なくとも80％の時間で機能します。私はTabletPCでそれが素晴らしいと感じており、それが高速であるため（少なくともその時間の80％は）生体認証キーボードを導入したいと考えていました。
これはWin2000、WinXP、Win2003、WinVistaではそれほど問題ではなかったと思います。デフォルトでは、ユーザー名フィールドには最後に成功したユーザー名がすでに入力されているためです。変更されたActiveDirectoryまたはワークステーションのバージョンは正確にはわかりませんが、現在のデフォルトでは、ユーザー名フィールドが空白になっているため、この問題がより一般的になっています。