パスワードとパスキーとは
次のシナリオを考えてみてください。午前2時14分、SOCアナリストが認証ログを確認すると、過去1時間に数百回のログイン失敗が記録されています。午前2時31分、過去の侵害で盗まれた認証情報を使ったログインが1件成功し、セキュリティスタックはこれを検知できませんでした。
これがパスワードとパスキーの本質的な違いです。パスワードは共有シークレットモデルで動作し、同じ認証情報がデバイスとサーバーの両方に存在します。攻撃者がサーバーを侵害したり、認証情報をフィッシングで入手した場合、認証に必要なすべてを手に入れることになります。パスキーは非対称暗号技術によりこの脆弱性を排除します。秘密鍵はデバイスから決して離れず、サーバーに保存される公開鍵は攻撃者にとって暗号的に無意味です。
22,052件のセキュリティインシデントを分析した2025年版DBIRによると、侵害の88%が盗まれた認証情報に関与しています。パスワードは複雑さの要件や定期変更、ユーザー教育に関係なく、システム全体の脆弱性を生み出します。
パスキーはFIDO2プロトコルアーキテクチャを、ブラウザやプラットフォームの認証情報管理を担うW3C Web Authentication（WebAuthn）仕様と、アプリケーションと認証器間の通信を担うFIDO Alliance CTAP2（Client to Authenticator Protocol）の2つの標準で実装します。これらのプロトコルにより、パスワード送信をドメインに紐づいた暗号チャレンジレスポンス認証に置き換えます。
パスキーを登録すると、認証器はそのアカウント専用の公開鍵・秘密鍵ペアを生成します。秘密鍵はデバイスのハードウェアセキュリティモジュールやセキュアエンクレーブに安全に保管され、ネットワークを通じて送信されることはありません。サーバーには公開鍵のみが登録されます。認証時、サーバーは暗号チャレンジを送信し、デバイスが秘密鍵で署名することで、鍵自体を公開せずに所有を証明します。
これらのアーキテクチャの違いが、どの攻撃が成功し、どの攻撃が失敗するかを直接左右します。
.jpg)
パスワードとパスキーのサイバーセキュリティへの関係
パスキーは、侵害の大半を引き起こす認証の弱点に対応します。 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サポートの大きな定常コストを排除しています。
これらの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要件となっています。
