WebAuthnループ："パスワードレス"ハンドシェイクの一般的な論理的欠陥

サイバーセキュリティ業界は現在、数十年ぶりの大きな変革を迎えています：”共有秘密”（パスワード）から”非対称証明”（パスキー）への移行です。WebAuthn（FIDO2）標準に基づくパスキーは、フィッシングやクレデンシャルスタッフィング、記憶疲労に免疫のある未来を約束します。

しかし、2025年の採用拡大に伴い、危険な傾向が浮上しています。セキュリティ研究者やペネトレーションテスターは、”WebAuthnループ”と呼ばれる繰り返し現象を特定しています。これは、技術的に”フィッシャブル”でないプロトコルが、フロントエンドのリクエストとバックエンドの検証間のハンドシェイクにおける欠陥により脆弱性を生む場合に発生します。

この深掘りでは、技術的なミスマッチ、”ハンドシェイクトラップ”、そしてパスキーが解決を意図したセキュリティホールを再導入してしまう重要なリカバリーフォールバックについて解説します。

1. 現代のWebAuthnハンドシェイクの構造

欠陥を理解するには、まずハンドシェイクの仕組みを理解する必要があります。パスワードログインとは異なり、WebAuthnの儀式は、Relying Party（サーバー）、クライアント（ブラウザ/OS）、認証器（生体センサーやセキュリティキー）間の複雑な3者間交換を伴います。

登録フロー:

チャレンジ生成: サーバーが暗号学的にランダムなチャレンジとRelying Party ID（RP ID）を送信。

クレデンシャル作成: ユーザーのデバイスが新しい公開鍵・秘密鍵ペアを生成。

アテステーション: デバイスが公開鍵、クレデンシャルID、”アテステーションオブジェクト”（鍵が正当なデバイスで作成された証明）をサーバーに送信。

検証: サーバーが署名を検証し、公開鍵を保存。

認証フロー:

アサーションリクエスト: サーバーが新しいチャレンジを送信。

署名: 認証器が秘密鍵でチャレンジに署名。

アサーション検証: サーバーが保存された公開鍵を使って署名を検証。

この”ループ”は、開発者がこの複雑な暗号演算を標準のAPIフォーム送信のように扱うときに始まります。

2. 欠陥#1：オリジン & RP ID検証のギャップ

WebAuthnの最も強力な機能はOriginバインディングです。銀行.com用に作成されたパスキーはbänk.com（ホモグラフフィッシングサイト）では使えません。ブラウザはこれを厳格に守ります。ただし、ブラウザは契約の片側だけを強制します。

技術的ミスマッチ:

多くのバックエンド実装は、認証器から返されるclientDataJSONの検証を厳密に行いません。ハンドシェイク中、認証器は儀式が行われたオリジンを含むbase64エンコードされたオブジェクトを提供します。

論理的欠陥: バックエンドのコードが署名だけを確認し、clientDataJSON内のoriginフィールドの手動検証をスキップすると、”リレイされたフィッシング”の機会を生み出します。攻撃者は正当なWebAuthn儀式を悪意のあるドメイン経由でプロキシし、バックエンドが怠惰な場合、有効な署名を”無効”なoriginから受け入れる可能性があります。

2025年の修正: サーバー側で厳格なoriginホワイトリストを常に実装してください。複数ドメイン環境（例：brand.co.ukとbrand.com）では、新たに標準化されたRelated Origin Requests（ROR）を使用し、RP IDを安全に共有し、セキュリティレベルを下げずに済みます。

3. 欠陥#2：「静的チャレンジ」とリプレイ攻撃の脆弱性

WebAuthn実装でよくある誤りは、「チャレンジ」を単なるセッション識別子とみなすことです。暗号学的なナンスではありません。

技術的ミスマッチ:

チャレンジは以下の条件を満たす必要があります:

• サーバーで生成
• 高エントロピー（少なくとも16バイト）
• 短時間有効（時間制限付き）
• 一度だけ使用

論理的欠陥: 一部の開発者は、静的または予測可能なチャレンジ（例：ユーザーIDやタイムスタンプ）を使ってAPIの”ステートレス”性を簡素化します。チャレンジが再利用されたり複数セッションにまたがって持続すると、攻撃者は署名済みのアサーションを傍受し、リプレイ攻撃を仕掛けることが可能です。秘密鍵は不要で、ただ最後の有効な”証明”を再送信するだけです。

2025年の修正: “Challenge-Store-Verify”パターンを採用してください。チャレンジはRedisなどのサーバー側キャッシュに保存し、TTLは60〜120秒。署名検証後は即座にチャレンジをキャッシュから削除します。

4. 欠陥#3：「リカバリーパラドックス」（最弱のリンク）

これは”パスワードレス”エコシステムで最も重要な論理的欠陥です。パスキーは基本的にフィッシング不可能です。しかし、ユーザーがスマートフォンを紛失した場合はどうなるでしょうか？

技術的ミスマッチ:

“ロックアウト”を防ぐため、多くのサービスはアカウントリカバリーを実装しています。しばしば、従来の方法に頼ります:

