😈
パスキー認証に対する脅威と対策 (2025秋)

ritou
2025/09/29に公開
Passkey (パスキー)
tech
ritouです。
ここ数年、ユーザー認証のお話をさせていただいている中、最近ようやく「パスキー認証はね、入れとかないと」みたいな雰囲気になってきましたが、しかしその一方で、「パスキー認証のこういうところが好きになれない」といったご意見も当初からいただいています。今回は、その中の「こうしたらやられる」と言う主張、つまりパスキー認証に対する現状の脅威、考えられる対策 について整理しましょう。

 ユーザー認証の現状とこれからユーザー認証はここ数年、脅威の認識と対策の繰り返しの中で変化してきました。

パスキー登場までの経緯については、 “パスワードレス認証への道" ユーザー認証の変遷とパスキーの関係 にて整理しています。
3行でまとめると、次のようになります。
パスワード認証のみの利用は、パスワードの使い回しによる他サービスへの影響範囲を考えても、極めて危機的な状況である
一般的に使われている「パスワード認証 + α」の方式は、リアルタイム型フィッシングで突破される可能性があることも知られている
パスキー認証では、これら従来の脅威への対策が実装されています。 導入を進めるべき。
この「過渡期」から、パスキーが当たり前に使われる「安定期」へ移行するためには、「パスキー認証自体や、パスキー認証が任意で利用可能な状態に対する脅威」が十分に周知され、根本的な対策や緩和策がある程度利用可能になること が重要です。
「パスキー認証なら絶対に安全」というわけではありません。**「パスキー認証にも脅威や課題はあるが、対策を講じれば従来よりは安全な状況にできる」**という共通認識を持っておく必要があります。

 脅威の特性を3種類に分類パスキー認証への脅威を扱うにあたり、まずはその特性によって大きく3つに分類します。

(A) パスキー認証自体の実装不備を突く攻撃、あるいは正しく実装しても対策が困難なもの: これはサービス提供者側の実装に関する問題です。

(B) 正規の認証や登録フローを悪用する問題: これは、プロトコルの不備ではなく、ソーシャルエンジニアリングやフィッシングによってユーザーを騙し、意図せず正規の操作を行わせることで成立する攻撃です。パスキー再設定のためのアカウントリカバリーフローを中継し、最終的に攻撃者のパスキーを登録させるフィッシング攻撃などがこれに該当します。

(C) パスキープロバイダやデバイス、外部サービスのアカウントなどを狙う攻撃: これは、サービス提供者 (RP) の直接的な管理範囲を超えた、ユーザーの利用環境全体を標的とする攻撃です。デバイスの盗難、パスキーを同期しているGoogle/Appleといったプラットフォームアカウントの乗っ取り、フォールバック認証としてのID連携への脅威などがこれにあたります。
A、B、Cでは責任の所在が異なり、それぞれ対策のアプローチも変わってきます。

この分類を念頭に、具体的な脅威を見ていきましょう。

 サービスの機能単位での分類次に、ID管理の機能単位で脅威を整理します。これにより、どの段階でどのような脅威が発生しうるかを明確にします。

 身元確認身元確認とは、新規アカウント作成時や、ログインできない状態からの回復（アカウントリカバリー）で行われる「属性情報を検証するプロセス」を指します。
パスキー認証においては、何らかの理由でパスキーが利用できない場合に、適切な身元確認を行った上でパスキーを再登録・リセットさせるといった場面で用いられます。このアカウントリカバリー時の身元確認がフィッシング耐性を持っていない場合、当人認証と同様にリアルタイム型フィッシング攻撃を受けるリスクがあります。攻撃者はパスキー認証を迂回し、ユーザー自身に身元確認を突破させた後、自身のパスキーを登録してアカウントを乗っ取る、といった脅威が考えられます。

 当人認証登録済みのパスキーを用いたログイン処理そのものです。パスキー認証フローの安全性は広く知られるようになりましたが、実装不備や正規フローを悪用した攻撃などが存在します。 また、パスキー認証が必須でない場合は、他の認証方式を狙った攻撃もこの対象となります。

パスキー認証の正面突破 (A): サービスの実装不備を狙って不正ログインを試みる攻撃です。

RPIDに関連するドメイン管理体制の不備を狙う攻撃 (A): サービスが指定するRPIDと一致するドメインが不正に取得されると、パスキー認証であってもリアルタイム型フィッシング攻撃を受け、ログインセッションを窃取されるリスクが生じます。

