本文へスキップ
ITDセキュリティ対策プラットフォーム
目的から探す
検索
用語辞典13分で読める

パスキーとは：パスワードを使わず、盗まれにくいログインの仕組み

パスキー（passkey）はFIDO標準の公開鍵認証情報です。認証先に秘密鍵を渡さず、偽サイトでの認証に強い仕組み、同期型と端末固定型の違い、PIN・生体認証の利用者確認、MFAとの関係と復旧の注意点を解説します。

本文を読む
#パスキー#認証#パスワードレス
公開日
更新日
目次

盗まれる可能性のあるパスワードを使わずにログインできるようにするのが、パスキーです。仕組みと、パスワードやSMS認証との違いを解説します（攻撃手順は載せません）。

仕組み：認証先に秘密鍵を渡さない

パスキーは公開鍵暗号（FIDO2 / WebAuthn という標準）で動きます。登録時に端末が鍵のペアを作り、公開鍵だけをサーバーに渡します。ログイン時は、サーバーからの「お題（チャレンジ）」に端末内の秘密鍵で署名して返すだけ。認証先へ秘密鍵を送信することはありません。端末固定型は認証器から秘密鍵を出さず、同期型は保護された同期基盤を通じてほかの端末でも使えるようにします。

パスワード

あなた と サーバー が同じ秘密を共有。サーバーが漏れる／偽サイトに入力すると盗まれる

パスキー

秘密鍵は認証先へ渡さない。同期型と端末固定型は保存条件が異なる

パスワードは認証先と共有する秘密。パスキーは秘密鍵を認証先へ渡さず、同期の有無は保存方式で異なる。

「サーバーには公開鍵しか無い」ことが効きます。公開鍵は文字どおり公開してよい値なので、データベースが漏れても、それ単体ではログインに使えません（パスワードの保存とは前提が逆です→ ハッシュ化とは）。

パスワード＋SMS と何が違うのか

パスワード＋SMSコード

  • 共有秘密（パスワード）が漏れる／使い回しで連鎖
  • 偽サイトに入力すると、コードごと中間者に中継される
  • 「自分は見破れる」という過信が前提になりがち

パスキー

  • 認証先とパスワードを共有せず、公開鍵だけではログイン用の署名を作れない
  • 署名がドメインに紐づく＝偽サイトでは成立しない
  • 利用者が気づかなくても、仕組みで偽サイトを弾く

中間者型フィッシング（AiTM）は、注意深く正しいコードを入れてもそのコードごと中継してしまいます（→ フィッシングとは）。パスキーは署名がドメインに縛られるため、この経路が原理的に塞がります。

パスキー・2FA・物理キーの違い

パスキーは「2FAの一種」とも「パスワードの代わり」とも説明されるため、混乱しやすい言葉です。役割で並べると次のとおりです。

パスキーパスワード＋ワンタイムパスワード物理セキュリティキー
ログインで使うもの秘密鍵の署名。利用者確認を要求する場合は指紋・顔・PIN等も確認覚えた文字列＋6桁などのコードUSBやNFCの鍵の中の秘密鍵＋PINやタッチ
サーバーに保存されるもの公開鍵パスワードのハッシュ（認証アプリ方式ならコード生成用の秘密値も）公開鍵
偽サイトに入力した場合署名が成立しないパスワードもコードも中継されうる署名が成立しない
端末をなくしたとき同期していれば別の端末で使える認証アプリの移行やリカバリーコードが必要予備のキーや別の復旧方法がなければ入れないおそれ
向いている人ほぼすべての個人利用パスキー非対応のサービス管理者アカウント・高リスクの人

FIDO2対応の物理セキュリティキーには、端末固定のパスキーを保存できます。違いは、秘密鍵がキーの外に出ず、クラウドに同期されない点にあります。2FAという考え方そのものは 二要素認証（2FA）とは、コード方式の仕組みは ワンタイムパスワード（OTP）とは で解説しています。

同期パスキーと、端末から出ないパスキー

