顧客のパスワードが侵害で発見されたかどうかを事前にチェックするこのシステムの何が問題になっていますか？

Question

アカウントの作成中、他のサイトの侵害から再利用されることがわかっているパスワードはすでに禁止されているとしましょう。しかし、侵害は常に発生するので、顧客がすでにアカウントを作成した後で、顧客のパスワードが後でリストに表示された場合はどうなるでしょうか。

もちろん、ハッシュ化、ソルト化、ペッパー化されたパスワードを保存していますが、その目的は、新しく漏えいしたすべてのパスワードなど、多くの推測を試行するのが非常に困難になることです。新しく漏洩したパスワードをチェックできるようにするためにソルトハッシュと一緒に保存すると考えられる情報も、ソルトハッシュを弱めます。次にサインインするまで待ってから、漏洩したパスワードのリストを確認することはできますが、事前に通知するにはどうすればよいですか？現在のすべてのセッションを期限切れにすることで再サインインを強制できますが、影響を受けていない顧客に不便をかけないようにするにはどうすればよいですか（特にそれが通常100％の場合）。

仮に：

サインインプロセス中に、サーバーは160ビットの暗号的にランダムなナンスを生成し、それをクライアントに送信し、それをMemcachedなどの一時ストレージ内のセッションに関連付けます
サインイン要求をサーバーに送信するとき、クライアントはSHA1でパスワードをハッシュし、それをナンスとXORし、ナンスを忘れている間、結果をローカルに保存します。
サーバーは新しい違反について学習すると、ナンスをクライアントにプッシュします
次に、クライアントはXOR暗号化されたSHA1を使用したナンスを実行し、SHA1ハッシュを「私がPwnedされたか」などで確認できます。

ノート：

nonceはどこにでもディスク/耐久性のあるストレージに触れることはありません
お客様のパスワードは、ディスクや耐久性のあるストレージのどこにも決して触れません（パスワードを簡単に抽出できる任意の値、たとえば無塩SHA1など）
nonceがないと、XORパッド/ワンタイムパッドの暗号化は暗号的に完全なので、暗号化されたSHA1は役に立たないため、XSSに対する脆弱性やクライアントのコンピューターの侵害はありません。
サーバーはしばらくするとナンスを期限切れにしたり、顧客アカウントごとに保持するそのようなナンスの数を制限したりできます。どちらの場合も、暗号化されたSHA1は不可逆的に役に立たなくなります。

もちろん、システムが完全に作成された場合、次にクライアントが更新されるときに、悪意のあるコードが含まれ、ナンスと暗号化されたSHA1を組み合わせて、攻撃者のサーバーのクリアテキストSHA1を引き出しますが、これは、私のデータベースダンプが侵害されるよりもはるかに高い障壁のようです。

私が考えることができる、これを潜在的に強化する1つの小さな方法は、完全にSHA1ハッシュを格納する代わりに、比較的少数の新しく漏洩したパスワードが非常にのみ衝突するように十分なビットのプレフィックスを格納するだけで可能である可能性があることです私の顧客のSHA1プレフィックスの一部ですが、辞書攻撃を数十または数百の推測にフィルタリングするだけの十分なビットがあり、適切にレート制限されたオンラインサービスで使用するには十分な数です。ただし、このような数のビットが存在していても、攻撃者がArgon2でハッシュされたパスワードとソルトを持っていないことを想像するのは難しいので、この緩和策はあまり有用ではないと思います。数百または数千にまで狭められました。

Anonymous · Answer

あなたが追求していることはかなり野心的だと思いますが、それはやり過ぎです。私の意見では、あなたは単純に：

最小レベルのパスワードの複雑さを適用する
2要素認証を追加（2FA）-これは弱いパスワードまたは侵害されたパスワードを補います
可能な場合は2FAを必須にするか、できるだけ多くのユーザーを登録してください
システムの引き締めと監査に自由な時間を費やします-いくつかの脆弱性が存在する可能性があり、すべてのセキュリティの取り組みを無効にする可能性があります

したがって、答えは、認証の目的でパスワードだけに依存することではありません。

サインアップ時に提供されたパスワードをpwnlistsと照合することをお勧めします。実行offline、つまり、ローカルドライブに保存されているパスワードリストに違反します。確認のためにオンラインサービスにパスワードを送信しないでください。
ユーザーがパスワードを変更するたびに、このチェックを繰り返すことができます。

2FAの実装に関しては、いくつかのオプションがあります。たとえば、多くのユーザーはGoogleオーセンティケーターで満足するかもしれませんが、他のユーザーは代替ソリューションでより快適であるかもしれません。

最近のSMSは安全とは見なされていませんが、保護しようとしている資産の価値によって異なります。

ThoriumBR · Answer

あなたはそれを必要としません。あなたはすでにハッシュ化されたソルト付きパスワードを持っており、ソルトを持っています。漏洩したパスワードに使用するサービスがプレーンテキストのパスワードを提供する場合、すべてのアカウントに対して「辞書攻撃」を利用し、漏洩したパスワードがクライアントと一致するかどうかを確認できます。

HIBP APIサービスを使用すると、部分的なSHA-1ハッシュを検索できるため、テーブルにフィールドを追加して、パスワードのSHA-1ハッシュの最初の5文字を格納できます。定期的にHIBPのハッシュを調べて、漏洩したパスワードを取得したクライアントがないかどうかを確認します。

RockYouパスワードダンプで上位の96016パスワードを取得し、実行しましたsha1sum それらの上に。最初の5文字（HIBP APIなど）のみを取得し、並べ替えて、一意のエントリをカウントしました。その宇宙の中で、91753のユニークな値を得ました。重複は4％未満でした。 1つのエントリだけに6つのコピーがありました。 110は3から6の間です。したがって、このシステムがパスワードの漏えいをおそらく検出した場合、少なくとも95％の確率で実際に漏えいしました。