パスキーはなぜ安全なのか ── 図解でわかる「秘密を送らない認証」の仕組み

「また大手サービスからパスワードが漏れた」というニュースは、もう誰も驚かなくなりました。フィッシング訓練を毎年やっても、引っかかる人はゼロにはなりません。「パスワードは使い回すな、長くしろ、定期変更は…もうしなくていい」──言うことも二転三転してきました。

ここ数年で急速に広まったパスキー(passkey)は、この状況への答えとして、Apple・Google・マイクロソフトの3社が揃って推進している認証方式です。¹ 「指紋や顔でログインできて便利」という紹介のされ方が多いのですが、本質はそこではありません。パスキーの本当の価値は、安全性の根拠を「人間の注意力」から「プロトコルの構造」に移したことにあります。

• パスワードが漏れるのは利用者の不注意だから、教育しよう → 人間は必ず間違える
• 偽サイトを見抜けるように訓練しよう → 見抜けない偽サイトが作れる
• パスキーなら → そもそも送る秘密がなく、偽サイトでは署名が成立しない

この記事では、パスキーがなぜ安全なのかを、パスワードの何が壊れているのかから出発して図で押さえます。そのうえで「同期されるパスキーは本当に安全なのか」「弱点はないのか」という当然の疑問に正面から答え、最後にWebアプリやWindows環境へ導入するときの実務の要点を整理します。

1. まず結論

パスキーが安全な理由は、次の3つに集約されます。

1. サーバーに秘密が存在しない。サーバーが保存するのは公開鍵だけで、これは漏れても悪用できない情報です。データベースが丸ごと流出しても、攻撃者が持ち帰れる「なりすましの材料」がありません。²
2. 秘密がネットワークを流れない。ログイン時に送られるのは、その場限りの乱数(チャレンジ)への署名だけです。秘密鍵はデバイスの認証器から一切出ないため、経路のどこを盗聴・中継しても秘密は手に入りません。²
3. 偽サイトでは署名が成立しない。パスキーはサイトのドメインに紐付いており、ブラウザーがドメインの照合を強制します。利用者が偽サイトに騙されても、本物のサイト用のパスキーはそもそも候補に出ず、仮に署名を中継しても検証で落ちます。³

この3つは独立した工夫ではなく、「秘密を共有して送る」認証から「秘密を持っていることを署名で証明する」認証への転換という1つの設計変更から、すべて導かれる帰結です。順に見ていきます。

用語の関係 ── パスキー・WebAuthn・FIDO2・CTAP

この分野は用語が多いうえ、記事によって指す範囲が違うので、先に関係だけ押さえておきます。パスキーは新しいプロトコルではなく、既存の規格の組み合わせに付いた「呼び名」です。²¹

表1: パスキーはFIDO2という土台の上の呼び名であり、規格名ではない

つまり「パスキーに対応する」とは、実装の言葉に直せば「WebAuthnを実装する」ことです。CTAPは外付けの認証器を使うときにブラウザーとOSが面倒を見てくれる層なので、Webアプリを作る側が直接触ることはありません。

この記事の知識マップ

パスキーはWebAuthnとCTAP(合わせてFIDO2)という標準規格の上に成り立つ公開鍵暗号ベースの資格情報で、秘密鍵は認証器から出ず、サーバーには漏れても悪用できない公開鍵だけを預けます。パスキーがサイトのドメイン(RP ID)に紐付けて作られることで、偽サイトでは署名がそもそも成立せずフィッシングが構造的に防止されます。同期型パスキーはクラウドアカウントへの依存と引き換えに紛失耐性を得る一方、デバイス固定型はハードウェアに鍵を閉じ込めます。パスキー導入後は、併存するフォールバック手段の縮小とアカウント回復フローの強化が実務の焦点になります。

