テック羅針盤
ツール活用

パスキーはパスワードより安全？仕組みを解説

パスキーがフィッシングに強い理由を、公開鍵暗号、登録とログインの流れ、端末紛失時の復旧、同期方式の違いまで初心者向けに整理します。

公開日
  • #パスキー
  • #WebAuthn
  • #セキュリティ
  • #認証

パスキーは、パスワードの代わりにスマートフォンやパソコンを使って本人確認するログイン方式です。画面では顔認証、指紋認証、端末のPINなどを求められるため、「生体情報をWebサイトへ送っている」と思われがちですが、実際の中心にあるのは公開鍵暗号です。顔や指紋は、端末内にある認証用の秘密鍵を使ってよいか確認するために利用され、通常はログイン先へ送信されません。

結論から言えば、適切に実装されたパスキーは、使い回しや偽サイトへの入力が起きやすいパスワードより、フィッシングへの耐性を高めやすい仕組みです。ただし、パスキーに切り替えればアカウント乗っ取りの原因がすべて消えるわけではありません。端末の画面ロック、パスキーを保存するサービス、アカウントの復旧手段、ログイン後のセッション管理まで含めて安全性を考える必要があります。

パスキーの結論: 強みは「覚えなくてよい」だけではない

パスキーとパスワードの大きな違いは、ログインに使う秘密そのものを、人が読んだり入力したりしないことです。

パスワードは、利用者とサービスが同じ秘密の文字列を扱います。サービス側は通常、パスワードそのものではなくハッシュ化した値を保存しますが、利用者はログイン画面へ文字列を送る必要があります。そのため、偽サイトに入力する、複数サイトで使い回す、短く推測しやすい文字列を選ぶ、といった問題が起こります。

パスキーでは、登録するサイトごとに専用の公開鍵と秘密鍵の組を作ります。サービスが保存するのは公開鍵で、署名を作る秘密鍵は端末または認証情報を管理する仕組みに保持されます。FIDO Allianceは、FIDOの標準が公開鍵暗号を使い、フィッシング耐性のある認証を提供すると説明しています。

要点は、「入力が楽だから安全」なのではないことです。サイトごとに異なる鍵を使い、秘密鍵をサイトへ渡さず、登録先との対応をブラウザやOSが確認する設計が安全性の土台です。一方、端末を失ったときは、同期、予備の鍵、別の復旧手段が必要になります。

公開鍵暗号の最小知識

公開鍵暗号では、対になる「公開鍵」と「秘密鍵」を使います。たとえるなら、公開鍵はサービス側に預ける検査器、秘密鍵は利用者側だけが使う印章です。ただし、秘密鍵の内容を見て手作業で署名するわけではなく、端末内の認証器が計算を行います。

サービスはログインのたびに、使い回せないランダムな課題である「チャレンジ」を送ります。端末は秘密鍵でその課題に署名し、結果をサービスへ返します。サービスは登録済みの公開鍵を使い、その署名が正しいかを検証します。署名から秘密鍵を復元したり、公開鍵だけで新しい有効な署名を作ったりすることは想定されていません。

Webサイトでこの流れを実現する標準がWebAuthnです。W3CのWebAuthn Level 3仕様は、特定のRelying Party、つまり認証を受けるサービスに範囲を限定した公開鍵資格情報を作成・利用するAPIを定義しています。Webサイトのスクリプトが秘密鍵そのものへアクセスする仕組みではありません。

ここで大切なのは、顔認証や指紋認証とパスキーを同一視しないことです。生体認証や端末PINは、秘密鍵の利用を端末上で許可する「本人確認の方法」です。同じパスキーでも、端末によって顔、指紋、PINなど利用できる方法は変わります。また、生体情報を登録していない環境ではPINを使える場合があります。

公開鍵、ハッシュ、署名の役割を先に整理したい場合は、暗号化・ハッシュ・署名の違いも参考になります。

登録時の流れ: サイト専用の鍵を作る

パスキーの登録は、一般に次の順で進みます。

  1. 利用者が、すでにログインしているサービスの設定画面などで「パスキーを作成」を選ぶ。
  2. サービスが、ドメインを示すRP ID、利用者情報、チャレンジなどをブラウザへ渡す。
  3. ブラウザとOSが、パスキーを保存する認証器やパスワード管理サービスを選ぶ画面を出す。
  4. 利用者が顔、指紋、端末PINなどで作成を承認する。
  5. 認証器がそのサービス専用の鍵ペアを生成し、秘密鍵を保護された場所に保存する。
  6. 公開鍵と登録に必要な情報だけがサービスへ返され、利用者のアカウントに関連付けられる。

