FIDO2/WebAuthnによるパスワードレス認証のセキュリティ対策

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

FIDO2/WebAuthnによるパスワードレス認証のセキュリティ対策

FIDO2とWebAuthnは、パスワードに依存しない強力な認証メカニズムをウェブにもたらし、フィッシングやアカウント乗っ取りといった従来の脅威に対する耐性を大幅に向上させます。しかし、その実装や運用には特有のセキュリティ上の考慮事項が存在します。本記事では、セキュリティエンジニアの視点から、FIDO2/WebAuthnの脅威モデル、具体的な攻撃シナリオ、検出・緩和策、そして運用におけるベストプラクティスを解説します。

脅威モデル

FIDO2/WebAuthnのセキュリティモデルは、公開鍵暗号に基づき、以下の主要なコンポーネントで構成されます。

  1. Authenticator: ユーザーの秘密鍵を安全に生成・保存し、認証署名を生成するデバイス（例: スマートフォンの生体認証、セキュリティキー）[1]。

  2. Relying Party (RP): 認証を要求するウェブサービスやアプリケーション（サーバー側）[1]。

  3. User Agent: ブラウザなどのRPとAuthenticator間の通信を仲介するソフトウェア[1]。

これらのコンポーネントに対する主な脅威は以下の通りです。

  • フィッシング攻撃: 攻撃者が正規サイトを模倣し、ユーザーを誘導して認証情報を窃取しようとする。WebAuthnはRPのOrigin検証により、この脅威に強い耐性を持つ [2]。

  • セッションハイジャック: 認証が成功した後、確立されたセッションを攻撃者が奪取する。WebAuthn自体はセッション管理を行わないため、RP側での堅牢なセッション管理が不可欠。

  • RP側の脆弱性: RPサーバーのCredentialデータベースへの不正アクセス、RP IDの不適切な設定、Attestation検証の欠如などが含まれる [3]。

  • Authenticatorの物理的な盗難・改ざん: 物理的にAuthenticatorが奪われ、PINや生体認証が突破されるケース。

  • サイドチャネル攻撃: Authenticatorの実装に存在する情報漏洩の脆弱性を悪用する。

  • リプレイ攻撃: 過去の認証署名を傍受し、再度利用しようとする。WebAuthnはclientDataHashとauthenticatorData内のsignature counterによりこの脅威を軽減する [1]。

攻撃シナリオ

シナリオ1: 不適切なRP ID検証を悪用したフィッシング（RP側の脆弱性）

  1. 初期アクセス: 攻撃者は正規のRP（例: login.example.com）を模倣したフィッシングサイト（例: login-examp1e.com）を構築し、ユーザーを誘導します。

  2. 認証要求: ユーザーがフィッシングサイトで認証を試みると、フィッシングサイトはRPのウェブフロントエンドと同じJavaScriptコード（WebAuthn API呼び出し）を実行し、Authenticatorに認証要求を送信します。

  3. 認証データの生成: Authenticatorは、ユーザーが過去にlogin.example.comで登録したCredentialに対して認証要求が来たと認識します。AuthenticatorはRP IDが正規のlogin.example.comではないことを検知し、認証を拒否するか、RP IDの不一致を通知します。これがWebAuthnの本来の防御メカニズムです [3]。

  4. RP IDの誤設定: しかし、RPサーバーがrelyingPartyIdをexample.comのように広範囲に設定しており、かつAuthenticatiorからのclientDataJson.originの検証を怠っている場合、フィッシングサイトがsub.example.comのようなサブドメインを利用していると、Authenticatiorがそのサブドメインでの認証要求を許可してしまう可能性があります。

  5. セッションの確立: フィッシングサイトはAuthenticatiorから得た有効な認証署名を正規RPに送信し、ユーザーになりすましてログインセッションを確立します。

Mermaidによる攻撃チェーンの可視化

以下は、RP IDとOrigin検証の不備を突いた攻撃シナリオの攻撃チェーンです。