flowchart LR
    accTitle: パスキーがなぜ安全かの知識マップ
    accDescr: パスキーがWebAuthn・FIDO2・CTAP・公開鍵暗号の上に成り立つこと、RP IDによるドメイン紐付けがフィッシングを構造的に防ぐこと、同期型とデバイス固定型の違いとそれぞれの単一障害点、フィッシング耐性MFAとしての位置付け、残存リスク(フォールバック・アカウント回復・セッション窃取)の関係を示す図
    passkey["パスキー"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["公開鍵暗号"]
    ctap["CTAP"]
    authenticator["認証器"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["セキュリティキー"]
    device_bound_passkey["デバイス固定型パスキー"]
    webauthn_secure_context["セキュアコンテキスト要件(HTTPS)"]
    webauthn_challenge["チャレンジ(使い捨て乱数)"]
    rp_id["RP ID(Relying Party識別子)"]
    phishing["フィッシング"]
    aitm_phishing["AiTM(中間者)型フィッシング"]
    credential_database_breach["認証情報データベースの漏洩"]
    password_authentication["パスワード認証"]
    password_reuse["パスワードの使い回し(リスト型攻撃)"]
    account_takeover["アカウント乗っ取り"]
    session_cookie_theft["セッションクッキー窃取"]
    totp["ワンタイムパスワード(TOTP)"]
    phishing_resistant_mfa["フィッシング耐性MFA"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["同期型パスキー"]
    platform_credential_vault["プラットフォームの資格情報保管庫"]
    nist_aal3["NIST AAL3(認証器保証レベル3)"]
    platform_account_hardening["プラットフォームアカウントの保護強化"]
    account_recovery_abuse["アカウント回復フローの悪用"]
    account_recovery_hardening["回復フローの本人確認強化"]
    fallback_credential["併存するフォールバック認証手段"]
    fallback_retirement["フォールバック手段の計画的縮小"]
    passkey -->|"利用する"| webauthn
    passkey -->|"利用する"| fido2
    passkey -->|"利用する"| public_key_cryptography
    fido2 -->|"利用する"| webauthn
    fido2 -->|"利用する"| ctap
    passkey -->|"利用する"| authenticator
    authenticator -.->|"利用する"| tpm
    windows_hello -.->|"利用する"| tpm
    passkey -.->|"利用する"| windows_hello
    passkey -.->|"利用する"| fido2_security_key
    device_bound_passkey -->|"利用する"| authenticator
    webauthn -->|"前提とする"| webauthn_secure_context
    webauthn -->|"利用する"| webauthn_challenge
    passkey -->|"前提とする"| rp_id
    rp_id -->|"防止する"| phishing
    passkey -->|"防止する"| phishing
    passkey -->|"防止する"| aitm_phishing
    public_key_cryptography -->|"軽減する"| credential_database_breach
    password_authentication -.->|"原因になり得る"| credential_database_breach
    password_authentication -.->|"原因になり得る"| phishing
    password_authentication -.->|"原因になり得る"| password_reuse
    password_reuse -.->|"原因になり得る"| account_takeover
    aitm_phishing -.->|"原因になり得る"| session_cookie_theft
    totp -->|"用いるのは非推奨"| phishing_resistant_mfa
    passkey -->|"推奨される対応"| phishing_resistant_mfa
    entra_id -.->|"利用する"| passkey
    passkey -.->|"で構成できる"| entra_id
    synced_passkey -->|"に保存される"| platform_credential_vault
    synced_passkey -->|"両立しない"| nist_aal3
    device_bound_passkey -.->|"推奨される対応"| nist_aal3
    platform_credential_vault -.->|"原因になり得る"| account_takeover
    platform_account_hardening -->|"推奨される対応"| account_takeover
    account_recovery_abuse -.->|"原因になり得る"| account_takeover
    account_recovery_hardening -->|"推奨される対応"| account_recovery_abuse
    fallback_credential -.->|"原因になり得る"| account_takeover
    fallback_retirement -->|"推奨される対応"| fallback_credential
    session_cookie_theft -->|"原因になり得る"| account_takeover
    passkey -->|"用いるのは非推奨"| session_cookie_theft

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全38件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. パスワード認証は何が壊れているのか

パスキーの安全性を理解する近道は、パスワードの弱点を「場所」で捉えることです。パスワード認証では、秘密そのものが認証のたびに全区間を旅します。

sequenceDiagram
    participant U as 利用者
    participant B as ブラウザー
    participant S as サーバー
    Note over U: 秘密(パスワード)を頭の中に持つ<br/>【弱点①】推測できる・使い回される
    U->>B: パスワードを入力
    Note over B: 【弱点②】偽サイトにも同じように<br/>入力できてしまう(見た目で区別不能)
    B->>S: パスワードそのものを送信
    Note over B,S: 【弱点③】秘密が経路を流れる<br/>TLSで守られるが終端では平文に戻る
    S->>S: 保存済みハッシュと照合
    Note over S: 【弱点④】全利用者の秘密(のハッシュ)が集積<br/>漏洩すればオフライン総当たりの的になる

図1: パスワード認証では、秘密そのものが全区間に存在する

攻撃者から見ると、これは的が多くて撃ちやすい構造です。

• 弱点①(利用者): 覚えられる程度の強度しかなく、複数サイトで使い回される。1か所の漏洩が全アカウントに波及する(パスワードリスト型攻撃)。
• 弱点②(入力の瞬間): 本物と見分けのつかない偽サイトを用意すれば、利用者は自分から秘密を差し出してくれる(フィッシング)。
• 弱点③(経路): TLSがあるので経路そのものの盗聴は難しいが、「正規の見た目をした中継点」を挟まれると意味がない(後述のAiTM)。
• 弱点④(サーバー): ハッシュ化して保存していても、データベースが流出すればオフラインで総当たりにかけられる。弱いパスワードから順に割れていく。

「ではワンタイムコード(SMSやTOTP)を足せばいいのでは」というのが従来の多要素認証ですが、これも共有された秘密を送る構造は変わっていません。TOTPはサーバーと認証アプリが同じシード(秘密)を共有していますし、生成された6桁コードは結局利用者が偽サイトに入力できてしまいます。実際、偽サイトが本物のサーバーへリアルタイムに中継するAiTM(Adversary-in-the-Middle)型のフィッシングは、パスワード+ワンタイムコードの組をそのまま横流しして突破します。CISA(米国のサイバーセキュリティ庁)が「フィッシング耐性のあるMFA」として挙げるのが、FIDO/WebAuthn方式と、スマートカード(PIV/CAC)のようなPKIベース認証の2つだけで、中でもFIDOをゴールドスタンダードと位置付けているのは、このためです。⁴

つまり問題はパスワードの「強度」ではなく、「秘密を共有して、認証のたびに送る」という構造そのものにあります。

3. パスキーの正体 ── 秘密を送らず、持っていることを証明する

パスキーは、W3CのWebAuthnとFIDOアライアンスのCTAPという2つの標準(合わせてFIDO2)の上に成り立つ、公開鍵暗号ベースの資格情報です。²¹ 難しそうに聞こえますが、構造は単純です。

flowchart LR
    subgraph DEV["利用者のデバイス"]
        AUTH["認証器(金庫)<br/>Windows Hello / Face ID /<br/>Androidの画面ロック / セキュリティキー"]
        SK["秘密鍵<br/>ここから一切出ない"]
        BIO["指紋・顔・PIN<br/>= 金庫の扉を開けるだけ<br/>これも外に出ない"]
        AUTH --- SK
        BIO -->|"ローカルで照合"| AUTH
    end
    subgraph SRV["サーバー"]
        PK["公開鍵<br/>漏れても悪用できない<br/>『検証専用』の情報"]
    end
    SK -.->|"数学的なペア<br/>(署名を作る側)"| PK

図2: パスキーの実体はサイトごとの鍵ペア。秘密側はデバイスから出ず、サーバーは検証用の公開鍵しか持たない

• 秘密鍵は署名を作れる側の鍵で、デバイス内の認証器(Windows Hello、iPhoneのFace ID/Touch ID、Androidの画面ロック、あるいはYubiKeyのようなセキュリティキー)に保管され、外に出ません。
• 公開鍵は署名を検証することしかできない側の鍵で、これをサーバーに預けます。公開鍵から秘密鍵を逆算することは計算量的に不可能なので、漏れても構わない情報です。
• 指紋や顔などの生体情報は、金庫の扉をローカルで開けるためだけに使われ、これもデバイスから出ません。サーバーに生体情報が送られることはありません。¹

登録: 公開鍵「だけ」を渡す

サイトにパスキーを登録するときの流れです。

sequenceDiagram
    participant S as サーバー(example.com)
    participant B as ブラウザー
    participant A as 認証器
    S->>B: 登録要求(乱数チャレンジ + サイト情報)
    B->>A: このサイト(example.com)用の鍵を作って
    A->>A: 指紋・顔・PINで本人確認(ローカル)
    A->>A: 新しい鍵ペアを生成<br/>秘密鍵は内部に保管
    A->>B: 公開鍵 + credential ID(鍵の名札)
    B->>S: 公開鍵 + credential ID を送信
    S->>S: このアカウントの公開鍵として保存
    Note over S: サーバーが受け取ったのは<br/>「漏れても悪用できない情報」だけ

図3: 登録時にネットワークを流れ、サーバーに保存されるのは公開鍵だけ

重要なのは、このとき鍵ペアがサイトのドメイン(RP ID)に紐付けて作られることです。example.com 用に作られたパスキーは example.com のサイトでしか使えません(RP IDはドメイン単位なので、login.example.com のような同じドメイン配下のサブドメインのページからは使えますが、無関係なドメインからは使えません)。この紐付けが、後述するフィッシング耐性の土台になります。³

また、鍵ペアはサイトごとに毎回新しく作られます。サイトAとサイトBのパスキーは数学的に無関係なので、「使い回し」という概念自体が存在せず、サイト間で利用者を突き合わせる材料にもなりません。

認証: その場限りの署名を返す

ログイン時の流れです。パスワード認証(図1)と見比べてください。

sequenceDiagram
    participant S as サーバー(example.com)
    participant B as ブラウザー
    participant A as 認証器
    S->>B: ログイン要求(その場限りの乱数チャレンジ)
    B->>A: example.com への署名要求
    A->>A: 指紋・顔・PINで本人確認(ローカル)
    A->>A: 秘密鍵で署名を作成<br/>チャレンジ + オリジン + RP IDハッシュを焼き込む
    A->>B: 署名(秘密鍵そのものではない)
    B->>S: 署名を送信
    S->>S: 保存済みの公開鍵で署名を検証<br/>チャレンジ・オリジン・RP IDも確認
    Note over B,S: 経路を流れるのは使い捨ての署名だけ<br/>盗んでも次回のチャレンジには使えない

図4: 認証時も秘密は移動しない。流れるのは「その場限りの証明書類」だけ

サーバーは毎回新しい乱数(チャレンジ)を出題し、認証器は「そのチャレンジ+いまブラウザーが見ているオリジン+RP IDのハッシュ」に対して署名します。サーバーは保存してある公開鍵で署名を検証し、チャレンジが自分の出題したものであること、オリジンとRP IDが自サイトのものであることを確認します。⁵

この設計の帰結として、冒頭の3つの理由のうち2つがすでに成立しています。

• サーバーに秘密がない: 保存されているのは公開鍵だけ。流出しても攻撃者は署名を作れないので、パスワードのハッシュのように「持ち帰って割る」ことができません。
• 秘密が流れない: 経路上の署名を盗んでも、チャレンジは使い捨てなので再利用(リプレイ)できません。

残る1つ、「偽サイトでは署名が成立しない」が、パスキー最大の売りです。節を分けて見ます。

4. フィッシングが「構造的に」成立しない理由

パスワードに対するフィッシングが成功するのは、本物の秘密を偽サイトに入力できてしまうからです。人間には example.com と examp1e.com の区別が(疲れていれば特に)つきませんが、パスワード入力欄はどちらのサイトでも同じように動きます。

パスキーでは、この照合を人間ではなくブラウザーが機械的に行います。WebAuthnの仕様上、ブラウザーは「いま表示しているオリジンのドメイン」と「パスキーのRP ID」が対応する場合にしか認証器を呼び出せません。³ 偽サイトにアクセスした時点で何が起きるかを図にします。

sequenceDiagram
    participant U as 利用者
    participant B as ブラウザー
    participant P as 偽サイト(examp1e.com)<br/>本物へ中継するAiTMプロキシ
    participant S as 本物のサーバー(example.com)
    U->>P: 見た目そっくりのログイン画面にアクセス
    P->>S: (裏で)本物のログイン処理を開始
    S->>P: チャレンジ
    P->>B: チャレンジを横流しして署名を要求
    B->>B: いまのオリジンは examp1e.com<br/>example.com 用のパスキーは候補に出せない
    B--xP: 署名は作られない(利用者は騙されようがない)
    Note over B,S: 仮に何らかの方法で署名が作られても、<br/>署名には examp1e.com が焼き込まれるため<br/>本物のサーバーの検証で必ず落ちる

図5: AiTM型フィッシングはパスワード+ワンタイムコードを突破するが、パスキーでは署名の段階で成立しない

防御が二重になっていることに注目してください。

1. 候補に出ない: ブラウザーはオリジンに対応するRP IDのパスキーしか列挙しません。偽ドメイン上では本物サイト用のパスキーが選択肢に現れないので、利用者は「うっかり使う」ことすらできません。
2. 署名が通らない: 署名対象にはブラウザーが確認したオリジンとRP IDのハッシュが含まれます。本物のサーバーは検証時にこれを照合するため、別オリジンで作られた署名は必ず拒否されます。⁵

パスワードのフィッシング対策は「利用者がURLをよく見る」という人間の努力に依存していました。パスキーでは利用者が偽サイトを見抜く必要がそもそもない。これが「フィッシング耐性(phishing-resistant)」という言葉の正確な意味であり、CISAやNIST(米国標準技術研究所)がFIDO/WebAuthn方式を特別扱いする理由です。⁴⁶

ここまでの内容を、攻撃手法ごとに整理します。

表2: 攻撃手法ごとの耐性比較。パスキーの「○」はどれも運用や注意力ではなく構造に由来する

5. 「同期されるパスキー」は安全なのか

ここまでの説明を読むと、当然こういう疑問が湧きます。「秘密鍵はデバイスから出ないと言ったのに、iPhoneで作ったパスキーがiPadでも使えるのはなぜだ」──良い疑問で、答えは「パスキーには2種類ある」です。

先に結論を早見表にしておきます。この節と次の節は、この表の各行がなぜそうなるのかを説明していると思って読んでください。

表3: 同期型とデバイス固定型の早見表。どちらを選ぶかは「紛失への強さ」と「鍵の所在を管理できること」のどちらを取るかで決まる

flowchart TB
    subgraph SYNC["同期型パスキー(コンシューマー向けの既定)"]
        S1["iCloudキーチェーン /<br/>Googleパスワードマネージャー /<br/>1Passwordなどのパスワードマネージャー"]
        S2["同じアカウントのデバイス間で<br/>エンドツーエンド暗号化して同期<br/>事業者も中身を読めない"]
        S3["利点: 機種変更・紛失に強い<br/>注意: クラウドアカウント自体の防御が要"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["デバイス固定型パスキー"]
        B1["セキュリティキー(YubiKeyなど) /<br/>Windows Hello /<br/>Microsoft Authenticator(Entra ID)"]
        B2["秘密鍵はそのハードウェアから<br/>物理的に出ない(TPMなどで保護)"]
        B3["利点: 鍵の所在が1か所で明確<br/>注意: 紛失に備え複数登録が必須"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

図6: 同期型とデバイス固定型。どちらも「秘密鍵をサーバーに送らない」点は同じで、守り方の重心が違う

同期型パスキーは、iCloudキーチェーンやGoogleパスワードマネージャーが秘密鍵を同じアカウントのデバイス間で同期するものです。ここで重要なのは、同期がエンドツーエンド暗号化されていることです。AppleもGoogleも、パスキーはデバイス上で暗号化されてから同期され、事業者自身も中身を読めないと明言しています。⁷⁸ つまり「秘密鍵がデバイスから出ない」という原則は、正確には「秘密鍵は平文ではデバイスから出ない」に緩和され、その代わりに機種変更や紛失への耐性を得ています。

この緩和が脅威モデルをどう変えるかは、はっきり言語化しておくべきです。守るべき場所が「各サイトのサーバー」から「クラウドアカウント1つ」に集約されるのです。各サイトのDB漏洩やフィッシングには相変わらず強いまま、今度はApple ID/Googleアカウント自体の乗っ取りが単一障害点になります。だからこそ、パスキーを預けるプラットフォームアカウントには最強の保護(強力な画面ロック、回復手段の整理、可能なら物理セキュリティキー)をかけるのが大前提です。NISTも2024年4月にNIST SP 800-63B の補遺(Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B)を出し、この同期型パスキー(syncable authenticator)が要件を満たせば政府基準のAAL2(Authenticator Assurance Level 2、認証器保証レベル2)を満たしうると正式に位置付けました。ただし、秘密鍵がエクスポートされうる以上、ハードウェアで隔離された環境を要求するAAL3には同期型を用いないこととされています。⁶

デバイス固定型パスキーは、秘密鍵がハードウェアから出ないタイプです。YubiKeyのようなセキュリティキーが典型で、法人向けではMicrosoft Entra IDのパスキー(Microsoft Authenticator内に作るもの)もデバイス固定型です。⁹ WindowsのWindows Helloも、TPMがあれば秘密鍵をTPM配下で保護します。この「鍵を外に出さないハードウェア金庫」の仕組み自体は、TPMの記事で詳しく解説したものと同じ土台です。

なお、「スマホのパスキーでPCのブラウザーにログインする」ときにQRコードを読み取らされるのを不思議に思ったことがあるかもしれません。あれは単なる画面遷移ではなく、BluetoothでスマホとPCの物理的な近接を確認するハイブリッド方式(FIDOのcross-device認証)です。遠隔の攻撃者が自分のPCへのログインをQRコード経由で他人に承認させる、という攻撃を近接確認で潰しています。¹

6. 銀の弾丸ではない ── 弱点は「消える」のではなく「移動する」

ここまでパスキーの強さを説明してきましたが、誠実に言えば、パスキーは攻撃を消滅させるのではなく攻撃者をより弱い場所へ追いやる技術です。認証の玄関が固くなったとき、攻撃者がどこへ回るかを図にします。

flowchart LR
    A["攻撃者"]
    G["認証そのもの<br/>チャレンジ署名<br/>【固い】"]
    R["アカウント回復フロー<br/>『パスキーを失くした』と申告して<br/>SMSやメールで再設定させ、<br/>攻撃者のパスキーを登録する"]
    F["併存するフォールバック<br/>パスワード・SMSログインが<br/>残っていれば最弱リンクはそこ"]
    C["クラウドアカウント<br/>同期型ならApple ID /<br/>Googleアカウントが単一障害点"]
    SS["セッション<br/>ログイン後のCookieを盗めば<br/>認証方式は関係ない"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

図7: 玄関(認証)が固くなると、攻撃は回復フロー・併存手段・クラウドアカウント・セッションへ移る

実務で押さえておくべき残存リスクは4つです。

1. 併存するフォールバックが最弱リンクになる。パスキー「も」使えるようにしただけで、パスワードやSMSログインが残っていれば、攻撃者はそちらを使うだけです。フィッシング耐性はアカウント全体で見ればいちばん弱いログイン手段のレベルに律速されます。導入の本丸は、パスキー追加ではなくフォールバックの計画的な縮小・廃止です。
2. 回復フローが新たな攻撃面になる。「デバイスを失くした」と偽ってサポート窓口やメール経由の再設定に持ち込み、攻撃者自身のパスキーを登録させる手口です。実際に、強固な認証を回避してヘルプデスクを騙すソーシャルエンジニアリングは大規模侵害の常套手段になっています。認証を固めたぶん、回復フローの本人確認をどう設計するかが問われます。
3. 同期型ではクラウドアカウントが単一障害点。前節のとおりです。パスキーを預けるアカウントの防御と、組織で使う場合の「どのプラットフォームへの同期を許すか」の方針決めが必要です。
4. セッション窃取は防げない。パスキーが守るのはログインの瞬間だけで、ログイン後のセッションクッキーをマルウェアやXSSで盗まれれば認証方式は関係ありません。トークンの有効期間・バインディング・デバイス健全性の管理という別レイヤーの仕事は残ります。

これらは「パスキーはやめておこう」という話ではありません。玄関の鍵を最新にしても窓の施錠は別の仕事だ、という当たり前の話です。むしろ弱点の場所が明確になるぶん、防御リソースを回復フローとセッション管理に集中投下できるようになります。

7. 実務での導入 ── WebAuthn APIとWindows環境

最後に、導入する側の視点で要点を押さえます。

自社Webサービスにパスキーログインをつける

ブラウザー側はWebAuthn APIの2つの関数だけです。登録は navigator.credentials.create()、認証は navigator.credentials.get() を呼びます。

// 登録(ブラウザー側)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // サーバーが生成した使い捨ての乱数
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "太郎" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // ディスカバラブル資格情報(=パスキー)にする
      userVerification: "required",   // 生体認証/PINによる本人確認を必須にする
    },
  },
});
// 公開鍵は credential.response から、credential ID はトップレベルの
// credential.id / credential.rawId から取り出す。登録レスポンスも認証時と
// 同様にチャレンジ・オリジン・RP IDをサーバーで検証してから保存する

主要なパラメーターの意味は次のとおりです。

表4: navigator.credentials.create() の主要パラメーター

検証環境の注意: WebAuthn APIはセキュアコンテキストでしか公開されないため、素の http:// で配信したページでは navigator.credentials の呼び出しが失敗します。例外は http://localhost(および 127.0.0.1)で、これらは信頼できるオリジンとして扱われるので、開発機ではHTTPS化しなくてもそのまま試せます。ただしRP IDはオリジンの実効ドメイン(またはその親ドメイン)でなければならないので、localhost で作ったパスキーは本番ドメインでは使えません。手元に認証器がなくても、Chromeの開発者ツールの「WebAuthn」タブで仮想認証器を有効にすれば、登録から認証まで一通り動かせます。

// 認証(ブラウザー側)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // ログイン欄の自動入力候補としてパスキーを提示する。事前に
  // PublicKeyCredential.isConditionalMediationAvailable() で対応を確認し、
  // 非対応ブラウザーでは mediation を付けない通常の呼び出しにフォールバックする
  mediation: "conditional",
  // (対象の<input>に autocomplete="username webauthn" の指定が必要)
});
// assertion.response の署名をサーバーで検証する