登録後、公開鍵はサービスのアカウントに保存され、秘密鍵は認証器が管理します。サービスから公開鍵が漏れても、それだけで有効な署名は作れません。ただし、サービス側もチャレンジ、RP ID、送信元のorigin、署名などを正しく検証する必要があります。

保存先には、端末内、AppleのiCloudキーチェーンやGoogle パスワード マネージャーなどの同期サービス、FIDO2対応の物理セキュリティキーがあります。作成画面で保存先を確認しておくと、機種変更や紛失時に迷いにくくなります。

ログイン時の流れ: 秘密鍵を渡さずに証明する

ログイン時には、登録時と同じ鍵をもう一度送るのではなく、その場で署名を作ります。

  1. サービスが新しいチャレンジを生成し、ブラウザへ送る。
  2. ブラウザとOSが、そのサービスに対応するパスキーを探す。
  3. 利用者が端末の顔、指紋、PINなどで利用を承認する。
  4. 認証器が秘密鍵でチャレンジや認証対象の情報に署名する。
  5. サービスが保存済みの公開鍵で署名を検証し、条件が合えばログインを認める。

チャレンジが毎回変わるため、過去の通信から署名結果だけを盗んで、そのまま再送する攻撃への対策になります。さらに、WebAuthnの資格情報はRP IDに結び付いています。W3C仕様では、公開鍵資格情報は登録されたものと同じRP IDのサービスでのみ認証に使えるよう制限されます。

スマートフォンにあるパスキーを、近くのパソコンで使う「クロスデバイス認証」もあります。パソコンのQRコードをスマートフォンで読み、スマートフォン側で本人確認します。Googleの公式ヘルプでは、この方式でBluetoothを有効にするよう案内しています。

フィッシングに強い理由と、残るリスク

フィッシングは、本物に似せた偽サイトへ利用者を誘導し、パスワードや確認コードを入力させる攻撃です。パスキーでは人が秘密を入力しません。さらに、ブラウザと認証器は、登録時のRP IDとログイン先の関係を確認します。本物とは異なるドメインの偽サイトが、本物用のパスキーで署名させようとしても、資格情報の対象が一致しません。

この点が、見た目や文章を見て本物か判断するパスワード認証との重要な差です。利用者が巧妙な偽画面を見破ることだけに、安全性を依存させずに済みます。

NISTのデジタルID指針は、WebAuthnを「検証者名への結び付け」によってフィッシング耐性を提供する標準の例に挙げています。一方、SMSや認証アプリなどのワンタイムパスワード（OTP）は、利用者がコードを手入力する方式では偽サイトから本物のサイトへ中継され得るため、同指針ではフィッシング耐性がある方式とは扱われません。OTPが無意味ということではなく、防げる攻撃の範囲が異なります。

一方で、パスキーが防ぐのは主に認証段階の攻撃です。次のような危険は別に考える必要があります。

  • ロック解除済みの端末を他人に操作される
  • 端末PINを盗み見られ、端末も一緒に奪われる
  • ログイン後のセッション情報をマルウェアなどに盗まれる
  • パスキー以外の弱い復旧手段を悪用される
  • サービス側の設定ミスやアプリの脆弱性を突かれる
  • 共有端末に誤ってパスキーを作り、別の利用者が端末を解除できる

Googleも、個人所有の端末だけにパスキーを作るよう案内し、端末を解除できる人はそのパスキーでアカウントへアクセスできる可能性があると注意しています。端末のPINは誕生日など推測しやすい値を避け、OSを更新し、画面ロックを短時間で作動させることが基本です。

移行時の確認を人の記憶だけに任せない考え方は、AIが書く記事に「機械の門番」を付ける方法で紹介した確認表づくりにも通じます。

認証方式とパスキーの保存方式を比較

「パスワードかパスキーか」と「同期型か端末固定型か」は別の選択です。主な違いをまとめると、次のようになります。

方式サービスへ登録するもの利用者がログイン時に扱うものフィッシング耐性紛失・機種変更への備え
パスワード通常はパスワードのハッシュ値パスワードを入力偽サイトへ入力する可能性があるパスワード管理と復旧手段が必要
パスワード＋手入力OTPパスワード情報とOTP用の設定パスワードと一時コードを入力コードを偽サイトに中継される可能性があるOTP端末の移行、予備コードが必要
同期型パスキー公開鍵端末の顔、指紋、PINなどで承認WebAuthnの正しい実装では高めやすい同じパスキープロバイダーでの同期条件と復旧方法を確認
端末固定型パスキー公開鍵登録端末や物理セキュリティキーで承認WebAuthnの正しい実装では高めやすい予備の端末・鍵・別の復旧手段を用意

