【ITニュース解説】FIDO2 Account Recovery: The Gap Passwordless Rollouts Leave Open

FIDO2は、パスワードを使わない「パスワードレス認証」を実現するための技術の一つで、インターネット上のさまざまなサービスへのログインをより安全にするものだ。従来のパスワード認証では、パスワードが第三者に知られてしまうと、そのパスワードを使って不正にログインされる「フィッシング」などのリスクがあった。FIDO2認証では、スマートフォンや専用のセキュリティキーなど、ユーザーが所有する「認証器」を使ってログインするため、パスワード自体が存在せず、フィッシング攻撃が非常に困難になるという大きな利点がある。

しかし、FIDO2のようなパスワードレス認証には、新たな課題がある。それは「アカウントの復旧」だ。FIDO2の認証器は、サービス側にコピーできないような、ユーザー固有の秘密情報を持っている。この特性こそがFIDO2を安全にしている理由だが、逆に認証器を紛失したり、壊してしまったりした場合に、ユーザーが自分のアカウントを取り戻すのが非常に難しくなる。パスワードを忘れた場合には、サービス側が設定した「パスワードリセット」のような仕組みがあるが、FIDO2ではサービス側にパスワードのような共有の秘密情報が存在しないため、同じようにはいかない。

多くの組織がパスワードレス認証を導入する際、ログインの仕組みは最新で安全なものに更新する。しかし、アカウントの復旧経路については、従来のパスワード時代の仕組み、つまり「レガシーなメカニズム」をそのまま残してしまうことが多い。攻撃者はこの「ログイン経路と復旧経路のセキュリティレベルのギャップ」を見つけ出し、脆弱な復旧経路を狙って不正にアカウントを乗っ取ろうとする。これが、パスワードレス認証導入プログラムにおける典型的な失敗パターンと言える。

アカウント復旧にはいくつかの選択肢がある。

一つは「複数の認証器を登録する方法」だ。ユーザーは普段使う「メインの認証器」に加えて、万一の事態に備えて「バックアップの認証器」も登録しておく。理想的には、これらを異なる場所に保管し、メインの認証器が使えなくなった際にはバックアップの認証器を使ってログインし、アカウントを復旧する。これはFIDO2の関連仕様でも推奨される基本的な方法だ。しかし、この方法には「人間的な弱点」がある。バックアップ認証器は登録された後、引き出しにしまい込まれ、いざという時までその存在が忘れられたり、実際に使えるかどうかが確認されないまま放置されたりすることが多い。結果的に、本当に必要になった時に使えないという問題が発生しがちだ。

次に「リカバリーコード」という選択肢がある。これは、アカウント登録時にサービスから発行される、一度だけ使える使い捨てのコードだ。しかし、このリカバリーコードは実質的にはパスワードと同じ「共有秘密」であり、FIDO2がせっかく取り除いたフィッシング攻撃のリスクを再び持ち込んでしまう。そのため、リカバリーコードを安全に保つには、「使い捨てであること」「オフラインで保管すること」「短時間に何度も利用できないように制限をかけること」といった厳格な条件を守る必要がある。これらの条件が守られない場合、リカバリーコードは攻撃者にとって格好のターゲットとなりうる。

三つ目は「本人確認（Identity proofing）」だ。これは、ユーザーが直接サービス提供者と対面したり、ビデオ通話で身分証明書を提示して本人確認を受けたりするなど、独立した厳格なプロセスを経てアカウントを復旧する方法だ。例えば、公的な身分証明書を使った認証などがこれにあたる。この方法は最も強力でセキュリティレベルが高いが、その分、本人確認に手間やコストがかかり、サービス提供側にとっても運用が非常に高価になるという欠点がある。

そして最後に、多くの組織が採用しがちなのが「ヘルプデスクによるリセット」だ。これは、ユーザーがサポート窓口に連絡し、人間のオペレーターが本人確認を行った上で、新しいログイン情報を発行したり、アカウントをリセットしたりする方法だ。多くのパスワードレス導入プログラムが最終的にこの方法に行き着くが、実はここが最も大きなセキュリティリスクを抱える場所となる。なぜなら、ヘルプデスクのオペレーターは人間であり、悪意のある攻撃者が巧妙な「ソーシャルエンジニアリング」の手口を使ってオペレーターを騙し、アカウントのリセットをさせようとすることが多いからだ。

実際に、多要素認証（MFA）が導入されているシステムに対するアカウント復旧攻撃の多くは、このヘルプデスクを狙って行われる。攻撃者は、暗号技術で保護された認証要素を突破するのではなく、サポート窓口に連絡し、被害者の「従業員ID」「上司の名前」「最近の活動履歴」といった個人情報を提示する。これらの情報は、企業の外部公開情報や、過去のデータ漏洩事故で流出した情報などから簡単に入手できてしまう場合が多い。ヘルプデスク側は、決められたチェックリストに基づいてこれらの情報を確認し、ユーザーの本人確認ができたと判断すると、アカウントのリセットを実行してしまう。ヘルプデスクの担当者は、通常、「問題解決までの時間」で評価されるため、厳格な確認よりも迅速な対応を優先してしまう傾向があることも、攻撃者にとっては有利に働く要因となる。

このような状況を踏まえ、アカウント復旧のセキュリティを強化するための対策がいくつか考えられる。

まず、アカウント復旧を単なる「サポートチケット処理」としてではなく、「認証の儀式」として設計することが重要だ。ログイン時と同じくらい、あるいはそれ以上に厳格な本人確認と手順を設けるべきだ。

次に、バックアップ認証器を登録する際には、その認証器が実際に機能するかどうかを「登録時に検証」するようにする。登録しただけで放置され、いざという時に使えないという事態を防ぐためだ。

また、アカウント復旧のすべてのイベントについて、「何が」「いつ」「どのように」変更されたのかを記録に残し、さらに、その情報を攻撃者が制御できない別の通信チャネル（例えば、登録済みの別のメールアドレスや電話番号）を通じてアカウントの持ち主に通知する仕組みを導入する。これにより、不正な復旧があった場合に、速やかにアカウントの持ち主が気づけるようになる。

さらに、アカウントの種類によって復旧プロセスを分離することも重要だ。例えば、一般ユーザーのアカウントはヘルプデスクによる復旧を許可するとしても、システム管理者やセキュリティインフラを管理するような重要なアカウントについては、より厳格な「独立した本人確認」を必須とするべきだ。システムの管理者が、自分が管理する経路を使って自身の管理者アカウントを容易に復旧できてしまうような設計は避けるべきである。

そして、復旧プロセスは「フェイルクローズ」に設定するべきだ。これは、本人確認が完全にできない場合、すぐにアカウントをリセットするのではなく、復旧処理を「遅延させる」か、「厳重な監視下で処理する」という方針を意味する。つまり、不明確な状況では安全側に倒し、簡単にアカウントをリセットさせないようにするのだ。

FIDO2のようなパスワードレス認証は非常に強力だが、アカウント復旧に関しては、ログイン時のセキュリティレベルに匹敵する広く普及した標準はまだ確立されていないのが現状だ。もし、どこかの組織がFIDO2の復旧がログインと同じくらい安全だと主張しているならば、それは一般的な仕様ではなく、その組織独自の強固な対策について述べているに過ぎない。現実的な対応としては、重要度の高いアカウントについては可能な限り強力な復旧策を講じ、残存するリスクについては、それを明確に認識し、ユーザーにも分かりやすく伝えることが不可欠となる。