本体はサーバー側の検証です。最低限、次を必ず行います。⁵

• チャレンジの照合: 自分が発行した未使用のチャレンジか。使い捨てにしているか(リプレイ対策)。さらに、発行時のブラウザーセッション(ログイン試行)に紐付けて保存し、同じセッションからの応答にだけ消費を許すこと。ここが緩いと、攻撃者が自分宛てのチャレンジへの署名を被害者のブラウザー経由で送り込み、被害者を攻撃者のアカウントにログインさせる(ログインCSRF)余地が生まれる。
• オリジンの照合: clientDataJSON の origin が自サイトの正規オリジンか(フィッシング対策の要)。
• RP IDハッシュの照合: authenticatorData の rpIdHash が自サイトのRP IDのSHA-256と一致するか。
• セレモニー種別とフラグの確認: clientDataJSON の type が認証なら webauthn.get、登録なら webauthn.create であるか。authenticatorData のUP(ユーザー在席)フラグが立っているか。ユーザー検証(UV)を要求したなら、UVフラグも立っているか。
• 署名の検証: 登録時に保存した公開鍵で署名が正しく検証できるか。
• アカウントとの紐付け: 提示された credential ID(と userHandle)を自分のデータベースで引き、その資格情報の持ち主に対してセッションを発行しているか。別途入力されたユーザー名を無条件に信用すると、正しい署名で他人としてログインさせる穴になる。
• 署名カウンターの保存と比較: authenticatorData の signCount を資格情報ごとに保存し、次回の値が前回より増えていることを確認する。前回の値以下(同値を含む)なら認証器の複製(クローン)の兆候として扱う。ただし同期型パスキーは常に0を返す実装が多いので、0同士だけは例外として許容する。