表の「フィッシング耐性」は、認証方式そのものの性質を比較したものです。端末の乗っ取り、ログイン後のセッション窃取、弱いアカウント復旧まで防げるという意味ではありません。

紛失・同期・復旧: 保存先によって動きが違う

パスキーを使い始める前に最も確認したいのが、端末を失ったときの戻り方です。ここは「パスキー」という共通名だけでは決まりません。同期型か端末固定型か、どの認証情報管理サービスを使うか、ログイン先がどの復旧方法を用意しているかで変わります。

同期型は、秘密鍵を保護した形で認証情報管理サービスに保存し、複数端末から使えるようにします。Googleの公式資料では、パスキーは端末上で暗号化されてから同期され、新しい環境での復号にはGoogleアカウントへのログインと、端末の画面ロックまたは専用PINが必要と説明されています。

Appleの公式セキュリティ資料でも、iCloudキーチェーンの同期機能と復旧機能が説明されています。1台を失っても戻せる可能性がある一方、対応OSや本人確認の条件は事業者ごとに異なり、更新もされます。

端末固定型は、作成した端末や物理セキュリティキーだけに秘密鍵を置く方式です。クラウド同期を避けられる一方、その端末を失えば同じパスキーを別端末へ戻せない場合があります。Microsoftの公式案内も、端末固定型は同期されず、端末を失うと別の復旧方法がない限りそのパスキーを失うと説明しています。

紛失に備える実践策は次のとおりです。

  1. 別端末や物理セキュリティキーなど、予備のパスキーを登録できるか確認する。
  2. 復旧用の連絡先と復旧コードを整え、共有端末にはパスキーを作らない。
  3. 紛失時は別の信頼できる端末から、該当する端末とパスキーを失効させる。

Googleアカウントの公式ヘルプでは、端末を紛失した場合、アクセスできる別端末から関連するパスキーを削除する手順を案内しています。ただし、パスキー管理サービスから消す操作と、ログイン先サービス側で登録を失効させる操作は別の場合があります。どちらの一覧を操作しているのかを確認してください。

復旧手段は、パスキーを保存した端末と同じ場所だけに置かない方が確認しやすくなります。データの保管先を分ける基本は、家庭で始める3-2-1バックアップの作り方でも整理しています。ただし、パスキー管理サービスの復旧コードや秘密情報は、そのサービスの公式手順に従って保管してください。

移行の判断: まず重要アカウントで予備経路を整える

利用中のサービスがパスキーに対応しているなら、パスワードからの移行を検討する価値があります。ただし、最初からパスワードや既存の多要素認証をすべて削除するのではなく、復旧経路を確認しながら段階的に進める方が安全です。

次の順で確認すると整理しやすくなります。

  1. メール内のリンクではなく、公式アプリやブックマークから設定を開く。
  2. 保存先と同期対象を確認し、別端末で使えるか試す。
  3. 予備パスキー、復旧コード、本人確認済みの連絡先を用意する。
  4. 通常ログインと復旧を確認してから、既存方式を外すか判断する。

パスキーは「サイト専用の鍵を端末が扱う」ことで、使い回しと偽サイトへの入力を構造的に減らします。ただし、安全性は端末のロック、保存先、サービス側の実装、復旧手段の組み合わせで決まります。どこに保存され、どの端末で使え、失ったときにどう戻るのかまで確認することが、無理のない移行につながります。

FAQ

パスキーを使うと、パスワードはすぐ削除してよいですか？

すぐに削除できるとは限りません。サービスによってはパスワードが復旧手段として残り、パスキーだけに変更できない場合があります。別端末でのログインと復旧方法を確認してから、サービスの公式設定で判断してください。

顔認証や指紋認証のデータはWebサイトへ送られますか？

通常は送られません。顔や指紋は端末内で秘密鍵の利用を許可するために使われ、Webサイトには認証結果と署名などが返されます。端末や認証器の実装条件は、提供元の公式資料で確認してください。

スマートフォンを紛失したら、パスキーでログインできなくなりますか？

同期型なら、同じパスキープロバイダーを設定した別端末で利用できる場合があります。端末固定型は同じ鍵を復元できない場合があるため、予備パスキー、復旧コード、別の本人確認手段を事前に用意します。

パスキーがあれば、SMS認証や認証アプリは不要ですか？

一律には決められません。パスキーだけでログインできるか、既存の多要素認証を外せるかはサービスごとに異なります。特に復旧経路がSMSのままなら、その経路の安全性もアカウント全体に影響します。

一次情報の確認メモ

以下は2026-07-23に確認した公式資料です。仕様や対応環境、画面名は変更される可能性があるため、利用時点の最新情報は各公式ページで確認してください。