拒否されたパスワードをログに記録することは一般的な方法ですか？
目的ごとに一意のパスワードを選択することは素晴らしいアイデアですが、実際にはこれはめったに起こりません。したがって、多くのユーザーは、簡単に思い出せるパスワードの個人用プールからパスワードを選択します。使用頻度の低いシステムへの認証時に、そのようなプールからの多数のパスワードが順番に試行される可能性が非常に高くなります。または、タイプミスの場合、失敗したパスワードは実際のパスワードに非常に近くなります。
拒否されたパスワードの処理方法を含め、有効なパスワードポリシーについてほとんど誰も説明していないため、これらは最高額の入札者に販売されているデータベースに収集されると想定する必要がありますか？
実装ガイダンスはありますか？これが拒否された場合、候補のパスワードは通常どうなりますか？それらはログに記録されていますか、すぐに破棄されていますか、またはガベージコレクションが完了するまで放置されていますか？失敗したパスワード処理手順は、監査対象のコントロールの一部ですか？有効なパスワードの処理方法については多くの実装要件と推奨事項がありますが、拒否されたパスワード値についてはあいまいです。
[〜＃〜]編集[〜＃〜]
この手順がどの程度普及しているかを理解するために、失敗したログインセキュリティ資格情報をログに記録するさまざまな実装をここにリストしてみましょう。
コンテンツ管理システム：
JoomlaLogin Failed Log プラグイン経由
このSmall Plug-inは、Joomlaサイトの管理者がログインに失敗するたびにログを収集し、それらのそれぞれについて、ユーザー名、パスワード、IPアドレス、エラーを記載したメールをサイトのスーパー管理者に送信します。
KPlaylist v1.3およびv1.4-無料のPHPインターネット経由で入手可能な音楽コレクション。
失敗したログインのユーザー名とパスワードをApacheエラーログに記録しています
Drupalバージョン5.19より前の5.xおよびDrupal 6.x 。
匿名ユーザーがユーザー名またはパスワードを誤って入力したためにログインに失敗し、そのページにソート可能なテーブルが含まれている場合、（誤った）ユーザー名とパスワードがテーブルのリンクに含まれます。ユーザーがこれらのリンクにアクセスすると、HTTPリファラーを介してパスワードが外部サイトに漏洩する可能性があります。
スタンドアロンソフトウェア
Symantec Client Security 3.1およびSAV CE 10.1に含まれるレポートサーバー
Symantec Reporting Serverの管理者パスワードは、ログイン試行が失敗した後に公開される可能性があります。
Linux：
OpenSSH変更された auth-passwd.c を介して; pam_sm_authenticate関数のオーバーロードによるPAMの使用
編集＃2
コンセンサスがあり、失敗したパスワードまたはPINSを記録することは、重大な/重大なセキュリティリスクと見なされますが、私が知る限り、次の基準は、このリスクに特に対処するガイダンス、監査手順、または制御を提供しません。
失敗したパスワード試行（クリアテキストまたはその他）の値をログに記録することは、セキュリティ対策パターンのようです。これを実行するWebアプリを見たことがありません。また、SSHなどのデフォルトのシステムサービスのどちらも実行することは知りません。以下の@tylerlで指摘されているように、ほとんどのシステムはアクセス試行に関するメタ情報（ユーザー名、時間、おそらくIPアドレスなど）をログに記録するだけです。
これがセキュリティのアンチパターンであるべき理由
簡単に言えば、失敗したパスワード試行の値をログに記録することが悪い考えである3つの理由を考えることができます。
1。ユーザーのタイプミス
パスワードを1〜2文字間違えるのはごく一般的なことです。失敗した試行のログファイルを調べると、特に失敗した一連の試行と成功した認証を対比できる場合は、これらの多くが簡単にわかります。
2。推測と確認
多くの人は、2つまたは3つのパスワードを繰り返し使用します。その結果、when彼らは特定のサイトで使用したパスワードを忘れ、一致するものを見つけるまですべてのパスワードを循環させます。これにより、他のサイトでアカウントをハッキングすることは簡単になります。
。ログブロート
失敗したパスワードを保存することは、今日の本番環境での認証サービスの大多数にとって有用な目的にはなりません。いくつかのEdgeケースがあるかもしれませんが、ほとんどの人にとって、このデータを保存することは単にディスク領域を捨てることです。
関連する法律/基準について
ログイン試行の失敗を保存するための手順に特に対処する標準（PCI、HIPAAなど）は知りませんが、上記の事実を認めると、保存に適用される同じ標準がパスワードは一般に、パスワードの入力に失敗した場合にも適用されます。言い換えれば、失敗したパスワードは依然としてカテゴリーとしてはパスワードであり、そのため同じ基準に従うという法的な主張をすることができます。
私は確かに弁護士ではありませんが、失敗したパスワードが平文で保存され、消費者が結果を被ったため、私が過失であるか業界標準に違反しているかを裁判官に判断してほしくありません。それが好ましい決定で終わるとは思いません。
さまざまな標準化団体がこの問題に具体的に対処することは有用である可能性があるというOPに同意します（実際にまだそうなっていない場合）。 そのために、私の提案は、失敗したパスワード試行の値をまったく保存しないというコンプライアンス標準を作成することです。
アプリケーションのプレーンテキストのパスワードをログに記録する正当な目的はありません。特に不正なログインの場合。偶然にログに記録される可能性があります。私は他の目的でauth.logをさりげなく見ましたが、ユーザーがログインフィールドに誤ってパスワードを入力したのを見ました（そして、ログインフィールドを記録して、どのアカウントが試行されたかを確認しましたログインする）-しかし、ユーザーに通知し、パスワードを変更しました。
反対に、ユーザーとしての保守的な前提は、使用するすべてのランダムなアプリケーションが不正な試行のすべてのパスワードをログに記録しているということです。これが、暗号化されたパスワードリスト（おそらくkeepassなどのツールを使用）で管理されている各サイトの一意のパスワードではなく、循環するランダムなパスワードを少数（3つ）持つのは悪い考えです。
このメモに関して、Mark Zuckerberg（facebookの創設者）は、businessinider.comがthefacebook.com（初期バージョンのfacebook）のログイン/パスワードの組み合わせのログを使用して（誤ったエントリからでも）ログを使用してメールアカウントに侵入したと非難されています。彼を調査していたハーバードクリムゾンジャーナリストの。 毎日のメールから： ：
しかし、さらなる主張が出された後、ザッカーバーグは明らかに紙が結局彼に物語を実行することを心配したようになりました。
Business Insiderは、クリムゾンスタッフのアカウントをハッキングした方法を友人に伝えたと主張しました。
彼は友達に、クリムゾンのスタッフであると言ったメンバーを探すためにTheFacebook.comを使用したと伝えました。
次に、ログイン失敗のレポートを調べて、クリムゾンメンバーのいずれかがTheFacebook.comに間違ったパスワードを入力したことがないかどうかを調べたとされています。
また、ある程度関連性があります xkcd （悪意のあるアカウントも、成功率を上げるために試行されたパスワードをログに記録したと想像してください）。
上記のいくつかの素晴らしい答えがあるので、これは機密情報を処理するコンピュータシステムの管理に関する米国政府のポリシーからの迅速かつ単純化された見方にすぎません。
（1）コンピュータシステム全体を、そのマシンの任意のデータで要求される最高水準に保護する必要があります。これには、マシン上またはマシン外に保存されたログが含まれます。
たとえば、意図的にまたは誤って「秘密」のデータをコンピュータに置いた場合、そのコンピュータのすべての部分を「秘密」の情報として保護する必要があります。これは、機密情報が記載された電子メールを受信した未分類のコンピュータ（自宅など）を使用している場合でも当てはまります。コンピュータ全体とそのすべてが「秘密」に分類されます。
（2）そのマシンに対するpasswordsも、そのマシン上のデータが必要とする最高レベルの保護で分類されます。
たとえば、そのマシンに「シークレット」データがある場合、パスワードをどこに保存しても、同じレベルの保護が必要です。
質問に適用すると、PCI-DSS、NISPOMなど、適用している標準に関係なく、保護することが要件である場合（ハッシュやソルトなど）、パスワードをログにクリアテキストで含めることはできません。 。
つまり、要約すると、問題のコンピューターシステムにany規制スキームが適用されており、その規制によりクリアテキストのパスワードは使用できないと記載されている場合、ログにクリアテキストのパスワードを使用することはできません。
認証の試行が失敗したという事実と、それがどのユーザーであったかを記録することは珍しいことではありません。これは、法医学的なトラブルシューティングに非常に役立ちます。拒否されたパスワードをログに記録することは、セキュリティの観点から非常に一般的ではなく、無責任です。この情報は有用ではなく、あなたに対して使用することができます。
[〜＃〜]編集[〜＃〜]
あなたは、うまくいけば信頼できる組織の会社がパスワード情報を販売しないことを期待できるはずです。見つけた。しかし、あなた自身の安全のために、あなたがあなたに提供する情報は常にあなたのために使われるように準備されるべきです。これは、信頼性を確立できない評判を持つ組織にとっては2倍になります。
いいえ。ユーザーがパスワードのプールを持ち、特定のサイトでどのパスワードが使用されているかを把握するためにユーザーを循環させることは一般的です。ロギングとは、あなたが危険にさらされたときに、彼らに代わるものがあなたに当たった人のクラッカープールに追加されることを意味します。