シェア
はてブ
2025年3月25日に開催されたオンラインイベント「パスキーで変わる認証設計 ritouさんに聞く実装における課題とベストプラクティス」。本イベントでは、OpenID ファウンデーション・ジャパンのエバンジェリストであるritouさんをお招きし、「パスキー導入の課題と現状のプラクティス、今後の展望」というテーマでご講演いただきました。
ご参加者からも「パスキー導入について理解が深まった」「認証の歴史やユーザー認証の変遷が整理できた」と好評で、イベント中にも多くの質問が寄せられました。当日、可能な限り回答をいただきましたが、時間の関係で回答しきれなかった質問も残りました。
本記事では、通常そのまま終わってしまうことが多いこうした未回答の質問について、ご登壇者の協力のもと、イベント後に回答いただいた内容をお届けします。また、イベント中に触れた質問についても、補足を交えてご紹介します。
イベント参加者の皆さまはもちろん、当日参加できなかった方も、ぜひ本編のアーカイブ動画と併せてご覧いただき、パスキーへの理解を深めるためにご活用ください。
※質問文は内容に影響を与えない範囲で、一部表現を調整しています
Q&A
Q.パスキーは、第三者による中間者攻撃での認証突破は出来ますか？
「第3者による中間者攻撃」が正規のサービスとは異なるドメインのフィッシングサイトで行われる場合、パスキーおよびFIDO認証の特性（正規のサービスが指定したドメインと実際にアクセスしているドメインが異なるので認証処理が動かない）により突破は不可能と言えます。
Q.パスキーはユーザーに理解されていると感じますか？パスキー導入によって、ログインできない、使い方がわからない、といったユーザーからの問い合わせは増えましたか？
まだまだ理解されているとは思いません。自分のサービスではパスキーを前面に押し出すことなく、オプショナルの方式として入れていく選択をしたので大きな混乱は起きていません。
しかし、特定機能にパスキーを必須化したサービスにおいてはクロスデバイス、クロスプラットフォームで使えないケースに直面し、ネガティブな反応が起こっているユーザーがいることが見て取れます。
まだまだ啓発は必要だろうと思いつつ、どこまで知ってもらうべきかは課題でしょう。技術を理解してもらえるのは開発者までかなというところで、パスワードよりも安全な仕組みでパスワードマネージャーやそれが動くデバイスに依存するという共通認識が必要そうです。
Q.Identifier-Firstパターンのスライドについて、パスキーが登録済みかどうかは誰が知っているのでしょうか？
サービス側はあるユーザーがパスキーを登録していることを知っています。ただし、ログインしようとしている環境で登録済みのパスキーが利用可能かどうかはわかりません。
モバイル端末でパスキーを登録し、PC環境からパスキー認証を要求となったときに使えないという状況が考えられます。サービスはログインしようとしている環境を見極めてパスキー認証を要求すべきかの判断が必要となるでしょう。
Q.プラットフォームアカウント同士のパスキーの同期が難しいというのが、前提知識なく理解できなかったです。何かよいリファレンスはありますか？
パスキーの同期は基本的に「パスワードマネージャー」により行われます。細かい違いはあるものの、パスワードマネージャーはその提供元のアカウント（Google パスワードマネージャーであればGoogle アカウント、AppleのパスワードアプリであればAppleアカウント、サードパーティー製のものはそのアカウント）を中心にして行われます。
今後、プラットフォームアカウント単位で同期する範囲は広がることが想像できますが、Google パスワードマネージャーとAppleのパスワードアプリの間でパスキーが同期されることは難しいということです。
Q.パスキー認証はOpenID ConnectやOAuthとの併用は可能でしょうか？
OIDCの登場人物は、大まかに「認証を要求する側」と「認証結果を利用する側」の2種類に分類できます。 前者が認証方式としてパスキーを採用するケースもありますし、既に「Googleでログイン」などを利用しているサービスがパスキー認証を採用するケースも考えられます。よって、パスキー認証とID連携のしくみは併用可能と言えます。
Q.「パスキー認証が必要だ」というビジネス上の判断がされるためにはどうすればいいでしょうか？自社のプロダクトがフィッシング被害に遭うしかないのでしょうか？
危機感を覚えるには実害が一番かもしれませんが、実害が出てからの対応は特に開発者の負担が大きいのでおすすめはしません。利便性向上などのモチベーションを実際の導入につなげるためには認証機能を含むID管理やID基盤全体のプランを考えて行く必要があるでしょう。
Q.不正ログインがあった場合はユーザーはどのような対応をするのがいいでしょうか？ 不正ログインがあったことが確定している場合はサービス側も取るべき手順を示しているはずなのでそれに従いましょう。
その前の「不正ログインが疑われる場合」においては、既存のセッション一覧を確認して第3者がログイン状態になっていないかを確認して必要ならばログアウトさせることが重要です。ユーザー単位のセキュリティイベントログを確認することでどのタイミングで不正ログインが行われ、どのような被害が発生しているかをユーザー自身で認識できることも安心につながるでしょう。
そのうえで、今後の不正ログインを防ぐための設定追加などを行う必要があります。当然ながらサービス側がこれらの機能を提供していなければならないので、今回の資料では上記2機能について紹介させていただきました。
Q.IT技術に明るくないユーザーを対象にしたWebサービスにパスキーを導入する際、エラー時のケアが課題になるかと思います。このようなエンドユーザーに対するケアについて何かノウハウがあれば、もしくはガイドラインで提供されていればご教示いただきたいです。
エラーを表示しない努力が必要と説明させていただきましたが、どのような仕組みでも一定の割合でエラーに遭遇することを避けられないでしょう。 このエラーが出たときにどのようなアクションが求められるかを適切に説明すること、画面で説明できない場合もヘルプや簡易的なチャットボットなどで補足するといった取り組みも重要でしょう。このあたりを扱うガイドライン等はあまり見かけたことがないのですが、どなたかご存知の方がいらしたら教えてください。
Q.偽のQRコード画面を表示してパスキー情報を取得すれば、認証突破は出来ますか？
他の質問にも関連しているのですが、Hybrid TransportではQRを表示して認証を要求している環境とパスキーを管理している端末がBLE接続可能な距離であることを求められます。物理的な接近が必要な分、オンラインだけで完結しないのです。 よって、今回紹介したような攻撃では物理的に近いところに攻撃者の管理下にある端末が存在する必要があります。
Q.先ほどご説明いただいたHybrid Transportの悪用攻撃は、BLEを使うことである程度は防ぐことができるものでしょうか？（攻撃者とターゲットが近距離にいる場合のみ攻撃成功）
ご指摘の通り、接続対象を近接の端末に限定することでリモート環境における悪用を防いでおります。 手元のモバイル端末を利用してパスキー認証を成功させるためには、QRコードによる接続（や接続したことのある場合は通知を送るなど）しつつ、BLE接続をする必要があります。
その前提の上で、既存のよくあるアクション（フォローだったりハッシュタグ投稿）だと思わせつつ、近接端末を用いてログインさせることでログインセッションを狙う攻撃が実現可能なことを紹介させていただきました。
アーカイブ動画
イベント本編は、アーカイブ動画を公開しています。こちらもあわせてご覧ください。