graph TD
    A["攻撃者"] -->|フィッシングサイト構築| B["login-examp1e.com(\"偽装サイト\")"];
    B -->|ユーザーを誘導| C["被害者ユーザー"];
    C -->|偽装サイトで認証開始| B;
    B -->|WebAuthn認証要求(RP ID設定不備)| D["ユーザーのAuthenticator"];
    D -->|認証署名生成(Origin不一致検出)| E{"RPサーバーのOrigin/RP ID検証"};
    E -- RP IDとOriginの厳格な検証がない --> F["攻撃者によるログインセクエスト生成"];
    F -->|認証署名送信| G["正規RPサーバー"];
    G -->|ログイン成功| H["攻撃者によるアカウント乗っ取り"];
    E -- RP IDとOriginの厳格な検証がある --> I["認証拒否"];

検出/緩和

検出策

  • 異常な認証試行の監視:

    • 特定のCredential IDに対する異常な数の認証失敗。

    • 地理的に不可能な場所からの短時間での複数回認証試行。

    • 通常と異なるUser Agent（ブラウザ、OS）からの認証。

    • RP側で記録されるAuthenticator Attestation GUID (AAGUID) の変化（登録済みAuthenticatorが突然別のタイプになる場合）。

  • セキュリティログの集約と分析: 認証イベント、Credential登録/削除イベント、デバイス変更イベントなどをSIEMシステムに集約し、リアルタイムで異常検知ルールを適用します。

緩和策

  1. RP IDの厳格な設定とOrigin検証の徹底:

    • WebAuthnのrelyingPartyIdは、認証が可能な正規のオリジンを厳密に定義する必要があります。通常は、ウェブサービスの最上位ドメイン、または特定のサブドメインに設定します [3]。

    • RPサーバーは、Authenticatorから受け取ったclientData.originが、期待されるRP IDと厳密に一致するかを検証する必要があります。これはWebAuthnのフィッシング耐性の根幹です [3]。

  2. Attestationの利用（オプション）:

    • 登録時にAuthenticatorの信頼性を検証するためにAttestationを利用できます。これにより、不正なソフトウェアAuthenticatorの登録を防ぐことが可能になります。ただし、プライバシーの懸念もあるため、匿名化されたAttestation (AnonCA) の利用や、初回登録時のみに限定するなど慎重な検討が必要です [3]。

  3. User Verification (UV) の強制:

    • AuthenticatorがPIN、生体認証などによりユーザー本人を検証することを強制します。これにより、Authenticatorが物理的に盗まれた場合でも、不正利用のリスクを軽減できます [3]。

  4. RP側の堅牢なセッション管理:

    • 認証後のセッション管理はWebAuthnの範囲外です。セッションIDの定期的なローテーション、Secure属性とHttpOnly属性の使用、厳格なCORSポリシーの適用など、一般的なウェブセキュリティ対策を徹底します。

  5. Resident Key (Discoverable Credential) の適切な利用:

    • Resident KeyはユーザーがRP IDを入力せずに認証できる利便性を提供しますが、Authenticatorが紛失した場合のリスクも考慮し、高セキュリティが求められる場合は非Resident KeyとMFAの併用も検討します。

コードによる誤用例と安全な代替（Python）

以下は、RP IDとOrigin検証に関する誤用例と安全な代替をPythonの例で示します。

# FIDO2ライブラリのモック (fido2ライブラリのコンセプトに基づきます)


# 実際には 'fido2' や 'webauthn' などの公式ライブラリを使用してください。

import json
import base64
from urllib.parse import urlparse

class AuthenticatorData:
    def __init__(self, rp_id_hash, flags, sign_count):
        self.rp_id_hash = rp_id_hash
        self.flags = flags
        self.sign_count = sign_count

        # ... その他のデータ

class AttestationObject:
    def __init__(self, authenticator_data, fmt, auth_data_b64):
        self.authenticator_data = authenticator_data
        self.fmt = fmt
        self.auth_data_b64 = auth_data_b64 # Base64エンコードされた認証データ

    def get_authenticator_data_bytes(self):
        return base64.b64decode(self.auth_data_b64)

