Have I Been Pwned 2.0 公開
(troyhunt.com)- 長く準備されてきた HIBP のリブランディングが実サービスへ移行し、Webサイトの全面再構築とほぼすべてのページの機能刷新があわせて公開された
- メイン検索は結果表示の体験を改善した一方、Webサイトでは username・phone number 検索を廃止し、既存 API との互換性は維持している
- 新しい漏えい別ページは検索結果を過度に複雑にしないようにし、事故後にユーザーが取れる具体的な対応案内を別画面に分離した
- メールアドレスへのアクセス確認が必要な機能は Sign In ベースのダッシュボードにまとめられ、domain search は JSON API とクライアント側フィルタリングによりさらに高速に動作する
- 技術スタックは Azure、Cloudflare、.NET 9.0、Bootstrap、TypeScript を中心に整理され、Google reCAPTCHA を廃止して Cloudflare Turnstile のみを使用する
新しいWebサイトと検索体験
- 新しい Have I Been Pwned Webサイト が公開された
- 公開リポジトリにおけるリブランディング作業の最初のコミットは 2024年2月に行われた
- 新ブランドは 2025年3月にソフトローンチされた
- 今回のリリースには、Webサイト全面再構築、ほぼすべてのページの機能変更、新機能追加、グッズストア公開が含まれる
- メイン検索ボックスは HIBP の代表機能を維持しつつ、結果表示の方法を変更した
- 一部のユーザーには祝福リアクションと confetti アニメーションが表示される
- 漏えいが確認された場合は、より落ち着いた赤色のレスポンスを表示する
- 結果は新しい順に並ぶスクロール可能な timeline 形式で、各漏えいの概要もあわせて提供する
- Webサイト検索では username と phone number のサポートが削除された
- username 検索は 2014年の Snapchat incident のために導入された
- phone number 検索は 2021年の Facebook incident のために導入された
- これら 2 種類のデータは、その 2 件以外では読み込まれたことがない
- username は所有者を特定しにくく、phone number は国際形式や表記ゆれのためパースが難しい
- SMS 通知はメールよりもはるかにコストが高い
- 旧サイトでこの入力を許可していたことで、「なぜ自分の番号が特定の漏えいにないのか」という混乱やサポート負荷が生じていた
- API では互換性維持のため引き続きサポートするが、新たなデータが追加されることは期待しないでほしいとしている
漏えいごとの専用ページ
- 新しい breach page は、メイン検索結果が複雑になりすぎる問題を減らすため、漏えいごとの詳細情報を別画面に分離した
- 例として Ashley Madison breach page
- 既存情報をよりユーザーフレンドリーな形で表示する
- ページの核となる変化は、漏えい後にユーザーが取るべき行動をより具体的に案内することにある
- 漏えい被害を受けたユーザーが何をすべきかに焦点を当てる
- identity protection provider のようなパートナーサービスへつなぐ方向性も含む
- 今後は漏えい情報とユーザー別データをさらに拡充していく予定
- そのサービスが 2FA をサポートしていれば、一般的な案内の代わりにそれを具体的に表示する
- passkey も別セクションとして追加予定
- 英国 NCSC との議論では、英国ユーザー向けに NCSC ロゴや関連案内リソースを表示する地域化されたデータ漏えいガイドが扱われた
統合ダッシュボードとドメイン検索
- メールアドレスへのアクセス確認が必要な機能が長年にわたり増えてきたため、それらを 1 つの central dashboard に統合した
- 2015年の Ashley Madison 事件で sensitive breach の概念が導入され、メール受信による確認が必要になった
- 2019年には API の悪用を減らすため API に認証レイヤーを追加し、API key 購入前にメール検証を求めた
- その後、domain search dashboard、有料サブスクリプション管理、stealer logs 閲覧が追加された
- 新しいダッシュボードは、1 回の Sign In の背後でメールアドレスへのアクセスを確認し、関連機能を表示する
- 一般向け機能とビジネス向け機能が同居している
- 将来的にはメール送信なしでログインできるよう、passkey サポートを追加する予定
- 家族のメールアドレスを通知購読に登録しつつ、通知は別のアドレスで受け取る機能も、ダッシュボードに適した例として挙げられている
- domain search には画面整理とフィルタリング改善が数多く盛り込まれた
- 検証済みドメイン一覧がより見やすくなった
- 検索結果はより明確な要約を提供する
- メールアドレス単位のフィルタリングと「最新の breach のみ表示」フィルタが追加された
- ドメイン検索ダッシュボードは API から JSON を受け取り、ダッシュボード全体が単一ページアプリのように動作する
- フィルタリングは domain search の JSON 全体を対象に クライアント側で実行される
- 25万件を超える漏えいメールアドレスを持つドメインでも動作可能であることをテストした
- ただし、その規模のデータはブラウザでスクロールするより API で受け取るほうが適している
- ドメイン所有権検証も完全に書き直された
- より整理されたシンプルなインターフェースに変わった
- メール以外の検証方法は、まださらに滑らかにする余地がある
API ドキュメントとグッズストア
- API 自体には変更がない
- 今回のアップデートでは 互換性を壊す変更は行っていない
- 既存 API 利用者に壊れる部分はない
- API ドキュメントは新方式へ移行できず、既存ドキュメントを維持した
- UX rebuild GitHub repo では API ドキュメント化方式について議論があり、一般的な合意は OpenAPI だった
- Scalar を使った作業が進められ、haveibeenpwned.com/scalar で確認できる
- Scalar は複数言語のサンプルとブラウザ内テストランナーを提供する
- 大きなローンチ日程の中で完成できなかったため、既存 API ドキュメント を新サイトのスタイルに合わせて維持した
- 今後余裕ができれば Scalar 実装へ移行する予定
- HIBP グッズストアが merch.haveibeenpwned.com に公開された
- Teespring を通じて運営される
- すべての商品は原価で販売され、利益は出さない
- コミュニティ向けの楽しい試みとして用意された
- ステッカーは Teespring の選択肢が従来の Sticker Mule の品質に及ばないため、既存の Sticker Mule store を継続利用する
- open source artwork も提供されており、好きな場所で自分で印刷できる
技術スタックと性能
- 元のサービスは引き続き Microsoft Azure 上で運用される
- Webサイトは App Service を使用する
- 大半の API は serverless Functions を使用する
- SQL Azure Hyperscale、queues、blobs、tables などの storage account 機能を使用する
- コードの大部分は C# で、.NET 9.0 と ASP.NET MVC on .NET Core を使用している
- Cloudflare も引き続き大きな役割を担う
- Workers に多くのコードがある
- R2 storage にデータがある
- WAF と caching 機能を使用する
- anti-automation は Cloudflare Turnstile のみを使用し、Google reCAPTCHA は完全に廃止した
- フロントエンドは最新世代の Bootstrap、SASS、TypeScript を使用する
- CSS は SASS で書かれている
- JavaScript は TypeScript で書かれている
- Webサイト性能にも計測可能な改善がある
- Pingdom テスト基準でページサイズを 28% 削減した
- リクエスト数を 31% 削減した
- 読み込み時間は変動が大きく、大差があるとは断定していない
- 11年後でも Webページサイズとリクエスト数を 2 桁比率で削減できた点を強調している
- トラッキングや広告由来の負荷と見なせる要素は入れていない
- 実際のトラフィック統計は Cloudflare edge node を通過するトラフィックに基づく
- 1Password product placement はテキストと画像だけである
- outbound click も追跡しない
- 侵襲的なトラッキング指標を期待する identity theft 企業との product placement の議論はさらに難しくなる
開発過程での AI 活用
- ChatGPT は再構築過程、特に最後の数日間で広範に活用された
- Bootstrap icons で「Index」見出しに合うアイコンを探すのに使われた
- 2,000 個を超えるアイコンの中から適切なものを約 30 秒で見つける、といった使い方だった
- サイト移行確認にも AI が使われた
haveibeenpwned.comをクロールして一意な URL を出力する PowerShell script を書かせた- 見つかった path が
stage.haveibeenpwned.comに存在するか確認する script も書かせた - 欠けていた
security.txtファイルを見つけるのに役立った - 存在したことのない項目まで見つけたため、「trust, but verify」が必要だった
- CSS の助言、Cloudflare rule 設定、.NET Core Webアプリ特有の癖のような小さな作業にも活用された
- 正答率はおよそ 90% と評価している
- ソフトウェア開発で AI を積極的に使っていないなら、それは間違っていると言えるほど強く肯定している
ローンチと Turnstile の問題
- 新サイトは筆者基準で日曜早朝にデプロイされた
- ほぼすべてが順調に進み、小さな glitch が 1、2 件あったがすぐ修正して配布した
- 記事はライブから 2 日後に公開し、先に問題をできるだけ整理した
- その間に 12 本を超える新リリースを配布し、素早く反復改善した
- 利用規約やプライバシーポリシーのような小さな変更にも多くの時間がかかった
- データ処理方法の小さな更新や stealer logs のような新サービスの反映が必要だった
- 弁護士との作業に何時間も、さらに数千ドルの費用がかかった
- Cloudflare Turnstile は、Google reCAPTCHA のようにトラフィックを Google に渡さない anti-automation の仕組みである
- 完全に見えない形で実装できる
- ブラウザ上で Cloudflare script が challenge を生成し、HTTP リクエストとともに送信され、その後サーバー側で検証される
- HIBP では 2023年から何らかの形で導入されていた
- メール送信フォームのように bot 対策が重要な場所では、Turnstile 失敗時にユーザーへ再試行やページ再読み込みを案内している
- 2 回目のクリックやページ reload で解決することがよくあった
- 解決しない場合は、ユーザーの操作が必要なより目立つ Turnstile widget の実装を検討する必要がある
- メイン検索ページでも Turnstile は重要な役割を果たす
- 非同期で API endpoint にリクエストし、challenge token も一緒に送る
- challenge 失敗により HIBP endpoint が HTTP 401 と
Invalid Turnstile tokenを返した場合、full page post へフォールバックする必要があった - 新サイト初回ローンチ時にはこのフォールバックが動作しなかったが、その後修正された
- full page post では Cloudflare managed challenge が表示され、より侵襲的だが信頼性は高い
- Cloudflare 統計では、発行された challenge の約 82% が正常に解決された
- 解決されなかった 18% のかなりの部分は、Turnstile が意図どおり遮断した bot かもしれない
- 実際の人間がブロックされたリクエストは 1 桁台の割合の可能性があり、この数値を下げる方法を引き続き見ていく必要がある
まだコメントはありません。