パスワードを入力せず、顔・指紋・端末のPINなどでログインできる「パスキー」。
便利なのは分かりますが、仕組みを調べるともっと気になる特徴があります。
サービス側の認証情報が盗まれても、それだけではログインに使えない。
パスワードなら、漏洩した文字列がそのまま不正ログインに使われることがあります。
では、なぜパスキーでは同じことが起きないのでしょうか。
そしてもう一つ。
パスキーを設定すれば、アカウント乗っ取りはもう防げるのか？
結論から言えば、そこまで単純ではありません。
この記事では、パスキーの仕組みを公開鍵暗号から追いながら、FIDO2、物理セキュリティキー、GoogleのTitan Security Keyまで整理し、パスキーの強さを本当に生かす使い方を考えます。
この記事でいう「盗まれても意味がない」は、主にサービス側に保存された公開鍵などが漏洩しても、それだけでは本人として署名できないという意味です。
端末やセッションまで盗まれても安全、という意味ではありません。
パスワードは「同じ秘密」を渡して証明する
まず、パスワード認証をかなり単純化します。
ユーザー
│
│ パスワードを入力
▼
サービス
│
│ 正しいか確認
▼
ログイン
実際のサービスは通常、パスワードそのものではなくハッシュ値を保存します。
しかし利用者側から見ると、ログインするたびに同じ秘密を入力していることに変わりはありません。
そのため、偽サイトに入力してしまえば攻撃者にその秘密を渡してしまう可能性があります。
本物: example.com
偽物: examp1e.com
見た目が完全に同じでも、人間が偽物だと気付けなければ入力できてしまいます。
パスキーは「秘密を渡さず、持っていることを証明する」
パスキーでは、公開鍵暗号を使います。1
登録時には大まかに、次の2つが用意されます。
| 鍵 | 主に存在する場所 | 役割 |
|---|---|---|
| 公開鍵 | サービス側 | 署名を検証する |
| 秘密鍵 | Authenticator / パスキープロバイダー側 | 署名を作る |
重要なのは、ログインのたびに秘密鍵そのものをサービスへ送るわけではないことです。
認証時は、サービスがランダムなChallengeを用意し、そのChallengeに対して秘密鍵で署名します。サービスは登録済みの公開鍵で署名を検証します。2
サービスが確認しているのは、
「秘密鍵を教えて」
ではなく、
「その秘密鍵を本当に持っているなら、このChallengeに署名できるよね？」
ということです。
「盗まれても意味がない」の正体
仮に、あるサービスからパスキーの認証データが漏洩したとします。
サービス側にある公開鍵を攻撃者が入手しても、対応する秘密鍵による正しい署名は作れません。
パスワードが漏洩
└─ 同じ文字列をログインに使える可能性がある
公開鍵が漏洩
└─ それだけでは本人の署名を作れない
FIDO Allianceも、パスキーでは暗号学的な鍵ペアを使い、従来のパスワードのような共有秘密をサービス側に置かないことを大きな特徴として説明しています。3
これが、パスキーがサーバー側の認証情報漏洩に強い理由です。
ただし、ここで「公開鍵なら何が漏れても平気」と考えるのは危険です。
たとえば次のものは別問題です。
- 秘密鍵を利用できる端末
- パスキープロバイダーのアカウント
- 端末を解除できるPIN
- ログイン済みのセッションCookieやトークン
- アカウント復旧に使えるメールや別の認証手段
パスキーが守っている範囲と、アカウント全体の範囲は同じではありません。
パスキーがフィッシングに強いもう一つの理由
公開鍵暗号だけなら、「偽サイトで署名させればいいのでは？」と思うかもしれません。
そこで重要になるのがWebAuthnです。
WebAuthnでは、Credentialが利用できる相手がRelying Party（RP）に結び付いています。認証時にはOriginやRP IDに関する情報も検証対象になります。4
つまり、本物が
example.com
だったとして、攻撃者が
example-login.example.net
のような偽サイトを作っても、本物のexample.com向けCredentialを好き勝手に使わせることはできません。
パスワード認証では、最後の判断を人間に頼る場面があります。
一方でパスキーは、認証情報そのものが利用先と結び付いているため、フィッシング耐性を持たせられます。1
Face IDや指紋そのものがパスキーではない
ここも誤解しやすいところです。
Face ID、Touch ID、Windows Hello、Androidの指紋認証などは、パスキーそのものではありません。
役割としては、
この端末に保存されている認証情報を
今このユーザーが使ってよいか確認する
ためのローカルなユーザー確認に近いものです。
FIDO Allianceも、パスキー利用時の生体情報はサービスへ送信されず、ユーザーの端末側で処理されると説明しています。1
つまり、
指紋 = パスキー
ではなく、
指紋・顔・PIN
↓
端末側で本人確認
↓
パスキーを使った署名を許可
という関係です。
パスキーはどこに保存されるのか
ここから、パスキーの使い方による違いが見えてきます。
FIDO Allianceは、パスキーを大きく同期型（synced passkeys）とデバイス固定型（device-bound passkeys）に分けています。1
| 同期型パスキー | デバイス固定型パスキー | |
|---|---|---|
| 主な保存先 | OSやパスワードマネージャー等 | 特定のAuthenticator |
| 複数端末での利用 | しやすい | 基本的にそのAuthenticatorが必要 |
| 機種変更 | しやすい | Authenticatorを持ち運ぶ |
| 利便性 | 高い | 少し手間 |
| 代表例 | スマホ・PC上のパスキー | FIDO2セキュリティキー上のパスキー |
同期型パスキー
スマホやPCで普段使うパスキーの多くはこちらです。
パスキープロバイダーを通して複数端末で利用できるため、スマートフォンを買い替えたときにも使いやすいという大きな利点があります。
一方で、パスキーだけを見るのではなく、そのパスキーを同期・管理するアカウントや端末も守る必要があります。
デバイス固定型パスキー
もう一つが、特定のAuthenticatorに紐付くパスキーです。
代表例がFIDO2対応の物理セキュリティキーです。
USBやNFCで接続する小さなキーの中にCredentialを保持し、そのキーを使って認証します。
「FIDOキー」と「パスキー」は別物なのか
ここは名前が多くて分かりにくいところです。
ざっくり整理すると、次のようになります。
| 用語 | ざっくりした役割 |
|---|---|
| FIDO2 | パスワードレス認証を実現するための標準群 |
| WebAuthn | Webサイトとブラウザ側でFIDO認証を扱うAPI |
| CTAP | PCやスマホと外部Authenticatorがやり取りするためのプロトコル |
| パスキー | パスワードレス認証に使うFIDO Credential |
| セキュリティキー | FIDO認証を行える物理Authenticator |
FIDO Allianceは、パスキーをFIDO Credentialとして説明しており、FIDO2ではWebAuthnとCTAPが利用されます。1
つまり、
パスキー vs FIDOキー
という完全に別の方式ではありません。
FIDO2対応の物理セキュリティキーは、パスキーを保存する場所にもなれます。
Googleも、セキュリティキー上にパスキーを作成するにはFIDO2対応が必要だと案内しています。5
具体例：GoogleのTitan Security Key
物理セキュリティキーの具体例として分かりやすいのが、GoogleのTitan Security Keyです。
2026年8月時点の日本向けGoogle Storeでは、
- USB-C / NFC
- USB-A / NFC
の2種類が案内されています。6
Googleによれば、Titan Security KeyはFIDOのオープン標準を採用しており、専用のセキュアエレメントチップも搭載しています。6
また、GoogleアカウントではFIDO対応セキュリティキーを2段階認証に利用でき、FIDO2対応キーならキー上にパスキーを作成してパスワードレス認証にも利用できます。5
つまり同じ「物理キー」でも、
パスワード
+
Titanを第2要素として使う
という使い方と、
Titan上のパスキーで認証する
という使い方があります。
Titanに限らず、YubiKeyなどFIDO2に対応した他のセキュリティキーでも、基本的な考え方は同じです。
物理キーを使う場合は、1本を唯一のログイン手段にして紛失すると復旧が難しくなることがあります。
重要なアカウントで本格的に使うなら、予備キーや十分に強い復旧手段も一緒に設計する必要があります。
では、物理キーを使えば絶対に乗っ取られないのか
ここまで読むと、
「じゃあTitanなどの物理キーにパスキーを入れておけば最強なのでは？」
と思うかもしれません。
しかし、ここが一番重要です。
強い認証方式を1つ追加しても、アカウント全体が同じ強さになるとは限りません。
攻撃者は、わざわざ一番強い入口を突破する必要がないからです。
1. パスワードが残っている
たとえば、
| ログイン方法 | 強さ |
|---|---|
| パスキー | 強い |
| 物理FIDO2キー | 強い |
| パスワード | 利用可能 |
| SMS | 利用可能 |
という状態だったとします。
攻撃者がパスキーを破れないなら、別の方法を狙えばよいだけです。
玄関を強固にしても、裏口が弱ければそこを狙われます。
サービスが許す範囲で、不要な弱いログイン方法を減らすことが重要です。
2. アカウント復旧が弱い
認証を強くすると、必ず出てくる問題があります。
「スマホも物理キーもなくしたらどうするのか？」
利用者を救うためにアカウント復旧は必要です。
しかし、
通常ログイン
└─ FIDO2キー必須
アカウント復旧
└─ メール1通だけ
となっていれば、攻撃者は通常ログインを狙う必要がありません。
復旧フローも認証の一部として考える必要があります。
3. 端末そのものを使われる
同期型パスキーを使っているスマートフォンが、解除された状態で第三者の手に渡れば話は変わります。
パスキーは「端末を安全に保つ必要がなくなる仕組み」ではありません。
むしろ、パスキーを重要な認証情報として使うほど、
- 端末のPINを弱くしない
- 生体認証を適切に使う
- OSを更新する
- 紛失時に遠隔で保護できるようにする
といった端末側の防御も重要になります。
4. ログイン後のセッションを盗まれる
そして、パスキーでも直接は解決できない代表例がセッション窃取です。
Webサービスでは、一度認証すると毎回パスキーを要求するのではなく、Cookieやトークンでログイン状態を維持するのが一般的です。
パスキーで正常にログイン
↓
セッションCookieが発行される
↓
マルウェアがCookieを盗む
↓
攻撃者がセッションを再利用
この場合、攻撃者はパスキーを突破していません。
パスキーを通過した後の状態を盗んでいます。
Googleも、マルウェアによるCookie窃取とセッションハイジャックを問題として説明し、2026年にはChromeでDevice Bound Session Credentials（DBSC）の展開を進めています。7
パスキーは非常に強いフィッシング耐性を持つ認証方式ですが、マルウェア対策・セッション保護・アカウント復旧まで自動的に安全にするものではありません。
では、どう使うと「真価」を発揮できるのか
個人利用なら、すべてを物理キーにする必要はないと思います。
パスキーの利便性を捨てず、重要度に応じて強度を上げる方が現実的です。
普段使いのサービス
まずは、信頼できるスマートフォンやPCの同期型パスキーを使うだけでも大きな改善です。
パスワードを入力する機会そのものを減らせるため、フィッシングやパスワード使い回しの問題を避けやすくなります。
メール・GitHub・クラウドなど重要なアカウント
他サービスの復旧や開発環境までつながるアカウントでは、もう一段強くしておく価値があります。
たとえば、
普段のログイン
└─ スマホ / PCのパスキー
追加の強い認証手段
└─ TitanなどのFIDO2セキュリティキー
紛失対策
└─ 予備キー または 十分に強い復旧手段
という構成です。
物理キーを主な認証手段にするなら、1本だけではなく予備も考えた方が安全です。Googleも、セキュリティキーを失った場合に備えて別のサインイン手段を用意するよう案内しています。5
一番強い認証ではなく「一番弱い入口」を見る
パスキーを設定すると、設定画面に「パスキー」の文字があるだけで安心したくなります。
しかし、本当に確認したいのは一番強い認証方法ではありません。
そのアカウントに残っている一番弱い入口です。
パスキーが非常に強くても、復旧メールや古い認証方式、ログイン済み端末が弱ければ、そこが攻撃対象になります。
パスキーを追加した後こそ、次を確認しておきたいところです。
- 不要なパスワードログインを無効化できないか
- SMSなど弱いフォールバックが残っていないか
- 復旧用メールアドレス自体が十分に保護されているか
- 知らない端末や古いセッションが残っていないか
- 紛失した端末のパスキーが残っていないか
- 重要アカウントに物理FIDO2キーを追加できないか
- 物理キーを使うなら予備を用意しているか
開発者側も「WebAuthn対応」で終わりではない
これはサービスを作る側でも同じです。
ログイン画面をWebAuthnに対応させても、
ログイン → パスキー必須
メールアドレス変更 → セッションだけで可能
パスキー追加 → セッションだけで可能
アカウント復旧 → 弱い本人確認
となっていれば、せっかく強い認証を導入しても迂回される余地が残ります。
特に重要なのは、
- 新しいパスキーの登録
- パスキーの削除
- メールアドレス変更
- 復旧方法の変更
- 管理者権限など重要権限の変更
といった操作です。
これらでは、必要に応じて再認証を要求する設計も検討すべきです。
パスキー対応は、単にログインフォームを置き換える機能ではありません。
登録・認証・復旧・Credential管理・セッションまで含めて、アカウント全体の認証設計を見直すきっかけになります。
まとめ
パスキーが「盗まれても意味がない」と言われる大きな理由は、ログインに使う秘密そのものをサービス側へ渡さないことにあります。
公開鍵が漏洩しても、それだけでは秘密鍵による正しい署名を作れません。
さらにWebAuthnでは認証先との結び付きがあるため、従来のパスワードと比べてフィッシングにも強い設計になっています。
そしてパスキーは、スマホやPCだけのものではありません。
Titan Security KeyなどのFIDO2対応セキュリティキー上に保存し、物理Authenticatorを使って認証することもできます。
ただし、
パスキーを設定した
↓
絶対に乗っ取られない
ではありません。
本当に見るべきなのは、
パスキー
端末
パスワード
2段階認証
アカウント復旧
ログイン済みセッション
を含めたアカウント全体です。
パスキーという「一番強い入口」を追加するだけではなく、攻撃者が使える弱い別ルートを減らす。
そこまでやって初めて、パスキーは真価を発揮するのではないでしょうか。
参考資料
-
Google for Developers, Passkeys developer guides ↩
-
FIDO Alliance, Passkey Security ↩
-
W3C, Web Authentication: An API for accessing Public Key Credentials ↩
-
Google Account Help, Use a security key for 2-Step Verification ↩ ↩2 ↩3
-
Google Store, Titan Security Key ↩ ↩2
-
Google Online Security Blog, Protecting Cookies with Device Bound Session Credentials ↩