この検証を手書きするのは事故のもとなので、実績のあるライブラリ(.NETなら fido2-net-lib、Node.jsなら SimpleWebAuthn など)を使ってください。仕様の細部(CBORのパース、アルゴリズムの合意、チャレンジ管理)はライブラリに任せ、自分たちはチャレンジの保存と失効、複数パスキーの管理UI、回復フローの設計に集中するのが正しい力の配分です。

Windows環境・社内システムの場合

このサイトの読者層である「Windowsの業務システムを預かる立場」からは、次の3点を押さえておけば十分です。

• Windowsクライアントは対応済み。Windows 11はWindows Helloを認証器としてパスキーの作成・利用・管理(設定 > アカウント > パスキー)に対応しており、秘密鍵はTPMがあればハードウェア保護されます。¹⁰ ブラウザー(Edge/Chrome)経由のWebAuthnはWindows 10でも動きます。
• Entra ID環境では「パスキー=FIDO2認証方式」を有効化する。Microsoft Entra IDはセキュリティキーとMicrosoft Authenticatorアプリ内のパスキー(デバイス固定型)をサポートしており、条件付きアクセスの認証強度で「フィッシング耐性MFA」を要求すれば、対象リソースへのアクセスをパスキー等に限定できます。⁹ NTLMやパスワード期限ポリシーの世界からの移行は一足飛びには進まないので、NTLMとKerberosの記事で扱った認証基盤の棚卸しと並行して、まず管理者アカウントからフィッシング耐性MFAを義務化するのが定石です。
• 社内Webアプリでも恩恵は同じ。ただしHTTPSが前提。WebAuthn APIはセキュアコンテキストでしか動かないため、イントラネットのアプリでも(開発時のlocalhostを除き)HTTPS化と、RP IDとして使える内部ドメイン名の整備が先決です。それさえ済めばRP IDは内部ドメインに対しても機能します。パスワード付箋との決別という意味では、外向けサービスより社内のほうが効果が早く出ることも珍しくありません。