Hybrid Transportの利用によるログインセッション取得を狙う攻撃 (B): 別端末からのパスキー認証で利用されるHybrid Transportでは、端末間をBLEで接続することによる近接チェックが行われます。これにより、QRコードを用いたリモートでのログインセッション取得は困難です。しかし、攻撃者が自身の端末をユーザーの近くに置き、SNSのフォローを促すといった偽のQRコードを提示した場合、ユーザーが「フォローのためにパスキーでログインするのだ」と誤認して許可すると、攻撃者の環境でログインセッションが取得されてしまうリスクがあります。

フォールバックの認証方式を狙う攻撃 (A/B/C?): パスワード認証や、それに別の認証方式を加えたMFAを狙う攻撃です。パスキー認証と他の認証方式を併用している場合、リアルタイムフィッシングなどへの注意が引き続き必要です。

 セッション管理パスキー認証に成功した後、そのログイン状態を維持する仕組みを狙う攻撃です。身元確認や当人認証を堅牢に実装しても、発行されたセッション情報（クッキーなど）が窃取されると、なりすましによる不正利用につながる可能性があります。
XSS (クロスサイトスクリプティング)
マルウェアによるブラウザ認証情報の窃取
ドメイン管理の不備によるCookie情報へのアクセス（パスキーのRPIDとは別の、ログインセッションの対象ドメインの問題）

 利用環境の管理認証の前提となる、ユーザーの利用環境に対する脅威です。パスキーにアクセスできるデバイスの物理的なセキュリティや、パスキーを管理・同期するサービスのアカウント、ID連携でも利用されているプラットフォームアカウントの安全性に依存します。

パスキー利用可能端末を狙う攻撃 (C): 端末の物理的な奪取や脅迫などによりローカル認証が突破されると、攻撃者によるサービスへの不正アクセスが可能になります。

パスキープロバイダのアカウントを狙う攻撃(C): プラットフォームアカウントやパスワードマネージャーのアカウントが攻撃者に乗っ取られると、その管理下にあるパスキーが奪われ、不正利用される可能性があります。プラットフォームアカウントが侵害されてもパスキーへのアクセスを防ぐPIN設定なども存在しますが、モバイル端末で受信したSMSを転送できるアカウントなどもあり、一度侵害された場合の影響は大きいと認識すべきです。

フォールバックのID連携のプロバイダのアカウントを狙う攻撃(C): プラットフォームアカウントなどでのソーシャルログインが利用可能な場合、そのアカウントが乗っ取られると、連携済みのサービスへ不正ログインされる危険性があります。上述のパスキープロバイダを兼ねているプラットフォームアカウントの場合、より広範囲の脅威を想定しなければなりません。

 どれぐらい危ないのか、対策が必要かの基準このように脅威を並べられても、どこから対策すべきか判断に迷うかもしれません。以前 https://zenn.dev/mixi/articles/200eeb64dfb148 という記事で解説しましたが、
正規ユーザーの同期的なアクションが必要かどうか
ユーザーの手元の端末など、環境へのアクセスが必要かどうか
という2つの軸で整理することで、すぐに対策が必要な脅威か、あるいは様子を見ながら対応すべき脅威かを判断しやすくなるでしょう。よろしければ併せてご覧ください。

 対策、緩和策脅威の分類ができたところで、対策と緩和策を整理します。一般的に、脅威への対策はサービス側のものが語られることが多いですが、今回はユーザーが取れる対策の要点も示しつつ整理します。

 身元確認当人認証ができない状況からのアカウントリカバリーにおいて、身元確認はアカウントを守る最後の砦です。重要なのは 「サービスがユーザーに今何が行われているかを説明すること」 と 「フィッシング耐性のない要素への依存を減らすこと」 の2点です。具体的には、具体的には、
今どのような処理が行われ、その結果どうなるかを明確に説明することで、意図せずアカウントリカバリーフローに入ってしまったユーザーに気づきを促せます。
リアルタイムフィッシング攻撃で中継されてしまっても、フィッシング耐性のある身元確認方式を採用することで、アカウントリカバリーの完了を防ぐことができます。

 当人認証当人認証では、「パスキー認証およびフォールバックの認証方式を安全に実装すること」 はもちろん、身元確認と同様に 「サービスがユーザーに今何が行われているかを説明すること」 が重要です。

パスキー認証の正面突破: サービス提供者はパスキー認証の仕様を正しく理解し、安全な実装を目指す必要があります。
RPIDに関連するドメイン管理体制の不備を狙う攻撃: サービス提供者はドメインを安全に管理するとともに、clientDataJSONに含まれる 実際にパスキー認証処理が行われたオリジン の検証を行うことで、被害の軽減を図ることができます