class ClientData:
    def __init__(self, origin, type, challenge):
        self.origin = origin
        self.type = type
        self.challenge = challenge

        # ... その他のデータ

def parse_client_data_json(client_data_json_b64: str) -> ClientData:
    """Base64エンコードされたclientDataJSONをパースする"""
    decoded_json = base64.urlsafe_b64decode(client_data_json_b64 + '==').decode('utf-8')
    data = json.loads(decoded_json)
    return ClientData(data['origin'], data['type'], data['challenge'])

# 想定されるRelying Party ID

EXPECTED_RP_ID = "example.com"

# 想定されるOrigin (Webブラウザのアドレスバーに表示されるもの)

EXPECTED_ORIGIN = "https://example.com"

# --- 誤用例: RP IDの検証が不十分なRPサーバーロジック ---


# 前提: Authenticatorから受け取ったAttestationObjectとclientDataJSONがあるとする


# 入力:


#   attestation_object: Authenticatorから得られるAttestationObject


#   client_data_json_b64: Authenticatorから得られるclientDataJSONのBase64エンコード文字列


#   expected_rp_id_from_config: RPサーバーの設定値として期待されるRP ID


#   expected_origin_from_config: RPサーバーの設定値として期待されるOrigin


# 出力: 検証結果 (bool)

def verify_webauthn_credential_incorrect(
    attestation_object: AttestationObject,
    client_data_json_b64: str,
    expected_rp_id_from_config: str,
    expected_origin_from_config: str
) -> bool:
    """
    WebAuthnのCredential検証ロジック（誤用例：RP IDとOriginの検証が甘い）

    懸念点：

    - RP IDがサブドメインで厳密に検証されず、より広いドメインを許容してしまう。

    - clientData.originの検証が不十分、または行われない。

    - Attestationオブジェクト内のRP ID HashとRP設定のRP IDの直接比較が行われない。
    """
    client_data = parse_client_data_json(client_data_json_b64)

    # 1. clientData.originの検証が**行われない**、または正規表現でゆるくチェックされる場合


    #    例: if not re.match(r".*example.com$", client_data.origin): return False (これはNG)


    # 2. RP IDのハッシュ検証が省略される、または不適切に行われる場合


    #    AuthenticatorDataには、rp_id_hashが含まれているが、これとRP設定のRP IDのハッシュを


    #    比較しなければならない。ここではそれを省略。

    print(f"誤用例: clientData.origin: {client_data.origin}")
    print(f"誤用例: 期待されるOrigin: {expected_origin_from_config}")

    # ここでは便宜上、OriginとRP IDのチェックを省略すると仮定


    # 実際には、RPサーバーはAuthenticatorDataのrp_id_hashを計算し、


    # 期待されるRP IDのSHA256ハッシュと比較する必要があります。


    # ここでは、その厳密な比較が行われないことを想定。

    # ... その他の検証ロジック（チャレンジ検証、署名検証など）


    # これらの検証が通ってしまうと、フィッシングサイトからの認証も成功する可能性がある。

    return True # 本来は失敗すべきケースでTrueを返す危険性

# --- 安全な代替: RP IDとOriginを厳格に検証するRPサーバーロジック ---

