パスキー認証はプロトコルとして堅牢ですが、RP（サービス提供者）側の実装ミスにより深刻な脆弱性が生まれ得ます。本記事では9つの実装リスクを整理し、パスキーの「手前」に認証レイヤーを置くことで得られる構造的なリスク低減効果を解説します。
パスキー（Passkey）の普及が加速しています。メルカリは2025年5月にパスキー登録者数1,000万人を突破し、FIDOアライアンスのJapan Working Groupには64の組織が参加、国内で50以上のパスキープロバイダーが稼働または計画中という状況です。
金融庁も2025年の対話資料でフィッシング対策としてパスキー利用の促進を明記し、日本証券業協会はフィッシング耐性のある多要素認証の必須化を求めるガイドライン改正案を公表しました。「パスキーを導入すれば安全」―そう考える企業が増えるのは自然な流れです。
しかし、「導入した」と「安全になった」は同義ではありません。2025年6月、GMO Flatt Securityの技術ブログがパスキー認証のRP（Relying Party）実装に起因する9つの脆弱性パターンを公開しました。本記事では、この指摘を起点に、パスキー時代の認証設計に必要な「もう一つの視点」を整理します。
1. パスキーは万能ではない―実装が生む9つの脆弱性
パスキー普及の加速と「導入＝安全」という誤解
パスキーの勢いは数字が示しています。FIDOアライアンスの2024年調査によれば、パスキーの世界的な認知度は2022年の39%から57%へと50%増加しました。認知している人の62%が実際にパスキーを利用しており、世界の上位100サイトの20%がすでにパスキーに対応しています。
日本国内でも、証券口座の不正アクセス事件を受けて規制当局が動き、金融庁は「ID・パスワードのみの認証やSMS OTPではもはや不十分」と明言しました。パスキーへの移行は、もはや先進的な取り組みではなく「やらなければならないこと」になりつつあります。
この流れ自体は歓迎すべきものです。ただし、ここで見落とされがちな事実があります。パスキーのプロトコル（WebAuthn）がどれだけ堅牢でも、それを「実装する側」にミスがあれば、従来と同じセキュリティリスクが残り続けるという点です。
GMO Flatt Securityが指摘した9つの実装脆弱性
2025年6月、セキュリティ企業GMO Flatt Securityの技術ブログが、W3CのWeb Authentication Level 3仕様を読み解き、RP側の実装で注意すべき9つのセキュリティ観点を公開しました。主な指摘は以下の通りです。
署名の検証不備―認証器から返されたデジタル署名の検証が不十分な場合、攻撃者が偽装したアサーション（認証応答）が受け入れられ、不正ログインを許す可能性があります。
チャレンジの検証不備―リプレイ攻撃（傍受したアサーションの再利用）を防ぐためのチャレンジ値が正しく検証されていない場合、過去のアサーションを悪用されるリスクが生じます。
Credential IDの重複検証不備―登録時にCredential IDの一意性を確認しない場合、攻撃者が被害者の認証情報を自身のアカウントに紐づけ、被害者を攻撃者のアカウントにログインさせるという巧妙な攻撃が成立し得ます。
ユーザーの検証不備―アサーションに含まれるuserHandleと、署名検証に使用する公開鍵の紐づけを正しく確認しない場合、なりすましが可能になります。
このほか、チャレンジの安全性（エントロピー不足）、オリジンおよびRP ID検証不備、安全でないフォールバック処理、Non Discoverable Credentialのフロー混在、アカウント登録状態の漏洩と、合計9つの観点が整理されています。
特に注目すべきは、実際にCVE番号が付与された脆弱性が存在する点です。CVE-2025-26788（CVSS 8.4・HIGH）は、オープンソースのFIDO認証サーバーであるStrongKey FIDO Serverにおいて、Non Discoverable CredentialとPasskeyの認証フローが混在する際の検証不備により、任意のユーザーアカウントを乗っ取れるものでした。
問題は「プロトコル」ではなく「実装する側」にある
WebAuthnの仕様自体に問題があるわけではありません。むしろ仕様は精緻で、各検証ステップが詳細に定義されています。問題は、その仕様を正しく実装するために求められる専門性の高さです。
たとえばCredential IDの重複検証は、ライブラリの導入だけでは対処できず、開発者自身がデータベースレベルで一意性チェックを実装する必要があります。セッション管理やフォールバック処理の設計も同様です。
パスキーという「強い鍵」を手に入れたとしても、その鍵を取り付ける「ドア」の設計に穴があれば、侵入は防げません。
2. なぜパスキーだけでは「入口」を守れないのか
認証の「入口」と「出口」―設計視点で整理する
認証設計を考える際、「入口」と「出口」という2つの視点で整理すると、パスキーの守備範囲が明確になります。
パスキーが強力なのは、認証セレモニーの「出口」―つまり、正当なユーザーが正当なデバイスで認証を完了し、セッションを確立するプロセスです。公開鍵暗号方式により、フィッシングサイトにパスワードを入力してしまうような事故は構造的に防止されます。
一方で「入口」―つまり、そもそも「誰がその認証フローを開始しているのか」「その人物は正当なアカウント保有者か」という問いに対しては、パスキー単体では構造的に弱い局面があります。認証セレモニーの開始自体は、誰でも要求できるためです。
この「入口と出口」の非対称性が、パスキー時代の認証設計において見落とされがちなポイントです。
フォールバック処理が「最弱リンク」になる構造
パスキーの実装脆弱性の中でも、とりわけ構造的に深刻なのが「安全でないフォールバック処理」です。
ユーザーがパスキーを紛失した場合、デバイスを変更した場合、あるいはパスキーに対応していない環境からアクセスする場合、サービスはアカウント復旧のための代替手段を提供する必要があります。この復旧フローが、メールアドレスへのリカバリーコード送信やパスワードリセットに頼っている限り、パスキー本体がどれだけ堅牢でも、認証基盤全体の安全性はフォールバック処理の強度に律されます。
これは「鎖の強度は最も弱い環に等しい」という、セキュリティ設計の基本原則そのものです。パスキーという強力な「環」を追加しても、フォールバックという「弱い環」が残っていれば、攻撃者はそちらを狙います。
認証フローの混在が生む「想定外の穴」
CVE-2025-26788は、この「想定外の穴」を象徴する事例です。
StrongKey FIDO Serverでは、バージョン4.10.0以降でDiscoverable Credential（パスキー）とNon Discoverable Credentialの両方をサポートしました。しかし、この2つの認証フローを区別する処理に不備があり、攻撃者は被害者のユーザー名で認証フローを開始し、返されたチャレンジを自身のパスキーで署名することで、被害者のアカウントにログインできてしまいました。
この脆弱性はCVSS 8.4（HIGH）と評価され、2025年2月に修正版がリリースされています。注目すべきは、これが個別の実装ミスではなく、2つの認証方式が共存する環境で構造的に発生しうるリスクである点です。
3. パスキーの「手前」に電話番号認証を置くという発想
「代替」ではなく「手前に入る」認証レイヤー
ここまで整理してきた課題に対して、Infront Securityが提案するのは「パスキーを電話番号認証で置き換える」ことではありません。パスキーの認証セレモニーの「手前」に、電話番号認証のレイヤーを配置するというアプローチです。
電話番号は、SIMカードに紐づく物理的に一意な識別子です。1つの電話番号が同時に複数の端末で有効になることはありません。この一意性とデバイスバインディング（端末紐づけ）を組み合わせることで、そもそも不正なユーザーが認証フローに到達すること自体を阻止できます。
具体的には、電話番号認証 → デバイスバインディング → パスキー認証（またはフォールバック）という多層構造を構築します。パスキーの「出口」の強さはそのまま活かしつつ、「入口」の安全性を電話番号認証で底上げする設計です。
フォールバック処理の安全性を構造的に底上げする
先述の「フォールバック処理が最弱リンクになる」問題に対しても、電話番号認証は構造的な解決策を提供します。
パスキー紛失時のアカウント復旧フローに電話番号認証を組み込めば、復旧を要求しているのが実際のアカウント保有者であることを、電話番号の一意性によって確認できます。メールアドレス＋パスワードリセットという従来のフォールバックと比較して、フィッシング耐性が構造的に高まります。
導入の敷居も低く設計されています。初期費用ゼロの従量課金モデルで、1つのAPIを連携するだけで実装可能です。最短数日で稼働開始できるため、パスキーのRP実装を全面的にリファクタリングするコストや期間と比較すれば、遥かに現実的な選択肢です。
アプリのインストールも不要で、「電話をかけるだけ」で認証が完結するUXのため、ガラケーや固定電話しか持たないユーザー層にも対応できます。再春館製薬所（ドモホルンリンクル）での導入では、高齢者層のログイン率改善と問い合わせ件数の減少という成果が得られています。
「セキュリティ診断の前に、構造で守る」という逆転の発想
最後に、少し視点を変えた提案をします。
パスキーの実装脆弱性を1つずつ発見し、修正するのは、セキュリティ診断の専門家の仕事です。GMO Flatt Securityのような企業が提供する「Passkey認証診断」は、この領域で大きな価値を持っています。
しかし、もう一つの発想があります。パスキーの「手前」に電話番号認証のレイヤーを置いておけば、仮にRP実装に脆弱性が残っていたとしても、不正アクセスの大半はその手前で食い止められるということです。
セキュリティ診断が「穴を見つけて塞ぐ」アプローチだとすれば、電話番号認証の事前配置は「穴があっても水が入らない構造にする」アプローチです。どちらが優れているかではなく、両方を組み合わせることで、認証基盤の安全性は二重に担保されます。
セキュリティ診断会社とは競合しないポジションで、認証の構造そのものを強化する―これがInfront Securityの提案です。
パスキーの普及は、認証の歴史において大きな前進です。しかし、「導入したから安全」で思考を止めるのではなく、認証設計全体を俯瞰する視点が求められます。
「出口」を固めるパスキー。「入口」を守る電話番号認証。この2つのレイヤーを組み合わせることで、パスキー時代の認証設計は、より堅牢なものになります
「出典・注釈」
・GMO Flatt Security Blog「Passkey認証の実装ミスに起因する脆弱性・セキュリティリスク」（2025年6月24日）
・CVE-2025-26788（NVD, CVSS 8.4 HIGH / Securing社レポート, 2025年2月）
・FIDO Alliance「Online Authentication Barometer」（2024年11月）
・メルカリ mercan「パスキー登録者数1,000万人を突破」（2025年5月）
・金融庁「キャッシュレス社会の安全・安心の確保に関する検討会」報告書（2025年3月）
・日本証券業協会「インターネット取引における不正アクセス等防止に向けたガイドライン」改正案（2025年7月）
・W3C Web Authentication: An API for accessing Public Key Credentials Level 3（Working Draft）