• SMSワンタイムパスコード（OTP）
• メールのマジックリンク
• セキュリティ質問

論理的欠陥: SMS OTPのバックアップを提供することで、パスキーの実装は意味をなさなくなります。攻撃者はWebAuthnの暗号を破ることはせず、「デバイスを失った」とクリックし、SIMスワップやソーシャルエンジニアリングでSMSコードを傍受しようとします。

アカウントの”ループ”は最も弱いリンクに戻ります。2024年だけでも、22%以上の侵害は資格情報の乱用から始まり、これらの”バックアップ”メカニズムを狙ったものです。

2025年の修正:

複数のパスキーを登録させる: ユーザーにバックアップデバイス（例：ラップトップとスマホ）やハードウェアキー（YubiKey）を登録させる。

リカバリーコード: 一度だけ使えるリカバリーコードを提供し、オフラインで保管させる。

本人確認: 高額アカウントには、24時間の待機期間や手動のID確認を要求し、パスキーリセットを制限します。

5. 欠陥#4：アテステーションの怠慢 & “バーチャル認証器”問題

登録時に、サーバーは”アテステーション”を要求できます。これは、Apple、Google、Yubicoなどのデバイスメーカーからのデジタル証明書で、公開鍵が安全なエンクレーブやHSM内で生成されたことを証明します。

技術的ミスマッチ:

多くのライブラリは、アテステーションの検証が技術的に難しく、信頼できるルート証明書のリストを維持する必要があるため、”none”をデフォルトとします。

論理的欠陥: アテステーションを無視すると、サーバーは”パスキー”が実際にハードウェアに結びついた安全な鍵なのか、それとも攻撃者のスクリプト上で動作する”仮想認証器”なのかを知る手段を失います。iCloudのような”同期パスキー”はアテステーションを複雑にしていますが、エンタープライズ環境では厳格な検証が推奨されます。

2025年の修正: FIDO Metadata Service (MDS3)を利用してください。これは認証器の特性を集約したデータベースです。MDS3を確認することで、バイオメトリクスセンサーやハードウェアバックストレージを持つデバイスからのパスキーかどうかを検証できます。

6. 欠陥#5：フロントエンドとバックエンドの同期不良と”成功と失敗の錯覚”

WebAuthnは複数ステップのプロセスです。ReactやNext.jsで構築された多くのSPA（シングルページアプリケーション）では、フロントエンドがnavigator.credentialsの呼び出しを担当し、バックエンドが検証を行います。

技術的ミスマッチ:

よくあるバグは、フロントエンドが認証器のレスポンスを”検証”し、その後”ユーザーが署名した”とだけ伝え、”IDをログインさせる”だけです。

論理的欠陥: バックエンドは”成功”の信号を信用してはいけません。2024年のいくつかのCVEs（特にNext.jsの認証ラッパーに影響）では、攻撃者がフロントエンドのAPI呼び出しを傍受し、”成功”ステータスを注入して、実際の暗号署名を検証せずにバックエンドが受け入れるケースが見つかっています。

2025年の修正: バックエンドが唯一の情報源です。フロントエンドの役割は、ブラウザからサーバーへ生のバイト列を運ぶことだけです。サーバーがauthDataの解析、clientDataJSONのハッシュ化、RS256やES256の署名検証を行います。

7. “ループを閉じる”ための開発者チェックリスト

真に安全なパスレスシステムを構築するには、基本的なチュートリアルを超え、これらの論理的欠陥に正面から取り組む必要があります:

厳格なオリジン検証: 署名だけでなく、clientDataJSONを解析し、オリジンがあなたのドメインと完全一致していることを確認してください。

ステートレスは危険: チャレンジはランダムでサーバー生成、使用後に消費されるべきです。

“パスキー優先” UX: ユーザーにパスキーがあれば、デフォルトで”パスワード”フィールドを表示しない。これにより、フィッシングでパスワードを入力させるリスクを防ぎます。

フォールバックの監査: SMSをバックアップとして使う場合は、それを”低セキュリティ状態”とみなしてください。ユーザーにメールで通知し、48時間以内にアカウントの権限を制限します。

検証済みライブラリを使用: 独自実装は避け、SimpleWebAuthn、FIDO2-lib、Clerk、Auth0、Passkeys.ioなどの信頼性の高いライブラリやサービスを利用してください。これらはMDS3やorigin検証を標準でサポートしています。

結論：未来は”パスワードレス”、論理的に無意味ではない

パスキーはセキュリティにおいて大きな飛躍をもたらしますが、”設定して放置”できる解決策ではありません。WebAuthnループは、最も脆弱な部分はブラウザとサーバー間のハンドシェイクや”安全”から”リカバリー”モードへの移行にあることを教えています。

フロントエンドの便利さとバックエンドの厳格さの間の技術的ミスマッチに焦点を当てることで、開発者は”パスワードレス”の約束が本当に実現することを保証できます：あなたのアイデンティティがあなたに属し、他者には属さないウェブを実現するために。