8. まとめ

• パスワードの弱点は強度ではなく、「秘密を共有し、認証のたびに送る」という構造にある。秘密が利用者・入力欄・経路・サーバーのすべてに存在するため、攻撃対象が多い。ワンタイムコードを足しても、AiTM型フィッシングには中継されて敗北する。
• パスキーはサイトごとの公開鍵暗号の鍵ペアであり、サーバーには漏れても悪用できない公開鍵だけを渡し、ログイン時は使い捨てチャレンジへの署名だけを送る。サーバーに秘密がなく、経路にも秘密が流れない。
• 署名にはブラウザーが確認したオリジンとRP IDが焼き込まれるため、偽サイトでは本物用のパスキーが候補に出ず、中継しても検証で落ちる。利用者が偽サイトを見抜く必要がないことが「フィッシング耐性」の正体で、防御の根拠が人間の注意力からプロトコルの構造に移った。
• 同期型パスキーはエンドツーエンド暗号化で同期され、機種変更・紛失に強い。その代わり守るべき場所がクラウドアカウントに集約されるので、Apple ID/Googleアカウント自体の防御が大前提になる。法人はデバイス固定型(セキュリティキー、Entra IDのAuthenticatorパスキー)も選べる。
• パスキーは攻撃を消すのではなく弱い場所へ追いやる。併存するパスワード、アカウント回復フロー、セッション窃取が残る攻撃面であり、導入の本丸はフォールバックの計画的縮小と回復フローの強化にある。
• 実装はWebAuthn APIの create / get の2関数+サーバー検証。検証は自作せず実績あるライブラリに任せ、チャレンジ管理・複数パスキーのUI・回復設計に力を割く。

