パスキーとパスワードレス認証の未来
この記事は約 11 分で読めます
パスワードに代わる新しい認証方式として「パスキー」が急速に普及しつつあります。Google 、 Apple 、 Microsoft といった大手プラットフォームが相次いで対応を表明し、パスワードレスな未来が現実味を帯びてきました。 FIDO Alliance の 2024 年レポートによると、パスキー対応サービスの数は前年比で約 2.5 倍に増加しており、消費者の認知度も 50% を超えました。 Google は 2024 年 10 月時点でパスキーによるログインがパスワードによるログインを上回ったと発表しています。2025 年に入り、 Amazon 、 PayPal 、 GitHub をはじめとする主要サービスがパスキー対応を拡充し、移行はさらに加速しています。しかし、すべてのサービスが一夜にしてパスキーへ移行するわけではありません。本記事では、パスキーの技術的な仕組みから対応状況、そして移行期間中にパスつく.com で安全を確保する方法までを包括的に解説します。
FIDO2 と WebAuthn の仕組み
パスキーの基盤となる技術が FIDO2 (Fast IDentity Online 2) と WebAuthn (Web Authentication) です。 FIDO2 は FIDO Alliance が策定した認証規格であり、 WebAuthn はそのウェブブラウザ向け API 仕様として W3C が標準化しました。
従来のパスワード認証では、ユーザーが入力した文字列をサーバーに送信し、サーバー側で保存されたハッシュ値と照合します。この方式では、サーバーが侵害された場合にパスワード情報が漏洩するリスクがあります。
公開鍵暗号方式による認証の原理
FIDO2/WebAuthn が従来のパスワード認証と根本的に異なるのは、公開鍵暗号方式を採用している点です。公開鍵暗号では、数学的に関連する 2 つの鍵 (秘密鍵と公開鍵) のペアを使用します。秘密鍵で署名されたデータは対応する公開鍵でのみ検証でき、公開鍵から秘密鍵を逆算することは計算量的に不可能です。この性質は楕円曲線暗号 (ECDSA) や RSA といったアルゴリズムの数学的困難性に基づいています。
具体的な認証フローは次のとおりです。まず登録時に、ユーザーのデバイス上で秘密鍵と公開鍵のペアが生成され、公開鍵のみがサーバーに送信されます。ログイン時には、サーバーがランダムなチャレンジ (検証用データ) を送信し、デバイス側が秘密鍵でチャレンジにデジタル署名を付与して返します。サーバーは公開鍵で署名を検証するだけなので、秘密鍵がネットワーク上を流れることはありません。サーバーに保存されるのは公開鍵だけであり、仮にサーバーが侵害されても攻撃者が得られるのは公開鍵のみで、認証を突破することはできません。これはパスワードのハッシュ値が漏洩した場合にオフライン攻撃で元のパスワードを復元できるリスクとは対照的です。
オリジン検証によるフィッシング耐性の原理
FIDO2/WebAuthn がフィッシング攻撃に対して強い耐性を持つ理由は、オリジン検証の仕組みにあります。パスキーの登録時に、ブラウザはサイトのオリジン (プロトコル + ドメイン + ポート) を秘密鍵に紐づけて保存します。ログイン時にブラウザは、現在アクセスしているサイトのオリジンと秘密鍵に紐づけられたオリジンを自動的に照合し、一致しない場合は認証処理自体を実行しません。この検証はブラウザの内部で行われるため、ユーザーが URL を目視で確認する必要がなく、人間の判断ミスに依存しない点が決定的な強みです。たとえば「 examp1e.com 」(l を 1 に置換) のような巧妙な偽ドメインでも、ブラウザレベルで確実にブロックされます。フィッシング対策の全体像についてはフィッシング詐欺の見分け方と対策もあわせてご覧ください。
パスキーとは何か
パスキー (Passkey) は、 FIDO2/WebAuthn の技術を基盤としつつ、ユーザー体験を大幅に改善した認証方式です。従来の FIDO2 セキュリティキーは物理的なハードウェアトークンが必要でしたが、パスキーではスマートフォンや PC に内蔵された生体認証 (指紋、顔認証) や画面ロック (PIN) を使って認証を完結できます。
同期パスキーとデバイス固定パスキー
パスキーには 2 つの種類があります。同期パスキー (Synced Passkey) は、Apple の iCloud キーチェーンや Google パスワードマネージャーを通じて複数のデバイス間で同期されます。 iPhone で作成したパスキーを Mac でも利用できるため、デバイスの紛失や買い替え時にも認証情報を引き継げます。
デバイス固定パスキー (Device-bound Passkey) は、特定のハードウェアに紐づけられ、外部にエクスポートできません。 YubiKey などのセキュリティキーがこの方式に該当します。同期パスキーよりもセキュリティは高いものの、デバイスの紛失時にはリカバリー手段が必要です。デバイス固定パスキーの導入を検討する場合は、FIDO2 対応セキュリティキーの関連製品 (Amazon)も参考になります。
注意すべき点として、同期パスキーはクラウド経由で秘密鍵が同期されるため、クラウドアカウント自体が侵害された場合にすべてのパスキーが漏洩するリスクがあります。Apple や Google はエンドツーエンド暗号化でこのリスクを軽減していますが、クラウドアカウントの保護 (強力なパスワード + 二段階認証) が前提条件となる点は見落とされがちです。
パスキー vs パスワード + 2FA vs セキュリティキー
認証方式の選択肢を正しく理解するために、主要な 3 つの方式を比較します。それぞれの特性を把握した上で、サービスの重要度に応じた使い分けが重要です。
- パスキー (同期): フィッシング耐性が高く、生体認証で手軽にログインできる。クラウド同期によりデバイス間の移行も容易。ただしクラウドアカウントのセキュリティに依存する。対応サービスがまだ限定的
- パスワード + 2FA (TOTP): 最も広く対応されている方式。パスワードの強度と TOTP アプリの組み合わせで一定の安全性を確保できるが、フィッシングサイトにパスワードと TOTP コードの両方を入力してしまうリスクがある。TOTP コードの有効期間 (通常 30 秒) 内であれば攻撃者がリアルタイムで中継する攻撃 (リアルタイムフィッシング) が成立する
- セキュリティキー (デバイス固定パスキー): フィッシング耐性が最も高く、秘密鍵がデバイス外に出ない。企業の特権アカウントや金融サービスに最適だが、物理デバイスの購入コスト (1 本あたり 5,000 〜 10,000 円程度) と紛失時のリカバリー手段の確保が必要
実務的な推奨としては、対応サービスではパスキーを最優先で設定し、未対応サービスではパスワード + 2FA を維持する「ハイブリッド運用」が現時点で最もバランスの良い戦略です。金融機関や管理者アカウントなど特に重要なサービスには、セキュリティキーの追加を検討してください。生体認証の利便性とリスクについては生体認証のリスクと安全な活用法で詳しく解説しています。
パスキーに対応するサービス
2024 年以降、パスキー対応サービスは急速に拡大しています。FIDO Alliance の調査によると、 2024 年末時点でパスキーに対応するウェブサイトとアプリは全世界で 150 億以上のアカウントをカバーしています。主要なサービスの対応状況は以下のとおりです。
- Google: Gmail 、 Google Workspace を含む全サービスでパスキーに対応
- Apple: Apple ID のサインインにパスキーを利用可能
- Microsoft: Microsoft アカウントおよび Windows Hello と連携
- Yahoo! JAPAN: 国内サービスとして早期にパスキーを導入
- GitHub: 開発者向けにパスキー認証を提供
- Amazon: ショッピングアカウントでパスキーに対応
- PayPal: 決済サービスとしてパスキーをサポート
ただし、対応サービスは全体のごく一部にすぎません。多くのウェブサービス、特に国内の中小規模サービスでは、依然としてパスワード認証が主流です。パスキー対応を表明していても、実装が不完全なケースもあります。たとえば、パスキーでのログインは可能でもアカウント復旧フローがパスワードに依存していたり、特定のブラウザでのみ動作したりするサービスも少なくありません。
よくある誤解: 「パスキーを設定すればパスワードは不要」
パスキーに関して最も多い誤解は、「パスキーを設定すればパスワードを削除しても安全」というものです。実際には、大半のサービスがパスキー設定後もパスワードによるフォールバック認証を残しています。つまり、攻撃者はパスキーを迂回してパスワードでログインを試みることが可能です。パスキーを設定したからといってパスワードの強度を下げてよい理由にはなりません。むしろ、パスキー設定後こそフォールバック用パスワードをパスつく.com で 20 文字以上のランダムな文字列に更新し、攻撃者がパスワード経由で侵入する経路を塞ぐことが重要です。
また、「パスキーは生体情報をサーバーに送信する」という誤解もあります。実際には、生体認証はデバイス上のセキュアエンクレーブ (Secure Enclave や TPM) 内でローカルに処理され、生体情報そのものがネットワークを通じて送信されることはありません。生体認証はあくまで「デバイス上の秘密鍵へのアクセスを許可するためのローカル認証」であり、サーバーとの認証は公開鍵基盤 (PKI) に基づくデジタル署名で行われます。
パスワードとの共存期間
パスキーが完全にパスワードを置き換えるまでには、相当な時間がかかると予想されます。その理由はいくつかあります。
- すべてのサービスがパスキーに対応するには技術的・コスト的なハードルがある
- 古いデバイスやブラウザではパスキーを利用できない場合がある
- パスキー対応サービスでも、フォールバックとしてパスワード認証を残しているケースが多い
- 企業の社内システムや業務アプリケーションの移行には時間を要する
この共存期間中は、パスキーに対応したサービスではパスキーを優先的に設定しつつ、未対応のサービスでは引き続き強力なパスワードで防御する必要があります。中途半端な対応が最も危険です。パスキーを設定したサービスでも、パスワードによるフォールバック認証が有効な場合は、そのパスワード自体の強度を維持しなければなりません。パスキーの仕組みを深く理解するには、公開鍵暗号と認証プロトコルの関連書籍 (Amazon)も参考になります。
パスキー移行チェックリスト
パスキーへの移行を段階的に進めるための実践的なチェックリストです。優先度の高いサービスから順に対応していくことを推奨します。
- メールアカウント (Google 、 Microsoft 、 Yahoo! JAPAN) でパスキーを設定する。メールはパスワードリセットの起点となるため最優先で保護する
- 金融サービス (銀行、証券、決済) でパスキーまたはセキュリティキーを設定する
- SNS アカウント (GitHub 、 X 、 Facebook) でパスキーを設定する
- パスキー設定済みサービスのフォールバック用パスワードをパスつく.com で 20 文字以上に更新する
- パスキー未対応サービスのパスワードをパスつく.com で 16 文字以上のランダムな文字列に更新する
- すべてのサービスで二段階認証を併用する
- パスワードマネージャーにすべての認証情報を集約し、マスターパスワードを最も強力に設定する
- 3 か月ごとにパスキー対応状況を確認し、新たに対応したサービスがあれば設定する
パスつく.com で強力なパスワードを維持する
パスワードレスの未来が近づいているとはいえ、現時点ではパスワードが認証の主軸であることに変わりありません。パスキー未対応のサービスはもちろん、パスキー対応サービスのフォールバック用パスワードも、十分な強度が求められます。
パスつく.com を活用すれば、移行期間中のパスワード管理を効率化できます。サービスごとに異なるランダムなパスワードを一括生成し、パスワードマネージャーに保存しておけば、パスキーへの移行が完了するまでの間も安全を確保できます。
パスキーの普及は歓迎すべき進歩ですが、完全な移行までの道のりは長く、その間のセキュリティを支えるのは依然として強力なパスワードです。パスつく.com の強度メーターで 80 ビット以上のエントロピーを確認しながら、すべてのアカウントを堅牢に保護していきましょう。
今すぐできること
- Google アカウントの「セキュリティ」設定からパスキーを登録する (スマートフォンの生体認証で完了)
- Apple ID 、 Microsoft アカウントなど、パスキー対応済みの主要サービスで順次パスキーを設定する
- パスキー設定済みサービスのフォールバック用パスワードをパスつく.com で 20 文字以上に更新する
- パスキー未対応サービスのパスワードをパスつく.com で 16 文字以上のランダムな文字列に更新し、二段階認証を併用する
- 3 か月後にパスキー対応状況を再確認し、新たに対応したサービスがあれば設定する
よくある質問
- パスキーとパスワードの違いは何ですか？
- パスワードはユーザーが記憶する文字列ですが、パスキーは公開鍵暗号方式に基づく認証情報で、秘密鍵はデバイス内に安全に保管されます。フィッシングサイトに入力してしまうリスクがなく、漏洩の心配もありません。
- パスキーに対応していないサービスではどうすればいいですか？
- パスキー非対応のサービスでは、パスワードマネージャーで生成した長いランダムパスワードと二要素認証を組み合わせてください。対応サービスが増えるまでの過渡期は、この併用が最も現実的な対策です。
- パスキーを設定したデバイスを紛失したらどうなりますか？
- Apple や Google のクラウド同期を利用していれば、新しいデバイスにサインインするだけでパスキーが復元されます。同期を使っていない場合に備え、サービス側のアカウント回復手段 (回復コードや別の認証方法) を事前に設定しておくことが重要です。
この記事は役に立ちましたか？