Webサイト100万件の認証調査：FIDO2普及の実態と暗号チャレンジ実装の課題 • vonxai blog

フィッシング攻撃やパスワード漏洩のリスクを低減する手段として、パスキー（FIDO2/WebAuthn）を用いたパスワードレス認証の導入が進められています。しかし、実際のWebサービスにおいてFIDO2がどの程度普及しており、サーバー側で安全に実装されているかについての包括的な調査データは不足していました。

本記事では、リエージュ大学のMacha Krumm氏らによる研究論文「FIDOLOGY: A Measurement Study of FIDO2 Adoption Across the Web」に基づき、100万規模のWebサイトを対象とした大規模調査で明らかになったFIDO2の普及実態と、サーバー側実装におけるセキュリティ上の問題点を解説します。

Web認証におけるFIDO2普及の実態：パスワード主導の継続と潜在的導入

研究チームは、主要ドメインリスト（Tranco、CrUX、Umbrella）から抽出した100万件のWebサイト（到達可能ドメイン：981,201件）を対象に、自動収集ツールを用いて認証シグナルの解析を実施しました。

ボット対策やヘッドレスブラウザのアクセス制限により判定不能となったサイトを除く、422,037件の解析結果は以下のとおりです。

表1：大規模Webサイト調査における認証方式の分布

認証カテゴリ	該当サイト数	全体比割合	分類可能サイト内の割合
判定不能・制限あり	231,767	54.92%	-
パスワードのみ	169,461	40.15%	84.87%
パスワード＋多要素	421	0.10%	0.21%
FIDO2関連シグナルあり	20,371	4.83%	10.20%
判定不能・その他	17	0.00%	0.01%

分類可能だったWebサイトのうち、 約85%に相当する169,461件が「パスワードのみ」 に該当しました。トップ画面で直接パスキーログイン（full_fido2）を提供しているサイトは361件（全体の0.09%）にとどまっています。

一方で、FIDO2に関連するシグナルを持つ「FIDO2関連シグナルあり」と判定された20,371件の内訳を見ると、大部分は latent_support（17,452件、全体の4.14%）でした。これは、ログイン画面上に直接「パスキーでログイン」というボタンを提示していなくても、内部的なJavaScriptライブラリ、バックエンドAPI、あるいはFedCM（Federated Credential Management）連携など、FIDO2を受け入れる基盤が内部に組み込まれている状態を示しています。

この結果から、表面的なログイン画面では依然としてパスワード認証が主流であるものの、裏側の基盤としてはFIDO2の導入準備が進みつつある段階であることが窺えます。

FIDO2実装に潜む致命的な問題：暗号チャレンジの再利用

本研究で最も注意すべき成果は、FIDO2を実際に導入しているWebサイトの「サーバー側における実装品質」の評価です。

研究チームは、FIDO2の導入が確認された2,575サイトに対して自動プロービングを実施し、サーバーから返却されるWebAuthnの認証オプション（PublicKeyCredentialRequestOptions）を5回連続で取得・解析しました。その結果、1,011サイトから正常にレスポンスを得ることに成功しました。

暗号チャレンジの品質およびセキュリティ要件の適合状況は以下のとおりです。

表2：FIDO2認証チャレンジのセキュリティ評価

評価項目	測定値 / 割合	仕様要求との比較
平均チャレンジ長	379.14バイト	推奨値（最小16バイト）を大きく超過
平均有効エントロピー	2,216.79ビット	推奨値（最小128ビット）を大きく超過
仕様適合サイト率	約98%	長さ・エントロピーともに基準を満たす
暗号チャレンジの再利用	3.96%（38サイト）	複数セッション間で同一チャレンジを返却

暗号チャレンジの長さやランダム性（エントロピー）に関しては、約98%のサイトがW3Cの仕様要件を満たしており、平均しても高い安全性を保持していました。

しかし、複数回のレスポンス取得に成功した959サイトのうち 3.96%（38サイト）において、セッションが異なるリクエストに対しても完全に同じ暗号チャレンジを再利用している挙動（ハミング距離0） が確認されました。