関連記事

• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
• 図解でわかるNTLMとKerberos ── なぜ認証はNTLMに「落ちる」のか
• WinForms/WPFアプリにEntra ID認証を組み込む ── MSAL.NETとWAMブローカーの実務構成
• PowerShellでの資格情報の安全な扱い ── 平文パスワードをスクリプトから追放する
• Windowsアプリ開発のセキュリティ最低限チェックリスト
• 中小企業のセキュリティ対策、何から始めるか ── IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の歩き方

関連する相談領域

合同会社小村ソフトでは、社内WebシステムへのパスキーログインWebAuthn実装の支援、Entra ID環境でのフィッシング耐性MFA展開の設計、WinForms/WPFなどWindows業務アプリへの認証組み込みを含む受託開発を扱っています。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

パスキーとパスワードの根本的な違いは何ですか？

パスワードは「利用者とサーバーが同じ秘密を共有し、ログインのたびにその秘密を送る」仕組みです。秘密が利用者の頭の中・入力欄・通信経路・サーバーのデータベースと、あらゆる場所に存在するため、そのすべてが攻撃対象になります。パスキーは公開鍵暗号の鍵ペアを使い、秘密鍵がサーバーに送られることはありません。デバイス固定型では秘密鍵は認証器から一切出ず、同期型でもエンドツーエンド暗号化された形でしか外に出ません。サーバーに保存されるのは公開鍵という「漏れても悪用できない情報」だけで、ログイン時に送られるのも、その場限りのチャレンジに対する署名だけです。つまりパスワードの弱点だった「共有された秘密」そのものが存在しません。加えて鍵ペアはサイトごとに別々に作られるため、使い回しという概念も成立しません。