パスキーには保存のしかたで2種類あります。

  • 同期パスキー：iCloudキーチェーン、Googleパスワードマネージャー、パスワード管理アプリなどに保存され、同じアカウントの別の端末でも使える。端末をなくしても締め出されにくい
  • 端末固定のパスキー：物理セキュリティキーなど、作った機器の中にだけ残る。同期されない分、保管場所を限定できる

米国国立標準技術研究所（NIST）の認証ガイドライン SP 800-63B（2025年7月の第4版）は、同期パスキーを中程度の保証レベル（AAL2）で使ってよいとし、最も高いレベル（AAL3）では同期しない鍵を求めています。利用者確認や同期基盤の保護などの要件を満たす必要があり、同期型という名称だけでAAL2への適合を保証するものではありません。必要な保証レベル、端末・同期アカウントの保護、復旧条件を合わせて方式を選びます。

パスキーを足しても残る弱点

パスキーの仕組み自体は偽サイトに強くても、アカウント全体の強さは、いちばん弱いログイン手段で決まります。

  • パスワードでのログインが残っている：パスキーを登録しても、多くのサービスはパスワードとSMSのコードでも入れるままです。偽サイトはパスキーではなく、この残った方法を求めてきます
  • 復旧の手段が弱い：アカウント復旧がSMSや登録メールだけで済むなら、そこが入口になります。復旧用メールのアカウント自体もパスキーなどで守ります
  • 端末のロックが弱い：パスキーは端末のロック解除で使えるようになるため、推測しやすい画面ロックのPINは避けます

具体例：証券口座の乗っ取りと、パスキーの必須化

2025年、証券会社を装った偽サイトなどで盗まれたログインIDやパスワードを使い、他人の証券口座で不正な取引を行う被害が多発しました。金融庁は注意喚起のページで、パスキー認証などのフィッシングに耐性のある多要素認証の必須化が進められているとして、利用設定を急ぐよう呼びかけています。

日本証券業協会は「インターネット取引における不正アクセス等防止に向けたガイドライン」を改正し、2025年10月15日から施行しました。ログイン時・出金時・出金先銀行口座の変更時などの重要な操作で、フィッシングに耐性のある多要素認証（例：パスキーによる認証、PKIをベースとした認証）を実装し、既定の設定として必須にすることを求めています。必要な機器を持たない顧客には、代わりの多要素認証を用意するとしています。

この事例から分かることは2つあります。

  • 業界の方針が「利用者の注意」から「仕組み」へ移った：偽サイトを見分けるよう呼びかけるだけでは被害が止まらず、偽サイトでは成立しない認証を既定にする方向へ変わりました
  • 例示されたのはパスキーとPKIで、人がコードを読んで入力する方式は含まれていない：NISTも、手で入力するワンタイムパスワードはフィッシング耐性を持てないとしています

証券会社の顧客向けの具体的な行動は、大和証券の委託先への不正アクセスの記事で、パスキー認証と操作通知の設定として整理しています。

自分のアカウント・サービスで確認する方法

1

重要なアカウントでパスキーが使えるか確かめる

メール、パスワードマネージャー、クラウド、証券・銀行、GitHubなどのセキュリティ設定に「パスキー」の項目があるかを見る。使っているパスワードマネージャーの一覧で、どのサービスにパスキーが保存済みかも確認できる。

2

2台目の端末か予備のキーにも登録する

同期パスキーなら同じアカウントの別の端末で使えるかを試す。同期しない物理キーを使うなら、予備のキーを1本登録し、別の場所に保管する。

3

パスワードとSMSの抜け道を確認する

パスキーを足したあと、パスワードだけ・SMSのコードだけでログインや復旧ができる経路が残っていないかを見る。パスワードでのログインを省く設定や、SMSを外す設定があれば使う。リカバリーコードはパスワードマネージャーなど別の場所に保存する。

4

サービスを作る側は、ドメインの検証と復旧経路を見る

パスキー（WebAuthn）を実装する場合は、署名の対象が自分のドメイン（RP ID）とオリジンになっているかをサーバー側で検証する。署名の検証は自作せず、実績のあるライブラリを使う。パスキーを導入しても、SMSだけで復旧できる経路が残っていればそこが弱点になる。