Hybrid Transportの利用によるログインセッション取得を狙う攻撃: この種の悪用フローのリスクを、啓発やUI改善だけで抑制するのは困難です。これが大きな問題となるようであれば、Hybrid Transportによる認証を許可しないという判断も必要になりそうですが、その場合、本来の目的であるクロスデバイス/プラットフォームでの利便性をどう担保するか、検討が必要です。

フォールバックの認証方式を狙う攻撃: パスキー認証と既存の認証方式が混在している場合、フィッシング耐性のない認証方式が狙われる可能性は残ります。リスクベース認証との組み合わせで安全性を強化したり、ログイン直後にメールやPush通知を送ることで事後の検知を容易にしたりといった対策が求められます。

 セッション管理身元確認、当人認証の安全性を高めると同時に、ログインセッションの保護を意識することが重要です。サービスは安全な仕組みの採用に加え、不正利用を前提とした検知・事後対応策を用意する必要があります。 また、ユーザー自身がログインセッションの状態を管理できる機能を提供することも重要です。
XSSなど実装不備によるログインセッション窃取: サービス全体で既存のセッション管理機能の実装を再確認します。
マルウェア: ユーザーは利用する端末で基本的なセキュリティ対策を行い、マルウェアなどによる情報窃取のリスクを軽減します。
ドメイン管理の不備によるCookie情報へのアクセス: Cookieの発行対象が想定した範囲であることを確認し、ドメイン管理を徹底します。
その上で、サービス側はログインセッションを用いたリソースアクセスの際にもリスク判定や環境チェックを行い、窃取されたセッションが悪用された際に検知できる体制を整えることも重要です。

 利用環境の管理サービス側が直接コントロールできない領域だからといって、思考停止に陥るべきではありません。「サービス提供者は自身の管理外のリスクを認識し、ユーザーへの啓発を行うこと」 が重要となります。
パスキー利用可能端末を狙う攻撃: パスキー認証が普及した世界では、パスキーにアクセス可能な端末の重要性が増します。ユーザーは、端末がモバイルアプリだけでなく、多くのWebサービスへのログインを可能にする鍵であると同時に、不正利用された際の影響まで意識する必要があります。

パスキープロバイダのアカウントを狙う攻撃: パスワードマネージャーやプラットフォームアカウントの安全性はそれぞれ異なり、乗っ取られた際のリスクもユーザーの利用形態によって変わります。

フォールバックのID連携プロバイダのアカウントを狙う攻撃: プラットフォームアカウントが侵害された場合、パスキー管理、ID連携、さらにそのアカウントに紐づくメールアドレスにも影響が及びます。
いずれのケースでも、ユーザーはパスキーにアクセス可能な端末や、パスキー管理を委ねているアカウントのセキュリティ機能を最大限に活用し、これらのリスクを下げることが重要です。では、サービス側は何もできないかというと、そうではありません。不正利用が疑われた際に対象のパスキーを無効化できる機能を提供し、被害を最小限に抑える準備をしておくべきです。
さらに、プラットフォームアカウントに関しては、最近注目されている SSF (Shared Signals Framework) の活用が期待されます。
プラットフォームアカウントで発生したリスクイベント（ユーザーの状態変更など）を、連携サービスに通知する機能
Google Workspaceのような連携サービスからプラットフォームアカウントへリスクイベントを通知する機能
といっといった仕組みが登場しており、今後は、こうしたイベント通知によって被害発生時の迅速な事後対応が可能になることが期待されます。パスキー認証に関しても、パスキープロバイダがリスクイベントをサービスに通知することで、不正利用の疑いを早期に検知できるようになる未来に期待したいところです。

 まとめ本記事では、パスキー認証に対する脅威を整理し、その対策について考察しました。
脅威を3種類に分類: 脅威を(A)実装不備、(B)正規フローの悪用、(C)サービス管理外の3つの性質に分け、責任の所在と対策のアプローチを明確にしました。
さらに、機能単位で分類: 身元確認、当人認証、セッション管理、利用環境の管理に沿って脅威を再整理し、どの段階でリスクが存在するかを具体化しました。
対策、緩和策を考察: 各機能単位での対策の要点を示し、サービス提供者とユーザーがそれぞれ何をすべきかを整理しました。
パスキーは、パスワードが抱えていた多くの問題を解決する画期的な技術です。しかし、決して万能ではなく、パスキー自体への脅威にも目を向けるべき段階に来ています。実際の攻撃が広まる前に、サービスとユーザーそれぞれができる対策を進める必要があるでしょう。「完璧ではないからパスキーは使えない」と考えるのではなく、弱点となりうる部分を認識し、対策を講じることで、パスワードの時代から一歩進んだレベルでの安定期を迎える準備をしていきましょう。
ではまた。