パスキーとは？仕組みとフィッシングに強い理由、使い始める前の注意点

パスキーは、パスワードの代わりに使うFIDO規格の認証情報です。スマートフォンやパソコンに保存され、端末のロック解除と同じ指紋・顔認証・PINでログインします。サイトごとに作られた鍵ペアで認証するため、偽サイトでは使えず、フィッシングに強いのが最大の特徴です。

パスキーとは

FIDO Allianceは、パスキーを「FIDO規格に基づく認証情報」と定義しています。スマートフォン、パソコン、ハードウェアのセキュリティキーに保存され、利用者は端末のロックを解除するのと同じ方法でサインインします。生体情報やPINの確認は端末の中で行われ、サーバーには「確認に成功した」という結果だけが届きます。

Webでは、パスキーはW3CのWeb Authentication API（WebAuthn）で実装されています。警察庁などの資料でも、パスキーは「FIDO AllianceとWorld Wide Web Consortiumにより規格化されているパスワードが不要な認証技術」と説明されています。

仕組みとフィッシングに強い理由

パスキーは公開鍵暗号を使ったチャレンジ・レスポンス方式です。MDNの説明をもとに、登録とログインの流れを整理します。

フィッシングに強い理由は、鍵が登録したサイトのドメインに結びついているためです。MDNは、署名がWebサイトのオリジンによって変わるため、偽のログインサイトが利用者になりすましてログインすることはできないと説明しています。利用者がうっかり偽サイトを開いても、そのドメイン用のパスキーは存在しないので、認証自体が成立しません。

サーバー側に保存されるのは公開鍵だけです。仮にサーバーから流出しても、秘密鍵がなければ認証できません。FIDO Allianceも、サーバーが盗まれる共有の秘密情報を持たない点をフィッシング耐性の核に挙げています。

NISTのデジタルアイデンティティガイドライン（SP 800-63B-4）は、パスワードはフィッシング耐性がなく、手入力するワンタイムパスワードやSMSなどもフィッシング耐性があるとはみなさないとしています。フィッシング耐性には暗号を使った認証が必要だという整理です。

同期パスキーとデバイス固定パスキー

パスキーには、保存のしかたによって2つのタイプがあります。

一般の利用者には、スマートフォンのOSやパスワード管理アプリが提供する同期パスキーが使いやすい選択です。一方で、NIST SP 800-63B-4は最も厳しい保証レベル（AAL3）では、秘密鍵を書き出せる同期型の認証器を使ってはならないとしています。管理者アカウントなど特に重要な用途では、セキュリティキーのようなデバイス固定型を検討する価値があります。

普及の状況と国内の動き

FIDO Allianceは、パスキーの効果について次のような数字を紹介しています。

国内では、フィッシングによる被害の拡大を背景に、公的機関がパスキーを推す動きが目立ちます。警察庁は令和7年の情勢資料で、所管省庁を通じて事業者に「パスキーの普及促進」を要請したと明らかにしました。令和8年3月に国家公安委員会・総務大臣・経済産業大臣が公表した不正アクセス行為の発生状況でも、アクセス管理者が講ずべき措置として、二要素認証に加えてパスキーなどフィッシングに耐性のある認証技術の積極的な導入を挙げています。

フィッシング対策協議会も、利用者向けの注意点として、パスキーに対応したサービスでは利用するよう勧めています。

使い始めるときと導入するときのポイント

利用者とサービス提供者では、気をつける点が少し違います。

1. 利用者：対応サービスから順に登録する

   サービスの設定画面にある「パスキー」「パスキーを作成」などの項目から登録します。ふだん使うスマートフォンやパソコンで本人確認をすれば完了です。

2. 利用者：端末のロックをしっかり設定する

   パスキーは端末のロック解除と同じ方法で使います。端末のPINやパスコードを推測されにくいものにしておくことが前提になります。

3. 利用者：復旧手段を確認しておく

   端末をなくしたときに備え、同期の設定や、ほかのログイン手段（予備の端末、復旧コードなど）がどうなっているかをサービスごとに確認しておきます。

4. 開発者：WebAuthnで実装する

   登録は navigator.credentials.create()、認証は navigator.credentials.get() を使います。WebAuthnはHTTPSなどの安全なコンテキストでしか動きません。サーバー側ではチャレンジ、オリジン、RP IDを必ず検証します。

5. 開発者：パスワードからの移行を設計する

   既存のパスワードログインを残す期間や、パスキーを失った利用者の本人確認の方法を決めておきます。復旧手段が弱いと、そこが新たな攻撃の入口になります。

MDNのサンプルをもとにした、認証時の呼び出しの例です。チャレンジは必ずサーバーで毎回生成します。

// サーバーから受け取ったチャレンジで認証を要求する
const credential = await navigator.credentials.get({
  publicKey: {
    challenge, // サーバーが生成したランダムな値（Uint8Array）
    rpId: "example.com",
    userVerification: "required",
  },
});
// credential をサーバーに送り、署名・チャレンジ・オリジン・RP ID を検証する

パスキーは必ず「検出可能な認証情報（discoverable credential）」として作られます。入力欄に autocomplete="username webauthn" を付け、mediation: "conditional" を指定すると、ユーザー名の入力欄でパスキーを候補として表示できます。

よくある質問