拒否されたパスワードのハッシュを記録することのセキュリティリスクは何ですか？
拒否されたパスワードをログに記録することは一般的ですか？ によると、拒否されたプレーンテキストパスワードをログに記録することは悪い考えですが、拒否されたパスワードのハッシュ形式を保存するとどうなりますか？分析のために失敗したログインについての詳細情報が必要です。例：
それが単なるタイプミスであるかどうかを確認します。ユーザーが最初に同じハッシュ化パスワードで最初にログインに失敗したが、後で正常にログインした場合、それはおそらくタイプミスです
パスワードを推測しようとしている人がいないか確認します。123456や誕生日など、ハッシュが固定されているいくつかの一般的なパスワードがあります。これらの試行が存在する場合、ログインに失敗した可能性があります。
ユーザーが別のアカウントを持っているかどうかを確認します。一部のユーザーは別のアカウントを持っている可能性がありますが、パスワードは異なります。ユーザーが通常同じハッシュでログインできず、ハッシュが別のアカウントと同じであるにもかかわらず、正常にログインした場合、ユーザーが別のアカウントでログインしようとしたが、パスワードを切り替えるのを忘れた。
私の質問は、拒否されたパスワードのハッシュ形式をログに記録することは、プレーンテキストの拒否されたパスワードをログに記録することと同じ問題ですか？
適切にハッシュされた の場合（つまり、ランダムなソルトと強力なハッシュを使用）、ハッシュされたパスワードは元に戻せず、パスワードが同じであっても、異なるアカウントのハッシュされたパスワードは異なります。
これは、最初に適切にハッシュされた（つまりランダムソルト）パスワードを使用して実行できる分析のほとんどが実行できないことを意味します。つまり、パスワードをログに記録してもほとんど何も得られず、いくつかの情報が場所に漏れるため、多くても失うことになります。ログは通常、保存されているパスワードほど機密性が高いとは考えられていないため、攻撃者が簡単にアクセスできる可能性があります。
代わりにプレーンハッシュ（ソルトなし）を使用する場合、攻撃者は事前に計算されたハッシュテーブルを使用してログに記録されたパスワードを元に戻すことができるため、攻撃ベクトルの増加を犠牲にして言及できることがいくつかあります。
多分あなたは適切なパスワードハッシュが何を意味するかについていくつかの誤解を持っています。パスワードを安全にハッシュする方法 パスワードを安全にハッシュする方法 を読んで、適切なパスワードハッシュがどのように行われ、なぜこのように行われるのかを理解することをお勧めしますが、以下では、誤解のいくつかに対処します。
それが単なるタイプミスかどうかを確認します。ユーザーが最初に同じハッシュ化パスワードを使用してログインに失敗することが多いが、後で正常にログインする場合、それはおそらくタイプミスです。
ハッシュされたパスワードを使用してタイプミスをチェックすることはできません。これは、入力のわずかな変更でも出力に大きな変化が生じるためです。また、ハッシュを元に戻して比較用のパスワードを取得することができないため、元のパスワードのタイプミスをチェックすることもできません。入力した間違ったパスワードが常に同じかどうかを確認するには、Jon Bentleyがコメントで提案したように、保存された（正しい）パスワードと同じソルトでソルトされたハッシュをログに記録できます。ログが保存されたパスワードと少なくとも同じくらい保護されている場合、これは攻撃対象領域をわずかに増やすだけですが、前述したように、ログは一般にパスワードの保存ほど機密性が高いとは見なされません。
... 123456や誕生日など、ハッシュが固定されたいくつかの一般的なパスワード...
適切なパスワードハッシュでは、ランダムソルトを使用して、一般的なパスワードで事前に計算されたハッシュを使用した攻撃を不可能にします。これは、同じパスワードを使用すると、ハッシュされたときに異なるハッシュが生成されることを意味します。つまり、これらのパスワードが固定ハッシュを持っているという想定は間違っています。繰り返しになりますが、攻撃対象領域が増えるという犠牲を払って、無塩ハッシュを簡単に元に戻すことができます。
入力されたパスワードがまだ利用可能であるときにこの種の分析を実行し、この分析の結果のみをログに記録することをお勧めします。
...ユーザーが通常同じハッシュでのログインに失敗し、そのハッシュが別のアカウントと同じであるが、その後正常にログインした場合、...
同じパスワードのハッシュは異なるため、この種の比較を行うには、最初に入力したパスワードが必要です。ログに記録されたハッシュからこれを取り戻すことはできないため、ハッシュされたパスワードをログに記録することは役に立ちません。この場合も、無塩ハッシュを使用してこの種の分析を行うことができますが、これは、すべてのアカウントが安全でない無塩の方法でパスワードを使用できる必要があることを意味します。これは、攻撃対象領域の大幅な増加です。おそらくソルト付きパスワードでもこの種の分析を行うことができますが、新しく使用したパスワードを、現在使用しているすべてのソルトでソルトハッシュしてログに記録する必要があります（つまり、アカウントごとに1つ）。
これは一般的な方法ではなく、一般にセキュリティに反します。私見、あなたがリストした理由のどれも、ハッシュされたパスワードをログに記録するのに十分なものではありません。実際、ログに記録する正当な理由は考えられません。コンプライアンス/法律の問題（PCIなど）に遭遇する可能性があります。ユーザーは通常、タイプミスによってパスワードに失敗し、どのサイトでどのパスワードを使用したかを忘れてしまいます。また、syslogを介して何らかのログを使用している場合は、リモートサーバーであっても、データベース以外の場所にこれらのパスワードがあります。
これらはどれも、ハッシュされたパスワードをログに記録する理由にはなりません。質問に直接答えるには、プレーンテキストのパスワードよりもハッシュ化されたパスワードをログに記録する方が「良い」のですが、どちらも非常に悪いため、実行すべきではありません。
例：HIPPAの一部は、適切かつ標準的な慣行を遵守することにより、電子保護医療情報（ePHI）を適切かつ効果的に保護する必要性に焦点を当てています。私が協力している審査員によると、パスワードを（ハッシュ化されているかどうかにかかわらず）ログに記録すると、推奨された標準的な方法ではないため、非準拠のままになります。
次のことについて多くの仮定を行っています。
- これらのアクションの有用性。
- パスワードのハッシュ化と保存は、これらのアクションを実行する唯一の方法です。
- これらのアクションの一部は、適切にソルト処理され、ハッシュされたパスワードから収集できます。
ユーザーがログインに失敗した場合、多くの理由が考えられます。たとえば、複数のパスワードがあり、それらを循環させて、サイトでどちらを使用したのか疑問に思っていることが原因である可能性があります...これで、その1つのサイトのユーザーパスワードの（ソルト）ハッシュの保存から、潜在的に複数の（ソルト） ）ユーザーがよく使用するハッシュ化されたパスワード。メールと同様に、私は複数のメールを使用しており、サイトでどちらを使用したか思い出せない場合があります。今、あなたはそれらを相互に関連付けるために私の電子メールを保存しています（この部分はパスワードとユーザーロジックの相互関係に依存します）基本的に、あなたはあなたのサイトの潜在的な将来の敵のためにユーザー名/メールとパスワードの組み合わせの大要を作っています。あなたのアイデアのいくつか：
「タイプミスかどうかを確認してください」
なんで気にするの？それがタイプミスである場合、ユーザーはタイプミスをしてそれを理解しました。フィンガープリントを開発して攻撃者にブルートフォースを指示することを目標とする場合は、他の方法があります。これはまた、適切にソルト処理され、ハッシュされたパスワードでは不可能です。それがソルティングとハッシュのまさに目標です。あなた自身は、かなりの努力なしに元のプレーンテキストをリバースエンジニアリングすることはできません。プレーンテキストがなく、ハッシュアルゴリズムが優れている場合、タイプミスが行われたかどうかを確認することはできません。
「パスワードを推測しようとしている人がいないか確認してください」
まず、実際のユーザーがこれらのパスワードを持っていないことを確認してください。第二に、他の方法があります。 3番目に、本当に必要な場合は、入力をストリームハッシュ化して既知の脆弱なパスワードのハッシュと比較できます。その場合は、一致したことをログに記録します。パスワード自体をフォームに記録する必要はありません。
「ユーザーが別のアカウントを持っているかどうかを確認する」
あなたがそうする明確な理由がない限り、あなたの条件に反することは、これはユーザーの観点からは不要です。さらに、適切にソルト処理およびハッシュ化されたパスワードは、システム内の他のレコードとすぐには比較できません。それがソルティングのポイントなので、さまざまなプレーンテキスト入力の事前に計算されたハッシュは照合できません。したがって、誰かが2つの異なるアカウントで同じパスワードを持っている場合、それらに追加されたソルトはランダムであるという概念によるハッシュは、関係なく一致しません。それらが一致した場合でも、同じパスワードを使用するまったく別のユーザー、または1文字だけ異なるパスワード（タイプミスまたはパスワードのバリエーション）である可能性があります。
このアイデアは、存在するすべてのセキュリティ概念にかなり違反しています。私はそれをお勧めしません。
Steffenの answer は適切ですが、ハッシュされたパスワードをログに記録せずに他のオプションがあることを知っておくことが重要だと思います。私の回答では、ログインを使用して外部Webサイトを実行していると想定しています。内部の場合は、ユーザーがログインしたコンピューター/デバイスに関するほぼすべてのものを保存できます。
それが単なるタイプミスかどうかを確認します。ユーザーが最初に同じハッシュ化パスワードを使用してログインに失敗することが多いが、後で正常にログインする場合、それはおそらくタイプミスです。
ユーザーが失敗して成功したときにログに記録するだけです。レポートを実行して、ユーザーが最初のログインに頻繁に失敗するかどうかを確認できます。
パスワードを推測しようとしている人がいないか確認します。123456や誕生日など、ハッシュが固定されているいくつかの一般的なパスワードがあります。これらの試行が存在する場合、ログインに失敗した可能性があります。
ログイン試行のIPアドレスをログに記録します。これは一般的な方法ですが、操作する場所でこれを合法的に行う必要があります。見知らぬ場所でログインすると、多くのサイトで追加情報が必要になります。
ユーザーが別のアカウントを持っているかどうかを確認します。一部のユーザーは別のアカウントを持っている可能性がありますが、パスワードは異なります。通常、ユーザーが同じハッシュでログインできず、ハッシュが別のアカウントと同じであるにもかかわらず、正常にログインした場合、ユーザーが別のアカウントでログインしようとしたが、パスワードを切り替えるのを忘れた。
これは他の2つの答えの組み合わせのようです。
パスワードのログを記録しなくても、必要な操作を実行できます。しかし、「なぜ」と尋ねることも重要です。なぜこれらのチェックを行うのですか？この情報を実際にどうするのですか？それらは受動的な手段で達成できますか？
それが単なるタイプミスかどうかを確認します。ユーザーが最初に同じハッシュ化パスワードを使用してログインに失敗することが多いが、後で正常にログインする場合、それはおそらくタイプミスです。
パスワードを推測しようとしている人がいないか確認します。123456や誕生日など、ハッシュが固定されているいくつかの一般的なパスワードがあります。これらの試行が存在する場合、ログインに失敗した可能性があります。
アカウント、タイムスタンプ、IP、およびそれらが成功したかどうかをログに記録するだけで十分です。この情報から多くを推測できます。
失敗、失敗、失敗、成功のパターンが同じアカウントで連続して表示される場合は、おそらくタイプミスでした。非常に多くの失敗が連続して非常に迅速に見られる場合、そのアカウントへの攻撃である可能性があります。
しかし、賢い攻撃者は数字のゲームをプレイし、攻撃を複数のアカウントに分散させます。攻撃者があなたのアカウントに関する情報を持っていない場合、与えられたパスワードの推測は、与えられたアカウントで動作する可能性と同じくらい同じです。 100個のパスワードを試してみる場合、1つのアカウントですべて試しても、100個のアカウントに分散しても、オッズは同じです。
同様に、複数のIPアドレスを使用する場合があります。多くのアカウントからのほぼすべての失敗のグループが表示されますが、分散攻撃の可能性がある単一のIPであるか、同じNATまたはVPNの背後にいる実際のユーザーの束である可能性があります。それは難しい伝えます。
現実的にはもっと簡単な方法があります。これらの攻撃は、レート制限およびソフトロックアウトによって、よりコストがかかります。パスワードの推測は、非常に多くのログイン試行を非常に迅速に実行できることに依存しています。ログインはすでにアカウントによってレート制限されているはずです。実際のユーザーが1秒間に複数回ログインを試みる理由はありません。まだユーザーには気付かれないようにできる最高のレート制限を選択してください。これにより、迅速な自動ログイン試行が失敗します。とにかく持続的な試みがある場合は、そのアカウント（および場合によってはIP）のレート制限を自動的かつ指数関数的に増やし、疑わしいプローブが収まったらそれを減らします。
また、ユーザーが自分のアカウントを作成するときに、パスワードの強度について適切なフィードバックを提供して、簡単に推測されるパスワードを回避できます。
このようにして、今日のタイピングに苦労している正当なユーザーに迷惑をかけずに、自動化された高速射撃プローブを無効にすることができます。
ユーザーが別のアカウントを持っているかどうかを確認します。一部のユーザーは別のアカウントを持っている可能性がありますが、パスワードは異なります。通常、ユーザーが同じハッシュでログインできず、ハッシュが別のアカウントと同じであるにもかかわらず、正常にログインした場合、ユーザーが別のアカウントでログインしようとしたが、パスワードを切り替えるのを忘れた。
これは、セキュリティの問題よりもビジネス要件のようです。あなたは本質的にアカウントの背後にいるユニークな人を検出しようとしています、そしてそれを正しくすることは非常に困難です：インターネットはあなたがその情報を持つことをほとんど望んでいません。それを正しくするためのコストは高く、ユーザーが増えるにつれて、実際のユーザーを困らせる多くの誤検知が発生する可能性が高まります。
それがあなたのビジネスでない限り、たとえばデータマイニング会社であれば、なぜこの要件があるのかを考えてみてください。システムに実際にどのような影響がありますか？それをバックアップするためにどんな指標が必要ですか？
本当にaltを防止する必要があると判断した場合は、さまざまな半一意の実世界IDを使用して、altアカウントにコストを追加し、その頻度を減らします。最も一般的なのはメールアドレスです。アカウントにお金がかかることや、クレジットカード番号を要求することは別です。大規模なビジネスサイトであれば、納税者番号も必要です。それはすべてあなたが何をしているかに依存します。
これは一般的な方法ですか確かにそうではありません; おそらくそうではないは良い習慣ですか？しかし、これを一度見たことがあります。このテーマについて完全に議論するために、ここで穀物に反対し、それが何に役立つのか、他の人が指摘した問題を回避するためにどのような予防策を講じたかについてお話ししたいと思います。
よく知られたログインへの絶え間ない外部攻撃、ブルートフォース、ディクショナリ攻撃、ワンパスワードエニーユーザー攻撃、スピアフィッシング、パスワードスニッフィングマルウェアのコンテキストで、組織は携帯電話、タブレット、パスワードに深刻な問題を抱えていました変化する。
パスワードの変更後にモバイルセッションがリセットされた場合、携帯電話は通常、oldパスワードを数回試行してから、通常は3の倍数（おそらくメール、カレンダー、タスク、またはそのようなもの）、beforeユーザーに新しいパスワードを要求します。これにより、認証バックエンドでの管理上および技術的に交渉不可能な3ストライクルールのため、ユーザーのアカウントがロックされました。
それ以降、モバイルデバイスのこの動作が修正された可能性があり（これは数年前です）、これが事実かどうかを知りたいと思います。
つまり、ユーザーは毎月デスクトップで「パスワードの変更」を受け取り、それを行わなかったすぐにでパスワードを変更allモバイルデバイスがすべてのデバイスでロックアウトされ、（より）安全な内部ネットワークに接続されているデバイスもロックアウトされます。これは、「単に」ロックアウトされるよりも深刻な問題でした。インターネットから。時々、すぐには不十分で、ロックアウトを回避するために飛行機モードを含む複雑なダンスの手順がありました。もちろん、携帯電話とタブレットの両方を持っているユーザーはさらに多くの問題を抱えていました。
組織は、次の方法でハッシュされたパスワードのロギングを実装しました。
- アプリケーションと認証バックエンドの間にレイヤーとして挿入されます。
- pBKDF2を使用したハッシュ。
- 深夜から深夜まで1つのソルト、正午から正午まで1つのソルト、ログインごとに2つのハッシュが保存されます。ソルトはレイヤーに保持され、どこにも保存されませんでした（レイヤーの再起動は新しいソルトを意味し、ソルトが再生されたときに失われました。 bcryptのようにハッシュに格納されませんでした）。
- ログインとペッパー（異なるアカウントの同じパスワードが検出されなかったことを意味します）。
- 特定の（ヘルプデスクにアクセスできない）データベースに格納され、（オプションで）エラー（日付、ユーザー、ソースIP、ハッシュ1、ハッシュ2、ユーザーエージェント。。。）および成功（日付、ユーザー、ソース）の形式で特定のデータストアに記録されます。 IP、useragent。。。）。
- データベースは、ここに具体的にリストされていないアクション（たとえば、すべてのユーザーのハッシュをリストする）を禁止するAPIを使用しました。
- 認証リクエストを受信すると：
- そのユーザーと同じハッシュのパスワードが（過去24時間以内に）拒否されたかどうかをデータベースで確認し、拒否された場合は、認証要求をバックエンドに提示せずにログインを拒否し、その理由をヘルプデスクがアクセス可能な場所に記録します。ログ（ハッシュなし）。
- 同じソースIPが過去n時間に複数のユーザーアカウントの認証に失敗し、ログインに成功しなかった場合はデータベースをチェックし、失敗した場合は、認証リクエストをバックエンドに提示せずにログインを拒否し、その理由をログインしますヘルプデスクがアクセス可能なログ（まだハッシュなし）。
- それ以外の場合は、リクエストをバックエンドに渡し、結果をログ/保存します。
- ユーザーのパスワードが変更されると、認証バックエンドによって、そのユーザーのすべてのレコードがデータベースから削除されます（パスワードが変更されたことをログに記録します）。これが認証バックエンドに対する唯一の変更でした。
- 24時間より古いレコードはデータベースから消去されました。
- ログはセキュリティ監査人だけがアクセスできました。
- ログにアクセスした場合、ログにアクセスするためのAPIはハッシュを取り除き、PASS1、PASS2という形式の名前のみを表示します。 。 。セキュリティ監査人へのPASSN。生のデータベースへのアクセスは非常に制限されており、基本的には上級開発者とセキュリティマネージャーの資格情報を提示することのみに限定されていました。これは実際にはハッシュの存在によるものではなく、一般にログの機密性が高い性質によるものであり、承認されたAPIの外部でrawデータベースにアクセスするための組織の標準的な手順でした。
- ユーザー名を実際に保存する必要があるかどうかが議論されました。同じ目的の機能はおそらくそうしなくても達成できたはずであり、それによって不要なユーザー追跡が回避されたでしょう。結局、攻撃者が特定のユーザーをターゲットにしているのか、それともユーザーのリストにアクセスできるのかを知ることが重要だと考えられました。
- 存在しないユーザーを安全な（ハッシュされた）方法でログに記録する機能（認証バックエンドが拒否の詳細な理由を返すことで可能になった）もあったため、存在しないユーザーを多数試行する外部エージェントも一部のユーザーのブラックリストに登録されますかなりの時間。
つまり、この実装の背後にある概念は辞書攻撃は問題ですが、同じ（間違った）パスワードを繰り返し試行しても辞書攻撃にはなりませんです。
この実装：
- ユーザーのロックアウトを回避することに成功デバイスの1つが同じパスワードを繰り返し試行したとき、これは望ましい非常に緊急の目標でした
- 認証バックエンドが提供できる機能ではなかった、複数のアカウントに対する一般的なパスワードを標的としたブルートフォース攻撃を防止
- インターネットからの認証が内部システムから分離されているため、インターネットからの攻撃は、ワークステーションにログインしているユーザーに影響を与えません。
- この件に関するヘルプデスクへの問い合わせを大幅に削減
- ティア2が特定のアカウントの拒否された認証の理由にアクセスできるようになったため（ティア3へのエスカレーションを大幅に削減）（ユーザーエージェントを使用し、ハッシュを使用しない）。
質問に答える。 。 。拒否されたパスワードのハッシュをログに記録する理由はいくつかありますが、実際に拒否されたパスワードのハッシュをログに記録することを選択したこの具体的な例は、これらの理由には当てはまりません。私は個人的に、あなたが与えた理由は有効ではないと思います。
それが単なるタイプミスであるかどうかを確認します。限られた回数の試行後にユーザーが実際にログインする限り、問題はありません。タイプミス、古いパスワード、または別のアカウントのパスワードを使用できますが、気にする必要がありますか？
パスワードを推測しようとしている人がいるかどうかを確認します。そうですが、既知のパスワードのハッシュと比較してはいけません。一般的なパスワードが使用されないようにする場合は、ユーザーがパスワードを選択するときにルールを適用する必要があります。
ユーザーが別のアカウントを持っているかどうかを確認します。アカウントのリンクはソースIPによって行われる可能性がありますが、ユーザーが他のユーザーのパスワードを最初に試してから自分のパスワードを試すことは、不正アクセスを防ぐのに役立つとは思いません。ユーザーが複数のアカウントを使用できないようにする差し迫った法的理由がある場合は、ソースIP、デバイス、およびログイン時間を追跡する方が、パスワードの誤りを追跡するよりも効果的です。
モバイルデバイスを特定することでさらに多くのことができますが、ここでの実際のソリューションは、モバイルデバイス管理とデスクトップログイン用のハードウェアMFAデバイスであり、状況が安定したら、それが問題の組織の選択でした。
お役に立てれば。
この投稿のいくつかの回答で示されているように、「ソルティング」などのセキュリティ機能が強化されているため、指定したユースケースを分析するために、保存されたパスワード（ハッシュ）を使用して失敗したパスワードを分析することは現実的ではない場合があります。
私が見ることができる実際の要件の1つは、以下のHIPAA（医療保険の相互運用性と説明責任に関する法律）の基準ですが、失敗したパスワードを記録するという主張はありませんが、以下で強調表示されている他の情報を記録/監視する必要があります。
HIPAA標準[164.308（a）（5）]に準拠）-失敗したログイン試行を含むログオンアクティビティを記録する手順
この手順に従って、システム内で発生するログオンとログアウトを記録する必要があります。不正なパスワードを使用した試行や、存在しないアカウントを使用した試行など、失敗したログオン試行を追跡する必要があります。ログには、失敗したIPアドレス、ログオン名、エラーの種類、およびシステム名が含まれている必要があります。
これが役に立てば幸い...