パスキーの脆弱性「Pass-ta-key」が暴く認証の盲点とエンジニアの責務

「パスワードレスこそがセキュリティの最終解」――我々エンジニアは長らくそう信じ、クライアントや社内システムにパスキーの導入を推奨してきた。しかし、パロアルトネットワークスの脅威研究部門「Unit 42」が報告した「Pass-ta-key」という攻撃手法は、その甘美な幻想を冷徹に打ち砕くものだ。現場のエンジニアにとって、これは単なる脆弱性報告ではない。我々が「安全」と信じて実装してきた認証基盤の根幹に、マルウェアという物理的な侵入者がいとも簡単に土足で踏み込めるという、極めて生々しい現実を突きつけられたのだ。

今回報告された「Pass-ta-key」は、Googleパスワードマネージャーの同期機能という、利便性の裏側に潜む実装上の欠陥を突いている。具体的には、被害者のWindows端末がマルウェアに感染していることを前提とし、攻撃者はパスキーの暗号を解読するような高度な数学的アプローチをとらない。そうではなく、正規のGoogle Chromeが行う認証処理そのものを模倣し、あたかも本人が操作しているかのように振る舞うのだ。これは、認証の「仕組み」をハックするのではなく、認証の「プロセス」を乗っ取るという、極めて狡猾な手法である。

Unit 42の検証によれば、GitHubのような堅牢なサービスでは不正ログインを拒否できた一方で、eBayではログインに成功したという事実は、我々に何を物語っているだろうか。それは、パスキーという規格がどれほど優れていても、ウェブサービス側の実装レベルで「指紋認証やPIN入力が本当に行われたか」を厳密に検査していない限り、脆弱性は残るということだ。我々エンジニアは、ライブラリやAPIを呼び出すだけで満足してはならない。その裏側で、認証の正当性がどのように担保されているのか、端末の再登録プロセスにどのようなバックドアが存在し得るのかを、コードレベルで再検証する必要がある。この「Pass-ta-key」は、パスキーがフィッシング耐性を持つことは事実だが、マルウェア耐性とは別次元の話であることを、痛烈な教訓として我々に突きつけている。

「Pass-ta-key」には、その深刻度に応じて3つの段階が存在する。最も基本的な攻撃では、マルウェアが認証処理を代行することで、本来必要な生体認証をバイパスする。さらに深刻な「Silver Pass-ta-key」では、攻撃者が被害者の端末を「本人確認済み」として再登録し、永続的なアクセス権を奪取する。そして最も恐ろしい「Golden Pass-ta-key」は、Googleパスワードマネージャーが暗号化して保存しているパスキーの秘密鍵を、メモリやログから直接抜き出すというものだ。Googleは既にログの問題を修正したが、端末再登録時の一時的なメモリ残存リスクは依然として残っている。

この事態を前にして、我々エンジニアが取るべきスタンスは「パスキーを捨てること」ではない。むしろ、パスキーの普及に伴い、攻撃者のターゲットが「パスキーそのもの」から「パスキーを許可する端末の管理手続き」へとシフトしているという構造変化を理解することだ。以下の表は、今回の攻撃手法が狙う脆弱性のポイントを整理したものだが、これを見れば明らかなように、防御の主戦場はもはやネットワーク境界ではなく、エンドポイントのセキュリティと、認証プロバイダーの管理ロジックに移行している。

我々が明日から行うべき対策は、単なるOSのアップデートだけではない。自社で認証基盤を構築、あるいは利用しているエンジニアは、パスキーの登録フローにおいて「本当にその端末が信頼できるのか」を判断するロジックを再設計しなければならない。例えば、新規端末登録時には、既存の信頼済み端末からの承認を必須にする、あるいはリスクベース認証を組み合わせるなど、多層的な防御が不可欠だ。マルウェア感染を前提とした「ゼロトラスト」の精神を、パスキーの実装にも適用する時が来ている。パスキーは魔法の杖ではない。それはあくまで、適切に管理された環境下で初めて機能する、強力な鍵の一つに過ぎないのだ。

最後に、我々エンジニア自身に問いかけたい。私たちは「パスワードレス」という言葉に酔いしれ、認証の複雑さをブラックボックス化しすぎてはいないだろうか。今回の脆弱性は、Googleという巨大なプラットフォームであっても、実装の隙を突かれれば認証の根幹が揺らぐことを証明した。これは、我々が開発するアプリケーションにおいても同様のことが起こり得るという警告である。もし、あなたの開発するサービスで、パスキーの登録フローが「ただ便利だから」という理由だけで設計されているなら、それは今すぐ見直すべきだ。

明日から取るべき具体的なアクションは明確だ。まず、自社サービスにおけるパスキーの登録・認証フローを監査せよ。特に、端末の追加や復旧プロセスにおいて、攻撃者が介入できる余地がないかを確認すること。次に、エンドポイントセキュリティの重要性を再認識せよ。パスキーがどれほど強固でも、OSがマルウェアに汚染されていれば、そのセキュリティは無力化される。ユーザーに対して、OSやブラウザの更新を促すだけでなく、不審なソフトウェアの実行を制限するような教育や、EDR（Endpoint Detection and Response）の導入を推奨することも、我々エンジニアの責務である。

我々は、利便性とセキュリティという永遠のトレードオフの中で、常に綱渡りをしている。パスキーは確かにパスワードよりも安全だが、それは「攻撃者が狙う場所が変わった」ことを意味するに過ぎない。技術の進化は、常に攻撃の進化を伴う。我々が直面しているのは、認証技術の完成ではなく、新たな戦場の幕開けである。あなたは、この変化に対して、単なる「仕様の利用者」として甘んじるのか、それとも「認証の守護者」として、その実装の深淵までを見通すエンジニアであり続けるのか。この問いに対する答えこそが、これからの時代を生き抜くエンジニアの価値を決定づけるだろう。