当サイトの視点：全部いきなり置き換えなくていい

パスキーは強力ですが、「今日から全アカウントをパスワードレス」にする必要はありません。当サイトの立場は重要アカウントから段階的にです。まずメール・クラウド・パスワードマネージャーといった、ほかのアカウントの復旧や管理に使うアカウントにパスキーを追加し、回復手段（複数端末への登録・バックアップ）を整える。パスワードが残るサービスは、パスワードマネージャーとフィッシング耐性MFAで守りつつ、対応サービスから順にパスキーへ移していくのが現実的です。

出典（一次情報）

  • FIDO Alliance — Passkeys FAQ（同期型/端末固定型・利用者確認）

  • FIDO Alliance「Passkeys」 — fidoalliance.org（パスキーの定義、同期パスキーと端末固定のパスキー、フィッシング耐性）

  • W3C「Web Authentication: An API for accessing Public Key Credentials Level 3」 — w3.org（RP ID とオリジンによる鍵の紐づけ）

  • NIST SP 800-63B-4「Digital Identity Guidelines: Authentication and Authenticator Management」（2025年7月） — pages.nist.gov（同期パスキーはAAL2で使用可・AAL3では不可、フィッシング耐性の条件、生体情報の照合は端末内で行う）

  • 日本証券業協会「インターネット取引における不正アクセス等防止に向けたガイドライン」の改正について（2025年10月15日） — jsda.or.jp（PDF）

  • 金融庁「インターネット取引サービスへの不正アクセス・不正取引にご注意ください」 — fsa.go.jp

  • passkeys.dev（パスキーを実装する開発者向けの解説） — passkeys.dev

次に読む

よくある質問

Qパスキーはパスワードと何が違いますか？
A

パスワードは『あなたとサーバーが共有する秘密の文字列』なので、漏れれば誰でも使えます。パスキーは共有する秘密を持ちません。端末の中にある秘密鍵で署名し、サーバーには対になる公開鍵しか保存されません。認証先から公開鍵だけが漏れても、それだけで秘密鍵の署名を作れないのが根本的な違いです。同期型では、暗号化された認証情報の同期先も保護します。

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

パスキーの署名は『どのサイト（ドメイン）向けか』に紐づいています。偽サイトでログインさせようとしても、ドメインが一致しないため署名そのものが成立しません。つまり、利用者が偽サイトに気づかなくても、仕組みとして偽サイトには通らない。パスワード＋SMSコードが中間者攻撃で丸ごと中継されてしまうのとは対照的です。

Q端末をなくしたらログインできなくなりますか？
A

パスキーは多くの場合、OSやパスワードマネージャーのクラウド同期でバックアップされ、別の端末でも使えます（同期パスキー）。加えて、複数の端末・キーにパスキーを登録しておく、回復用の手段を用意しておくのが安全です。1つの端末だけに紐づけて回復手段を持たないのは避けます。

Qパスキーと二要素認証（2FA）は何が違いますか？
A

2FAは異なる2種類の要素を使う認証で、パスキーは認証情報の方式です。サービスが利用者確認を要求する構成では、認証器の所持とPIN・指紋・顔などによる確認を組み合わせます。パスキーを使うという名称だけで、常にMFAの条件を満たすとは判断せず、サービスの要求と設定を確認します。

Qパスキーの指紋や顔のデータはサーバーに送られますか？
A

送られません。指紋や顔は、端末の中で秘密鍵を使えるようにするための確認にだけ使われ、照合も端末の中で行われます。認証先が受け取るのは署名や利用者確認の結果などで、生体情報そのものではありません。

Qパスキーを設定すれば、パスワードは使われなくなりますか？
A

サービスによります。多くのサービスでは、パスキーを足したあともパスワードやSMSのコードでのログインが残っています。偽サイトはその残った方法を求めてくるので、パスワードでのログインを省く設定があれば使い、弱い復旧手段が残っていないかを確認してください。