生体情報(指紋・顔)はサーバーに送られるのですか？

送られません。指紋や顔のデータは、デバイスの中で「秘密鍵の入った金庫の扉を開ける」ためだけに使われるローカルな照合であり、FIDOの設計上、生体情報がデバイスの外へ送信されることはありません。サーバーが受け取るのは「利用者の本人確認(ユーザー検証)が行われた」というフラグの立った署名だけで、指紋そのものはもちろん、その特徴量も一切含まれません。生体認証が使えない場面ではPINで代替できますが、このPINもWindows HelloのPINと同様にデバイスのローカルでのみ照合されるもので、ネットワークを流れない点はパスワードと決定的に異なります。

なぜパスキーはフィッシングに強いのですか？

利用者が偽サイトを見抜く必要が、仕組みの上でそもそもないからです。パスキーはサイトのドメイン(RP ID)に紐付けて作られ、ブラウザーは「いま表示しているサイトのドメイン」に対応するパスキーしか候補に出しません。本物そっくりの偽ドメインにアクセスしても、本物のサイト用のパスキーは選択肢に現れず、利用者は騙されようがありません。さらに署名にはブラウザーが確認したオリジンとRP IDのハッシュが焼き込まれるため、仮に署名を中継しても本物のサーバー側の検証で落ちます。パスワードやSMSコードのように「本物の資格情報を偽サイトに入力してしまう」という事故が構造的に起こせないのが、訓練や注意喚起に頼る対策との根本的な違いです。

