これは、本文で説明されていますが、haveibeenpwned APIを使用する際に攻撃の可能性はありますか？
入力したパスワードが他の場所で侵害された場合のhaveibeenpwnedのチェックを含めるために、現在、アプリでサインアップのパスワード強度検証を実装するための理解と検討に取り組んでいます。
このプロセスには、サイトがパスワードの部分的なハッシュをHIBPに送信するプロセスが含まれており、HIBPがそれが盗まれたかどうかに応じて応答することを理解しています。
また、HIBPがAPIリクエストのログを保存する可能性があり、アプリに戻る情報が含まれている可能性があると想定しています。
HIBPがハッキングされ、攻撃者が上記の架空のログへのアクセスを取得した場合、元のリクエストにすべての情報（部分的なハッシュとそれがどこから来たか（私のサイト））が含まれていると想定すると、攻撃者は私のサイトに攻撃を構築できますこちらです？
- 作成されたパスワードのリストでパスワードをハッシュし、ハッシュのリストを取得します
- 彼が持っている部分ハッシュを上記のリストのハッシュと一致させ、同じ部分ハッシュでN個の可能なパスワードの洗練された辞書を導き出します。
- 私のサイトでパスワードを試してください
上記のすべての点で、それぞれを軽減するための対策を講じることができることを知っています。 2FA。しかし、私のサインアップをセキュリティで保護する方法を尋ねることは私の目的ではなく、HIBPの使用に関する私の懸念と、検討すべき攻撃ベクトルがあるかどうかを検証することです。
PS：私はセキュリティの専門家ではありませんが、パスワードとハッシュの仕組みを知っています。私にとってHIBPは初めてなので、その仕組みやAPIのすべての機能を完全には知りません。間違った仮定をした場合はご容赦ください。
攻撃者がhaveibeenpwned.comとそのハッシュのリストを制御できる場合、これは実行可能な攻撃シナリオだと思います。彼らは部分ハッシュを照合し、すべての結果を収集してそれらを試すことができます。
並行して、攻撃者はデータベース全体に対して長期間の暗号解読を実行し、それらのエントリの一部をプレーンテキストで生成し、対応するプレーンテキストに対応する部分リストをその部分ハッシュに一致させることで、攻撃を大幅に簡略化できます。
他の多くの場合と同様に、サービスを使用する場合はプロバイダーを信頼する必要があります。侵害されているサービスは他のサービスよりも可能性が高く、可能性も低く、非常に機密性の高いデータ（ハッシュされたパスワード）を処理しています。あなたのリスク評価のために考慮に入れるべきちょうど何か。
私が現場で目にしたのは、hibp SHA1データベースのクローンを作成してローカルでテストしている人々です。
情報セキュリティにおけるすべての決定は、管理リスクを中心に展開されます。仮説の脅威が実際の攻撃ベクトルで実現できるかどうかを尋ねると、理論的には可能ですが、実際にはほとんどありません。
アプリケーションのユーザーが登録時に脆弱な（または侵害された）パスワードを選択した結果としてアカウントが侵害されるリスクはより重大であるため、必要な対策を実施することによってそのリスクを管理する必要があります。ここで、HIBPは（パスワードの複雑さの要件、2FAなどの中でも特に）リスクを許容レベルまで低減する1つの対策ですが、言及した脅威を含む他のさまざまな脅威が原因で、依然として何らかのリスクが残っています。そうは言っても、PwnedPasswordファイルをダウンロードしてネットワーク内のローカルデータベースにロードすることで、残留リスクをさらに減らすことができます。