WebAuthnにおける暗号チャレンジは、悪意のある第三者が過去の認証応答を横取りして使い回す「リプレイ攻撃」を防ぐためのワンタイムな使い捨て乱数（nonce）です。同一のチャレンジを返却するサーバー実装は、FIDO2の本来の防衛機能を無効化する重大なセキュリティ上の欠陥となります。

WebAuthnポリシー設定におけるセキュリティの不均衡

暗号チャレンジの生成問題に加えて、WebAuthnのポリシー指定（userVerification フラグ）においても設定の不均衡が見られました。

表3：WebAuthnにおけるユーザー検証（userVerification）設定の分布

設定値	該当サイト数	割合	セキュリティ上の意味
required	671	66.36%	生体認証やPINによるユーザー検証を必須とする（最も安全）
discouraged	238	23.54%	ユーザー検証を明示的に不要とする（端末存在確認のみ）
preferred	68	6.72%	端末状況に応じて検証を実施する
未指定（unknown）	34	3.36%	ポリシーが未定義で端末のデフォルトに依存する

ユーザー検証（userVerification）を required（必須）に設定しているサイトが約66.4%と多数派を占める一方、約23.5%のサイトでは discouraged（不要）が指定されていました。

discouraged を指定すると、ログイン時の操作ステップが減りユーザー体験は滑らかになりますが、端末が盗難された場合などに第三者による不正アクセスを許すリスクが高まります。利便性と保護強度のバランスにおいて、開発者や運営側の判断が分かれている状況が分かります。

安全なFIDO2運用に向けた実装上の注意点

本研究の測定結果を踏まえ、FIDO2/WebAuthnを安全にシステムへ組み込む際に確認すべき技術的なポイントを整理します。

サーバー側でのワンタイムなチャレンジ生成の徹底 暗号チャレンジは、必ず認証リクエストごとにサーバー側で暗号学的に安全な疑似乱数生成器（CSPRNG）を用いて生成してください。データベースやセッション情報に固定値を保持して再利用したり、予測可能なタイムスタンプのみに依存した生成を行わないよう実装を確認することが重要です。
適切な認証ポリシー（userVerification）の選定 保護すべきデータの機密性に応じて userVerification を設定してください。高リスクな取引や個人情報を扱うサービスでは required を設定し、PINや生体認証による本人確認を必須とすることが推奨されます。
タイムアウトおよびリライングパーティID（rpId）の適切な管理 rpId は、作成したパスキーを利用できるWebサイトのドメイン範囲を指定する識別子です。WebAuthnでは、アクセス中のドメインが rpId と一致しているかを端末（ブラウザ）が自動検証することで、フィッシングサイトでの不正な認証要求をブロックします。複数サブドメインでパスキーを共有する場合や外部の認証プロバイダへ処理を委譲する場合は、rpId が意図したドメイン範囲で正しく構成されているか確認してください。
また、認証処理のタイムアウト時間についても、セッション固定化のリスクを避けるため、W3C仕様で推奨される5〜10分程度の適切な範囲内に収めることが望まれます。

まとめ

論文による100万規模のWebサイト調査は、Web認証の現状と課題を具体的に示しています。

表面的に露出しているログイン手段としてはパスワード認証が全体の約85%と依然として主流です。
FIDO2の導入は完全なパスワードレス提供（0.09%）よりも、内部基盤の準備やFederated連携といった潜在的な形態（4.14%）を中心に広がっています。
FIDO2導入サイトの約3.96%で暗号チャレンジの再利用が検出されるなど、サーバー側の実装不備によるセキュリティリスクが一部に存在します。

パスキーへの移行を進めるにあたっては、フロントエンドの導入だけでなく、バックエンドでの正しい暗号処理と適切なポリシー運用を行うことが不可欠です。

Webサービスや社内のセキュリティにお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！

参考資料：

FIDOLOGY: A Measurement Study of FIDO2 Adoption Across the Web