【ITニュース解説】Passkey enrollment security in practice

Passkeyは、従来のパスワードに代わる新しい認証方法として、フィッシング詐欺などの脅威からユーザーを守り、ログイン時のセキュリティを大きく向上させる手段として期待されている。しかし、Passkeyそのものの安全性とは別に、その「登録」プロセスに脆弱性があると、新たなセキュリティ上の問題が発生する可能性があると指摘されている。

これまでのパスワード認証では、攻撃者がパスワードを盗んでアカウントに不正アクセスした場合、ユーザーがパスワードをリセットすれば、盗まれたパスワードは無効になり、アカウントの安全は回復できた。しかしPasskeyの場合、状況は少し異なる。もし攻撃者が、パスワードやSMSによるワンタイムパスワード、あるいはアカウント回復プロセスなど、比較的セキュリティが弱い経路を使って一度でもアカウントに侵入できたと仮定する。このとき攻撃者は、不正に侵入したアカウントに自分自身のPasskeyを登録してしまう可能性がある。

攻撃者が登録したPasskeyは、攻撃者自身が管理する秘密鍵と結びつき、アカウントに紐付けられてしまう。従来のパスワードとは異なり、この攻撃者が登録したPasskeyは、ユーザーがパスワードをリセットしても削除されない。つまり、パスワードをリセットしても、攻撃者は自分のPasskeyを使って引き続きアカウントにアクセスできてしまうという深刻な事態が起こり得るのだ。これは単なる理論上の話ではなく、実際にMicrosoft 365に対するフィッシングキャンペーンで、攻撃者がユーザーをだまして偽のPasskey登録をさせ、自分たちの認証情報をアカウントに紐付けた事例が報告されている。この手口はすぐにキット化され、広く利用されるようになった。

Passkeyのセキュリティ設定には、「userVerification: "required"」という項目がある。これは、認証器をローカルでロック解除するために、例えば指紋認証やPINコードの入力が必要であることを意味する。この設定があれば安全だと考えるのは一般的な誤解であり、注意が必要だ。なぜなら、この設定は「誰かが認証器をロック解除した」ことを証明するだけで、「その認証器が正当なユーザーのものである」ことを証明するわけではないからだ。Passkeyの登録セキュリティを評価する上で、この違いは非常に重要になる。

より安全な運用のためには、新しいPasskeyを作成する際には、発行しようとするPasskey自体と同等、あるいはそれ以上の強力な認証をユーザーに求めるべきである。例えば、フィッシングに弱い要因（例：パスワード）で開始されたセッションだけを根拠に、新たなPasskeyの登録を許可するのは危険だ。

安全なPasskey登録経路を構築するためには、いくつかの対策が考えられる。まず、Passkeyを作成する前に、別途強力な「ステップアップ認証」を求めることだ。これは、例えば別の認証要素（生体認証、ハードウェアキーなど）による追加認証を意味する。次に、アカウント回復プロセスを通じてPasskeyを登録する場合、より厳格なチェックを実施する必要がある。また、セキュリティが比較的弱い方法で確立されたセッション（弱いセッション）と、強力な方法で確立されたセッションを区別し、弱いセッションからのPasskey登録には特別な対応をすべきだ。さらに、新しい認証情報が追加された際には、登録に使われたセッションとは独立した別のチャネル（例えば、登録済みメールアドレスへの通知）を通じて、必ずユーザーに通知を行うことが重要となる。Passkeyの採用を促進するために、バックグラウンドで自動的にPasskeyが作成されるような仕組みも増えているが、これも同様に、目に見える登録フローと同じ厳格な認証基準を適用する必要がある。

共有デバイス環境でのPasskey登録もまた、セキュリティ上の課題を抱えている。もし企業や公共施設にある共有のOSプロファイルや端末にプラットフォームPasskeyが保存されてしまうと、そのプロファイルをロック解除できる誰もが、そのPasskeyを使ってアカウントにアクセスできてしまう可能性がある。WebAuthnの仕様では、デバイスが共有されているかどうかを確実に識別する機能は提供されていない。デバイスの管理状況、以前の強力な利用履歴、アカウント切り替えパターン、ブラウザやデバイスのフィンガープリント、IPアドレスや位置情報といった情報は、共有デバイスの可能性を示す有用な手がかりにはなるが、これらだけでデバイスの所有者を完全に証明することはできない。

このため、共有デバイスにおけるPasskeyの登録ポリシーを確立することが重要になる。環境をリスク別に分類し、それに応じて登録経路を変更するのだ。例えば、キオスク端末や共有される可能性が高いマシンでは、そのデバイスにPasskeyを保存するプラットフォームPasskeyの作成を抑制し、代わりにユーザーのスマートフォンを使ったクロスデバイス登録や、持ち運び可能なセキュリティキーの利用を推奨するといった対策が考えられる。

どれほど強固な防御策を講じても、Passkeyの登録プロセスを狙った攻撃が完全に防ぎきれるとは限らない。だからこそ、Passkeyのセキュリティ対策においては、登録後の監視と対応も非常に重要になる。Passkeyが新規作成された際には、リスクスコアが特定のしきい値を超えたかどうかに関わらず、必ずセキュリティ通知を発行すべきである。この通知は、Passkeyの登録に使われたセッションとは独立した経路（例えば、登録メールアドレスや別の認証アプリ）を通じて行われるべきであり、どのプロバイダーのPasskeyが、どのブラウザ、どのOSで、いつ作成されたかといった、ユーザーが識別できる具体的な情報を含めることが望ましい。セッション中に表示されるバナーは便利なユーザー体験だが、攻撃検出のための独立した通知としては不十分である。

また、ユーザーやサポートチームが、現在どのアカウントにどのPasskeyが登録されているかを一覧で確認し、それぞれを明確に区別し、疑わしいPasskeyを迅速に削除できるような「Passkeyインベントリ」と「取り消し（Revocation）」機能が不可欠だ。Passkeyに関するセキュリティインシデントが発生した場合の対応の中心は、まずアカウントに対する変更をロックダウンし、アクティブなセッションをすべて取り消すことである。その上で、他の認証要素をリセットするという手順を踏むべきだ。パスワードのリセットから始めて、問題が解決したと安易に考えるべきではない。

この一連の議論から得られる最も重要な教訓は、Passkeyが、より脆弱なサインイン経路やアカウント回復経路を自動的に保護するわけではないということだ。アカウント全体の本当のセキュリティ境界は、結局のところ、そのアカウントが受け入れる最も脆弱な経路によって決まるのである。Passkeyを導入する際には、登録プロセスから登録後の管理、インシデント対応に至るまで、システム全体のセキュリティを包括的に見直すことが求められる。