スマホを失くしたらアカウントに入れなくなりますか？

同期型のパスキー(iCloudキーチェーンやGoogleパスワードマネージャーに保存されるもの)であれば、同じApple ID/Googleアカウントにサインインした新しいデバイスに復元できます。ただし、エンドツーエンド暗号化された保管庫の復元にはアカウントのパスワードだけでなく、以前の端末の画面ロック(パスコード)の入力などの追加の本人確認が求められるため、これらの回復手段も失うと復元できないことがあります。スマホ1台だけに全てを預けない構えが重要です。デバイス固定型(セキュリティキーやWindows Helloなど)は端末と運命を共にするので、重要なアカウントには複数のパスキーを登録しておくのが定石です。多くのサービスは1アカウントに複数のパスキーを登録できます。紛失時の無効化は種類で手順が変わる点に注意してください。同期型は各デバイスのコピーが同じ1つの資格情報なので、まずプラットフォームのアカウント側で紛失端末の削除やリモートワイプを行って端末上のコピーを使えなくします(サービス側のアカウント設定でそのパスキーを削除すると、全デバイスのコピーが一括で無効になります)。デバイス固定型なら、サービス側でその認証器のパスキーを削除すれば失くした鍵だけを無効化できます。組織で使う場合は「利用者が自力で復旧できる二重化」と「紛失時に管理者が失効させる手順」をセットで設計しておくことが重要です。

パスキーにも弱点はありますか？

あります。ただし弱点の場所が変わる、という言い方が正確です。認証そのものは公開鍵暗号で固くなるため、攻撃者はより弱い周辺部を狙います。具体的には、パスワードやSMSなど従来の手段が併存していればそこが最弱リンクとして残ること、アカウント回復フローを悪用して攻撃者が自分のパスキーを登録する手口、同期型ではクラウドアカウント自体の乗っ取りが新たな単一障害点になることです。またログイン後のセッションクッキーを盗む攻撃はパスキーでは防げないので、無関係な脅威が消えるわけでもありません。導入時は「パスキーを足す」だけでなく、回復フローの強化とフォールバック手段の計画的な縮小まで含めて設計する必要があります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。