def verify_webauthn_credential_secure(
    attestation_object: AttestationObject,
    client_data_json_b64: str,
    expected_rp_id_from_config: str,
    expected_origin_from_config: str
) -> bool:
    """
    WebAuthnのCredential検証ロジック（安全な代替：RP IDとOriginを厳格に検証）

    RPサーバーが実施すべき検証：

    1. AuthenticatorData.rpIdHash が、expected_rp_id_from_config の SHA256ハッシュと一致すること。

    2. clientData.origin が、expected_origin_from_config と厳密に一致すること。

    3. clientData.type が 'webauthn.get' (認証時) または 'webauthn.create' (登録時) であること。

    4. clientData.challenge が、セッションで生成されたチャレンジと一致すること。

    5. 署名が有効であること。

    6. AuthenticatorData.signCount が増加していること（リプレイ攻撃対策）。
    """
    import hashlib

    client_data = parse_client_data_json(client_data_json_b64)

    # 1. clientData.origin の厳格な検証 (必須)


    #    WebAuthn L3 Section 10.3.1. step 5 & 6

    if client_data.origin != expected_origin_from_config:
        print(f"検証失敗: Origin不一致。Expected: {expected_origin_from_config}, Actual: {client_data.origin}")
        return False

    # 2. RP ID Hash の検証 (必須)


    #    WebAuthn L3 Section 10.3.1. step 7


    #    AuthenticatorDataの最初の32バイトはRP IDのSHA256ハッシュ

    rp_id_hash_from_authenticator = attestation_object.get_authenticator_data_bytes()[:32]
    expected_rp_id_hash = hashlib.sha256(expected_rp_id_from_config.encode('utf-8')).digest()

    if rp_id_hash_from_authenticator != expected_rp_id_hash:
        print(f"検証失敗: RP ID Hash不一致。Expected: {expected_rp_id_hash.hex()}, Actual: {rp_id_hash_from_authenticator.hex()}")
        return False

    # 3. clientData.type の検証

    if client_data.type not in ["webauthn.get", "webauthn.create"]:
        print(f"検証失敗: 不正なclientData.type: {client_data.type}")
        return False

    # 4. clientData.challenge の検証 (セッションに保存されたチャレンジと比較)


    #    ここでは簡略化のため省略するが、実際にはサーバーはセッションに保存された


    #    チャレンジと比較する必要がある。


    # if client_data.challenge != session_challenge: return False

    # 5. 署名の検証 (Public Key Credential Source内の公開鍵とAuthenticatiorの署名データを使って検証)


    #    ここでは簡略化のため省略。fido2ライブラリなどで実装される。

    # 6. AuthenticatorData.signCount の検証 (登録済みのカウンタより大きいことを確認)


    #    ここでは簡略化のため省略。リプレイ攻撃対策に重要。

    print("検証成功: RP IDとOriginが厳格に検証されました。")
    return True

# --- 実行例 ---


# 偽装サイトからの認証リクエストをシミュレート


# clientDataJSONのOriginが正規サイトと異なる


# AuthenticatorDataのrp_id_hashは、Authenticatorが認識している正規のRP ID ("example.com") のハッシュ


# と仮定 (フィッシングサイトはAuthenticatiorを騙せないため、Authenticatorは正規RP IDで署名する)

# 正規のAuthenticatorData (example.com のハッシュで生成されているとする)

rp_id_hash_for_example_com = hashlib.sha256(EXPECTED_RP_ID.encode('utf-8')).digest()
mock_authenticator_data_good = AuthenticatorData(rp_id_hash_for_example_com, 0x01, 10) # flags, sign_count
mock_attestation_object_good = AttestationObject(mock_authenticator_data_good, "none", base64.b64encode(rp_id_hash_for_example_com + b'\x00'*40).decode()) # 簡略化

# フィッシングサイトからのclientDataJSON (originが異なる)

malicious_client_data_json_b64 = base64.urlsafe_b64encode(
    json.dumps({
        "challenge": "a_valid_challenge",
        "origin": "https://login-examp1e.com", # フィッシングサイトのOrigin
        "type": "webauthn.get"
    }).encode('utf-8')
).decode('utf-8').rstrip('=')

# 誤用例のテスト

print("\n--- 誤用例の結果 ---")
result_incorrect = verify_webauthn_credential_incorrect(
    mock_attestation_object_good,
    malicious_client_data_json_b64,
    EXPECTED_RP_ID,
    EXPECTED_ORIGIN
)
print(f"誤用例での検証結果: {result_incorrect} (フィッシングを許してしまう可能性)\n")

# 安全な代替のテスト

