パスワードとパスキーとは何か？
次のシナリオを考えてみてください。午前2時14分、SOCアナリストが認証ログを確認し、過去1時間に数百回のログイン失敗があったことを発見します。午前2時31分、過去の侵害で盗まれた認証情報を使ったログインが1件成功し、セキュリティスタックはこれを検知しませんでした。
これがパスワードとパスキーの本質的な違いです。パスワードは共有シークレットモデルで動作し、同じ認証情報がデバイスとサーバーの両方に存在します。攻撃者がサーバーを侵害したり、認証情報をフィッシングで入手した場合、認証に必要なすべてを手に入れることになります。パスキーは非対称暗号技術によってこの脆弱性を排除します。秘密鍵はデバイスから決して離れず、サーバーに保存される公開鍵は攻撃者にとって暗号的に無意味です。
22,052件のセキュリティインシデントを分析した2025年版DBIRによると、侵害の88%が盗まれた認証情報に関与しています。パスワードは、複雑さの要件や定期的な変更、ユーザートレーニングに関係なく、システム全体の脆弱性を生み出します。
パスキーは、FIDO2プロトコルアーキテクチャを2つの補完的な標準で実装します。1つはブラウザやプラットフォームの認証情報管理のためのW3C Web Authentication（WebAuthn）仕様、もう1つはアプリケーションと認証器間の通信のためのFIDO Alliance CTAP2（Client to Authenticator Protocol）です。これらのプロトコルにより、パスワードの送信を、特定ドメインに紐づいた暗号学的チャレンジレスポンス認証に置き換えます。
パスキーを登録すると、認証器はそのアカウント専用の公開鍵・秘密鍵ペアを生成します。秘密鍵はデバイスのハードウェアセキュリティモジュールやセキュアエンクレーブ内に安全に保管され、ネットワークを通じて送信されることはありません。サーバーには公開鍵のみが登録されます。認証時、サーバーは暗号学的チャレンジを送信し、デバイスが秘密鍵で署名することで、鍵自体を公開することなく所有を証明します。
これらのアーキテクチャ上の違いが、どの攻撃が成功し、どの攻撃が失敗するかを直接左右します。
パスワードとパスキーのサイバーセキュリティへの関係
パスキーは、侵害の大半を引き起こす認証の弱点に対応します。 NIST Special Publication 800-63BはAAL2でフィッシング耐性のある認証を要求し、AAL3ではそれを必須としています。また、 CISA CPG 2.0はパスキーをフィッシング耐性のある手法として明示的に推奨しています。パスワードは、長さや複雑さ、変更頻度に関係なく、これらの要件を満たすことができません。
データがその理由を裏付けています。 2025年版DBIRの調査によると、クレデンシャルスタッフィング攻撃はピーク時の認証トラフィック全体の44%を占め、 侵害されたアカウントの80%が他サービスでの認証情報漏洩を経験していました。 ランサムウェアは侵害の44%に登場し、パスワードの使い回しが初期アクセスの入口となっています。2021年のColonial Pipeline攻撃はその好例で、攻撃者は1つの侵害されたVPNパスワードを使ってネットワークにアクセスし、 DOJの発表によれば440万ドルの身代金支払いにつながりました。
パスキーはこれらの攻撃経路を排除します。 FIDO Allianceによれば、パスキーの設計は、公開鍵がサーバーに保存されていても、ユーザーデバイス上の秘密鍵がなければ認証に使えないため、フィッシング、クレデンシャルスタッフィング、大規模なデータ侵害に対して耐性があります。
具体的な攻撃ベクトルを詳しく見る前に、次の表は、セキュリティチームにとって重要な観点でパスワードとパスキーを比較しています。
パスワード vs パスキーの概要比較
パスワードとパスキーの違いは、セキュリティアーキテクチャ、ユーザー体験、コンプライアンス対応、エコシステムサポートに及びます。この比較は、FIDO Allianceの調査、NIST標準、Verizon DBIRデータに基づき、各観点を定量化しています。
| Feature | Password | Passkey |
| Authentication Model | Shared secret (server stores credential) | Asymmetric cryptography (server stores only public key) |
| Phishing Resistance | None; credentials transmit to any domain | Cryptographic domain binding blocks phishing sites |
| Credential Stuffing Risk | High; reused credentials work across services | None; each credential is unique per service |
| Login Success Rate | 63% average (FIDO Alliance Passkey Index) | 93% average (FIDO Alliance Passkey Index) |
| Login Speed | ~27.5 seconds average | ~13.6 seconds average (FIDO Alliance Passkey Index) |
| User Action Required | Remember and type password, then complete MFA | Biometric scan or device PIN |
| Server Breach Impact | Hashed passwords exposed to offline attack | Public keys are cryptographically useless without private keys |
| Recovery Method | Password reset via email | Synced passkeys, backup authenticators, or admin recovery |
| Compliance (NIST AAL2/AAL3) | Cannot meet phishing-resistant requirements | Meets phishing-resistant requirements |
| Platform Support | Universal | Apple, Google, Microsoft ecosystems; 48% of top 100 websites |
以下のセクションでは、パスキーが排除することを目的としたパスワードの脆弱性から、各観点を詳しく解説します。
セキュリティ脆弱性：パスワード攻撃ベクトル
パスワードは、フィッシング脆弱性、クレデンシャルスタッフィングへの曝露、中間者攻撃による傍受、データベース侵害時の影響という4つの主要な弱点を生み出します。 NIST SP 800-63Bは、FIDO2/WebAuthnの非対称暗号アーキテクチャが、パスワードでは実現できないフィッシング耐性認証を可能にすることを確認しています。
- パスワードベース認証はフィッシング攻撃に依然として有効です。 2025年版Verizon DBIRにまとめられた調査によると、ユーザーはトレーニング後も模擬フィッシング演習でリンクをクリックし続けています。ユーザーが攻撃者管理のドメインでパスワードを入力すると、その認証情報は平文で攻撃者に送信され、即座に実際のサービスで試されます。2023年のMGM Resorts侵害はその好例で、攻撃者は ソーシャルエンジニアリングを用いてMFAを回避し、SEC提出資料によれば約1億ドルの損害をもたらしました。
- クレデンシャルスタッフィングはパスワードの使い回しを大規模に悪用します。 Verizonの2025年版Data Breach Investigations Reportによると、侵害されたアカウントの80%が他サービスでの認証情報漏洩を経験していました。ユーザーは消費者向けサービス、業務プラットフォーム、企業アプリケーション間で認証情報を使い回すのが一般的です。いずれかの消費者向けサービスが侵害されると、攻撃者は即座にその認証情報を企業の 認証エンドポイントで試行します。
- 中間者攻撃はパスワード送信を傍受します。 MITM攻撃者はユーザーとサーバーの間に位置し、偽のSSL証明書などの手法で通信を傍受します。パスワードベース認証は、本人証明のためのシークレット送信が必要であり、その送信自体が輸送暗号化の有無に関わらず脆弱性となります。
- データ侵害はハッシュ化済みパスワードも漏洩させます。 認証データベースには平文ではなくパスワードハッシュが保存されていますが、この保護は認証情報の漏洩を遅らせるだけで防止はできません。攻撃者がデータベースにアクセスすると、アカウントロックやレート制限を回避しつつ、ハッシュ化されたパスワードに対してオフライン総当たり攻撃を実行できます。データベースが侵害された場合、全ユーザーのパスワードを即時リセットする必要があります。
パスキーは、認証情報の窃取を無効化する暗号アーキテクチャによって、これらの脆弱性を排除します。
パスキーの暗号アーキテクチャ
パスキーが提供するセキュリティ保証は、基盤となる暗号技術の仕組みによるものです。パスワードが共有値の秘密性に依存するのに対し、パスキーは公開鍵暗号を用い、認証の証明と認証の秘密が本質的に異なるオブジェクトとなります。
認証時、サーバーはWebAuthn APIを介してユーザーの認証器に暗号学的チャレンジを送信します。認証器はデバイスに保存された秘密鍵でこのチャレンジに署名し、署名済みアサーションがブラウザ経由でサーバーに返送されます。サーバーは、事前に登録された公開鍵でデジタル署名を検証します。このチャレンジレスポンス方式により、秘密鍵を公開することなく所有を証明できます。
ドメインバインディングがフィッシング耐性を提供します。 WebAuthnは、認証を登録時の特定オリジンドメインに暗号的に紐づけます。ユーザーが フィッシングサイトで自社ドメインを模倣した場合でも、ブラウザのWebAuthn実装が誤ったオリジンへの認証レスポンス送信をブロックします。この保護はプロトコルレベルで動作し、ユーザーの判断に依存しません。フィッシングサイトは、たとえユーザーが見た目で完全に騙されても、有効な認証レスポンスを受け取ることができません。
暗号アルゴリズムは、政府・企業導入向けのNIST仕様に準拠しています。サポートされるアルゴリズムは以下の通りです：
- 署名操作用のECDSA、RSA、EdDSA各種
- ハッシュ用のFIPS 202（SHA-3）
- 鍵導出用のSP 800-108
- 乱数生成用のSP 800-90a
これらはFIDO Authenticator Allowed Cryptography Listで定義されており、NIST標準を明示的に参照しています。このアーキテクチャ上に構築されたディスカバラブルクレデンシャルにより、ユーザー名を覚える必要のないパスワードレス認証や、ブラウザの自動入力によるログイン体験の効率化が実現します。
この暗号基盤は、日常利用時のパスワードとパスキーの体感的な違いにも直結します。
ユーザー体験：パスワード vs パスキーログイン
パスワード認証は、ユーザーが各サービスごとに固有の認証情報を記憶し、正確に入力し、さらにSMSコード入力やプッシュ通知承認など追加のMFA手順を完了する必要があります。この多段階プロセスは、測定可能な摩擦を生みます。 FIDO Alliance Passkey Indexによると、パスワードベースのログイン成功率は平均63%で、3回に1回以上は認証情報の失念やタイプミス、MFAトークンの期限切れで失敗しています。
パスキー認証はログインを1ステップに短縮します。ユーザーは生体認証（Face ID、指紋、Windows Hello）またはデバイスPINで認証します。 FIDO Alliance World Passkey Day調査によれば、パスキーはログイン成功率93%、1回あたり平均13.6秒で、パスワードの27.5秒より大幅に高速です。覚えるものも、入力するものも、傍受されるものもありません。生体データはデバイス内に留まり、サーバーに送信されることはありません。
組織にとって、このUX向上は運用コスト削減に直結します。FIDO Alliance Passkey Index参加企業は、パスキー導入後、サインイン関連のヘルプデスク問い合わせが81%減少し、ITサポートの主要な定期コストの1つが解消されたと報告しています。
これらのUXメリットは、ユーザーやアプリケーションが実際にどこで動作しているかに依存するため、プラットフォームやエコシステムの対応状況が重要となります。
プラットフォームとエコシステムのサポート
パスキーのサポートは主要プラットフォームで広く利用可能となっています：
- Apple はiCloudキーチェーンを通じて、iOS、iPadOS、macOS間でパスキーをエンドツーエンド暗号化で同期します。
- GoogleはAndroid 9+およびChrome上のGoogleパスワードマネージャーでパスキーを管理し、同一Googleアカウントにサインインした全デバイス間で同期します。
- Microsoft はWindows 10+のWindows Helloを通じてパスキーを統合し、EdgeやMicrosoftアカウントでサポートしています。
FIDO Allianceによると、世界のトップ100ウェブサイトの48%がパスキー認証をサポートしており、2022年の2倍以上となっています。
クロスプラットフォーム認証はQRコードの引き継ぎやBluetooth近接通信で実現し、ユーザーはスマートフォンに保存したパスキーでノートPCに認証できます。1PasswordやBitwardenなどのサードパーティパスワードマネージャーもパスキーの保存・同期に対応し、特定エコシステムへの依存を低減しています。FIDO AllianceのCredential Exchange Protocol（CXP）も成熟しつつあり、プロバイダー間の安全なパスキー移行を可能にし、ベンダーロックインの懸念に対応しています。
ブラウザサポートも充実しています。Safari、Chrome、Edge、Firefoxはすべてパスキー認証に必要なWebAuthn APIを実装しており、ウェブアプリケーションはブラウザ固有のコードなしでパスキーをサポートできます。
このように広範なプラットフォームサポートがある一方で、パスキーには導入前に考慮すべきトレードオフも存在します。
パスキーの制限事項とトレードオフ
どの認証技術にも摩擦はあり、これらの制約を理解することで現実的な導入戦略を構築できます。
- エコシステム依存は依然として課題です。 同期されたパスキーは現時点でプラットフォーム固有の認証情報管理に紐づきます。Apple iCloudキーチェーンを利用する従業員は、Androidデバイスから直接パスキーにアクセスできません。QRコード認証やサードパーティパスワードマネージャーで回避策はあるものの、クロスエコシステムの可搬性は発展途上です。FIDO AllianceのCredential Exchange Protocolがこれを解決することを目指していますが、完全な相互運用性はまだ標準化されていません。
- 共有アカウントやサービスアカウントは複雑さを生みます。 パスキーは個々のデバイスと生体認証に紐づくため、チーム共有アカウントやサービスアカウント、複数ユーザーが同一デバイスで認証するキオスク端末などでは利用が困難です。多くの組織は、共有アカウントにはパスワード認証を維持し、個人ユーザーアクセスにはパスキーを展開することで対応しています。
- パスワードなしのリカバリーには新たなワークフローが必要です。 ユーザーがすべてのデバイスを紛失し、バックアップ認証器も未登録の場合、アカウントリカバリーは単純なパスワードリセットより複雑になります。組織は、管理者によるリカバリーや帯域外の本人確認を含む、十分に検証されたリカバリープロセスを用意する必要があります。
- すべてのサービスがパスキーに対応しているわけではありません。 普及が進んでいるとはいえ、多くのレガシーアプリケーション、社内ツール、サードパーティSaaS製品はWebAuthnに未対応です。多くの組織は、主要なIDプロバイダーにはパスキーを導入し、移行期間中は未対応システムにパスワード認証を併用するハイブリッド認証体制を維持することになります。
これらの制限が、企業が実際にパスキー導入を進める際のアプローチに影響を与えていますが、データは多くの組織が複雑さを乗り越えて前進していることを示しています。
企業におけるパスワード vs パスキー導入
FIDO Alliance Enterprise Deployment Surveyによると、従業員500人以上の英国・米国企業400社のうち、87%が従業員サインイン向けにパスキー認証を導入済みまたは導入中です。多くの企業は段階的なアプローチを採用し、インフラ統合を優先してから全社展開に進んでいます。パスキー導入後、パスワード利用が26%減少しており、部分的な導入でもレガシーシステム対応を進めながら測定可能なセキュリティ向上が得られることが示されています。
自社のIDプラットフォームにはWebAuthn API対応とパスキーライフサイクル管理機能が必要です。多くの最新IDプロバイダーはWebAuthn経由でパスキー認証をサポートしています。統合はIDプロバイダー（IdP）層で行われ、ユーザーはパスキーで認証後、SAMLアサーションやOIDCトークンがフェデレーションアプリケーションに発行されます。SentinelOne Singularity Platformのようなセキュリティプラットフォームは、IdPと連携して認証イベント全体の可視性を維持し、パスキーベースのログインとエンドポイントアクティビティやユーザー行動分析を相関させる必要があります。
モバイルデバイス管理（MDM）や統合エンドポイント管理（UEM）ポリシーも、パスキー認証器やデバイスアテステーション対応のために更新が必要です。レガシーアプリケーションの互換性が主な導入障壁となるため、パスキー対応システムと移行期間中にゲートウェイソリューションやパスワード認証が必要なシステムをマッピングするため、アプリケーションの全体棚卸しが求められます。
ユーザーの利用率がセキュリティ成果を左右します。 Thales/FIDO Alliance State of Passkey Deployment Report（2024年）は、ユーザー教育が主要な導入課題であると指摘しています。特にパスキーの概念やデバイス間同期に関する混乱、既存習慣の変更への抵抗が記録されています。利用率向上に失敗した組織は、パスキー導入後も同じ脆弱性やコストを抱え続けるリスクがあります。
運用面の導入だけでなく、パスキー導入は企業のセキュリティ体制を規定するコンプライアンスフレームワークやゼロトラストアーキテクチャにも適合する必要があります。
コンプライアンスとゼロトラストの整合性
パスキーは、パスワードでは満たせないフィッシング耐性認証要件を満たします。NIST Special Publication 800-63Bは、AAL2でフィッシング耐性オプションの提供を明示的に要求し、AAL3ではそれを必須としています。パスワードのみを使用している場合、複雑さポリシーや多要素認証を追加しても、これらの要件を満たすことはできません。
連邦企業導入向けには、NISTの補足ガイダンスが、同期パスキーがAAL2要件を満たすことを確認しています。連邦認証鍵は、FISMA準拠を達成した同期基盤に保存される必要があります。PCI Security Standards Councilも、FAQ 1595およびFAQ 1596で、パスキーおよびFIDO2ベース認証の決済業界コンプライアンスについて明確に言及しています。
パスキーはコアな ゼロトラスト原則と整合します：
- 秘密鍵は認証器デバイスから決して離れず、認証情報の窃取やリプレイ攻撃を防止します。
- 認証は検証済みドメインに暗号的に紐づき、リライングパーティの検証によってフィッシングを阻止します。
- 各セッションでキャッシュされた認証情報の提示ではなく、デバイス所有の暗号学的証明が求められます。
これらの特性が、ゼロトラストの「信頼せず、常に検証する」という原則を支えます。
GDPR管轄、ヘルスケア、SOC 2コンプライアンス環境下の組織にとっても、パスキーは個人データ曝露の低減とNIST AAL2/AAL3準拠のフィッシング耐性認証により、コンプライアンス対応を支援します。これらの要件を満たすことが一方の側面であり、もう一方は移行中の認証インフラ全体の可視性を維持することです。
重要なポイント
パスワードは、攻撃者がフィッシング、クレデンシャルスタッフィング、データ侵害を通じて盗むことができる共有シークレットによって、システム全体の脆弱性を生み出します。パスキーは、秘密鍵がユーザーデバイスから決して離れない非対称 暗号技術によって、これらの攻撃を排除します。
侵害の88%が盗まれた認証情報に関与し、米英の従業員500人以上の企業の87%がパスキーを導入または導入中であることから、方向性は明確です。NISTとCISAは、パスワードでは複雑さポリシーに関係なく実現できないフィッシング耐性認証を明示的に要求しています。
よくある質問
パスキーは、フィッシング耐性のある認証資格情報であり、FIDO2/WebAuthn標準に基づいて構築されています。非対称暗号を使用して、各アカウントごとに一意の公開鍵と秘密鍵のペアを生成します。秘密鍵はデバイス上に保持され、サーバーに送信されることはありません。
パスワードは、デバイスとサーバーの両方に保存される共有シークレットであり、フィッシング、クレデンシャルスタッフィング、データベース侵害のリスクがあります。パスキーは、再利用可能なシークレットを送信するのではなく、暗号学的なチャレンジレスポンスによって本人確認を行います。
パスキーは暗号学的なドメインバインディングを使用しており、認証応答が登録された特定のオリジンドメインに対してのみ有効となります。ユーザーがフィッシングサイトにアクセスした場合、ブラウザのWebAuthn実装が認証応答を誤ったドメインに送信することをブロックします。
この保護はプロトコルレベルで動作し、ユーザーが不正なサイトを見分けることに依存しません。FIDOアライアンスは、同期型およびデバイスバインド型の両方のパスキーをフィッシング耐性があると正式に分類していますが、パスワードはSMS OTPやメールOTPなどと同様にフィッシングのリスクがあるカテゴリに残っています。
エンタープライズ向けパスキーの実装では、Apple、Google、Microsoft など同じアカウントエコシステムにサインインしているデバイス間で同期されたパスキーが複製されます。ユーザーがデバイスを紛失した場合でも、他の認証済みデバイスでパスキーに引き続きアクセスできます。組織は、すべてのデバイスへのアクセスを失った場合に備え、バックアップ認証器や管理者による復旧ワークフローを実装する必要があります。
NIST準拠のため、連邦導入環境では、NIST SP 800-63B Supplement on Syncable Authenticators で指定されているように、FISMA準拠の同期基盤に認証キーを保存する必要があります。
WebAuthnに対応していないレガシーアプリケーションは、パスキー認証を直接受け入れることができません。組織はパスキーをアイデンティティプロバイダー層で導入し、ユーザーはSAMLアサーションやOIDCトークンがフェデレーションアプリケーションに発行される前にパスキーで認証します。
これにより段階的な移行が可能となり、最新のアプリケーションはパスキー認証と直接統合し、レガシーアプリケーションはパスキーによるIdP認証後に標準のフェデレーショントークンを受け取ります。
NIST SP 800-63BはAAL2およびAAL3に対してフィッシング耐性のある認証を要求しており、パスワードは複雑さや定期変更ポリシーに関係なく要件を満たせません。CISAは重要インフラのデフォルト認証としてフィッシング耐性のある方法によるパスキーを推奨しています。
PCI DSS v4.xはFAQ 1595および1596で決済カード業界のコンプライアンスにおけるパスキーを取り上げています。連邦導入では、認証鍵の保存が準拠した同期ファブリックで行われることがFISMA要件となっています。