print("--- 安全な代替の結果 ---")
result_secure = verify_webauthn_credential_secure(
    mock_attestation_object_good,
    malicious_client_data_json_b64,
    EXPECTED_RP_ID,
    EXPECTED_ORIGIN
)
print(f"安全な代替での検証結果: {result_secure} (フィッシングを防止)\n")

# 正規サイトからの認証リクエストをシミュレート (Originが一致)

valid_client_data_json_b64 = base64.urlsafe_b64encode(
    json.dumps({
        "challenge": "a_valid_challenge",
        "origin": EXPECTED_ORIGIN, # 正規サイトのOrigin
        "type": "webauthn.get"
    }).encode('utf-8')
).decode('utf-8').rstrip('=')

print("--- 安全な代替 (正規サイト) の結果 ---")
result_secure_valid = verify_webauthn_credential_secure(
    mock_attestation_object_good,
    valid_client_data_json_b64,
    EXPECTED_RP_ID,
    EXPECTED_ORIGIN
)
print(f"安全な代替での正規認証結果: {result_secure_valid}\n")

コメント:

  • 前提: 上記コードはWebAuthnプロトコルの一部であるRP IDおよびOrigin検証に焦点を当てた簡略化された例です。実際のWebAuthnライブラリは、鍵の生成、署名検証、Attestationオブジェクトのパースと検証など、より多くの処理を内包します。

  • 入出力: 各関数は、Authenticatorから受け取ったデータとRPサーバーの設定値を受け取り、検証の成否をブール値で返します。

  • 計算量: 主にハッシュ計算と文字列比較が中心であり、非常に小さい定数時間 (O(1)) で実行されます。

  • メモリ条件: 扱うデータが比較的小さいため、メモリ消費は無視できるレベルです。

  • セキュリティに関する注意: 署名検証、チャレンジ検証、Authenticatior Data内のフラグやカウンタの検証など、上記のコード例で省略されている他の検証ステップも全て必須です。これらも怠ると重大な脆弱性につながります。

運用対策

FIDO2/WebAuthnの導入後も、安全な運用を継続するためには以下の対策が不可欠です。

鍵/秘匿情報の取り扱い

  • Authenticator側の秘密鍵: 秘密鍵はAuthenticatorデバイス内部で生成され、セキュアエレメントなどに保護されて保存されます。RPサーバーやUser Agentに決して公開されることはありません。これはFIDO2/WebAuthnの根幹をなすセキュリティ特性です。

  • RPサーバー側の公開鍵・Credential ID: RPサーバーは、ユーザーの認証時に登録された公開鍵、Credential ID、およびその他のメタデータ（例: Authenticator Attestation GUID, 署名カウンタ）を安全に保管する必要があります。

    • これらの情報は厳重に暗号化してデータベースに保存し、不正アクセスから保護します。

    • データベースへのアクセスは最小権限の原則に基づき、必要な担当者とシステムのみに限定します。

    • Credential IDはユーザーを特定する情報ではないため、データベース上ではユーザーIDとの紐付けを厳重に管理し、安易な問い合わせでCredential IDが漏洩しないようにします。

ローテーション

FIDO2/WebAuthnのCredentialは、パスワードのように定期的に「ローテーション」するという概念は一般的ではありません。しかし、以下の運用でセキュリティを維持します。

  • Credentialの追加と削除: ユーザーは複数のAuthenticatorを登録し、不要になったCredentialはいつでもRP側で削除できる仕組みを提供します。例えば、デバイス紛失時にそのデバイスに紐づくCredentialを失効させる機能は必須です。

  • 異常検知時の再登録: 不審な認証試行やAuthenticatiorの侵害が疑われる場合、既存のCredentialを無効化し、ユーザーに新しいAuthenticatorまたはCredentialの再登録を促す運用フローを確立します。

  • Resident Keyの考慮: Resident Keyを使用している場合、Authenticatorの紛失はより大きなリスクとなるため、その場合の復旧プロセス（別の認証方法での本人確認とCredential削除）を明確にします。

最小権限

  • RP側のAPIアクセス: WebAuthn認証を処理するRPのバックエンドAPIは、認証に必要な最小限のデータ（チャレンジ生成、Credential IDと公開鍵の照合、署名検証）にのみアクセスできるよう、権限を厳しく制限します。

  • 管理者のアクセス制御: FIDO2/WebAuthnのCredential情報を管理するシステムへのアクセスは、担当者の職務権限に基づき、最小限のアクセス権限（例: 閲覧のみ、削除のみ）を付与します。

監査

  • 認証イベントのログ: 全ての認証試行（成功・失敗）、Credentialの登録、Credentialの削除、Authenticator情報の更新を詳細にログに記録します。

    • ログには、タイムスタンプ、ユーザーID、RP ID、Authenticator Attestation GUID (AAGUID)、ClientData.Origin、IPアドレス、User Agentなどの情報を記録します。

  • ログの監視と分析: 記録されたログは、前述の検出策に基づき、リアルタイムまたは定期的に監視・分析します。異常が検出された場合は、速やかにアラートを発し、対応します。

  • 長期保存: 法的要件や内部ポリシーに基づき、監査ログを長期的に安全に保管します。

現場の落とし穴

FIDO2/WebAuthnの導入には多くのメリットがありますが、現場で陥りがちな落とし穴も存在します。

  • 導入の複雑性: WebAuthnプロトコルは多岐にわたり、RPサーバー側の実装が複雑になりがちです。適切なライブラリやフレームワークの選定、専門知識を持つエンジニアの確保が重要です。

  • ユーザー体験 (UX) とのトレードオフ: Resident Keyの利用はUXを向上させますが、Authenticator紛失時のリスクが高まります。セキュリティと利便性のバランスを考慮した設計が必要です。

  • レガシーシステムとの連携: 既存のパスワード認証システムとの移行期間や併用時の考慮が必要です。段階的な導入計画を立てることが推奨されます。

  • デバイス紛失時のリカバリーフロー: Authenticatorを紛失した場合の、安全かつユーザーフレンドリーなアカウント復旧メカニズム（例: 別のAuthenticatorでの認証、セカンドファクターによる本人確認、サポートデスクによる対応）の設計が非常に重要です。このフローが脆弱だと、FIDO2のメリットが台無しになります。

  • Attestationの誤解: AttestationはAuthenticatorの信頼性を示すものですが、その検証には複雑な証明書チェーンの検証が含まれ、プライバシー懸念もあります。 Attestationを過信せず、必要最小限の範囲で、かつ匿名性を考慮して利用すべきです [3]。

  • 誤検知/検出遅延: 異常検知システムは誤検知（False Positive）を発生させやすく、ユーザー体験を損ねる可能性があります。精度の高いルール設計と、検出遅延を最小限に抑えるリアルタイム監視が必要です。

まとめ

FIDO2/WebAuthnは、パスワードレス認証の未来を切り拓く強力な技術であり、フィッシング耐性やMFAバイパス耐性において非常に高いセキュリティを提供します。しかし、その真価を発揮するためには、RP IDとOriginの厳格な検証、堅牢なRPサーバーの実装、そして鍵管理、監査、緊急時のリカバリーフローを含めた運用対策が不可欠です。本記事で解説した脅威モデル、攻撃シナリオ、そして具体的な対策と運用上の落とし穴を理解し、安全で使いやすいパスワードレス認証環境の構築に貢献できることを願います。

参考文献 [1] W3C. “Web Authentication: An API for accessing Strong Authentication Credentials – Level 3”. W3C Recommendation. 2024年4月16日. https://www.w3.org/TR/webauthn-3/ [2] FIDO Alliance. “FIDO Security Reference”. 2023年9月19日. https://fidoalliance.org/specs/fido-security-reference/ [3] webauthn.io. “Security Best Practices”. 2024年6月25日. https://webauthn.io/docs/security/best-practices/

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました