はじめに

「ID・パスワード認証」って、もう古い？最近は新しい認証方式であるFIDO2が話題です。この記事では、なぜ今パスワードから脱却すべきなのか、そして新しい認証方式のメリット・課題について、より詳しく・分かりやすく解説します。

想定読者

• サービス開発者、運営者、セキュリティに興味がある非専門領域の方

※この記事は実装方法の紹介ではありません

用語解説

• FIDO（Fast IDentity Online）：パスワードレス認証を実現するための国際標準規格。公開鍵暗号方式を使い、秘密鍵は端末内に安全に保存される。
• passkey：FIDO2をベースにした、Apple/Google/Microsoftなどが推進する新しい認証情報。ユーザーはパスワードを覚える必要がなく、端末の生体認証やPINでサインインできる。
• フィッシング：Fishingじゃないよ、Phishingだよ。サイトを模倣してユーザーから情報を抜き取る詐欺手法のこと。

認証の基本

本記事を読む上で必要になる知識をまとめています。既知のものはすっ飛ばしてください！

認証要素の種類

認証にはいろんな「要素」があります。ざっくり分けると、

1. 記憶要素（パスワードなど）

   • 本人とサービスだけが知る秘密。メールアドレスは含まない。
   • 弱点：盗難・推測・流出リスク、不十分な保管。
2. 所有物要素

   • 例：スマホ、物理トークン。スマホはロックされている場合のみ有効。
3. 生体要素

   • 形態学的（指紋・顔・声・網膜）と生物学的（DNAなど）に分かれる。
   • 生体認証は完全一致しない前提で設計されている。
   • 最大の欠点：複製や不正を許す可能性があるにも関わらず、それを簡単に修復する手段がほとんどない。新しい虹彩や指紋を簡単に発行することはできない。
   • リスクを大幅に低減する方法は、大規模データベースに保持するのではなく、デバイスごとにローカル保存すること。
4. 振る舞い要素

   • 例：ピクチャパスワード、筆跡、特定の動作。あまり使われていない。
5. 位置要素

   • 例：IP、GPS、ネットワーク経路、ping遅延。
   • 単独では弱いが、他要素と組み合わせると有効。
6. 時刻要素

   • 例：普段と異なる時間帯のアクセスを検知。
   • 位置と組み合わせるとリスク検知が可能。

2FA(2要素認証)やMFA（多要素認証）とは？

上記要素を2つ以上組み合わせて、セキュリティを高める仕組み。

passkeyは、生体要素(指紋や顔など)と所有物要素(認証器)を組み合わせたもの。

チャレンジレスポンス

チャレンジレスポンス認証とは、相手が本当に本人かを確認するための一つの方法です。古典的な例では、「山」と問いかけ（チャレンジ）、相手が「川」と正しく応答（レスポンス）できれば本人だと判断する「合言葉」のようなものです。

Passkeyにおけるチャレンジレスポンスでは、このやり取りをより安全かつ高度に行います。

サーバーからの「今日の合言葉の問い（チャレンジ）」に対して、あなたは自分だけが持っている「秘密のハンコ（秘密鍵）」で「正しい答えの印（署名）」を押して返します。サーバーは、あなたが事前に登録しておいた「ハンコの印影（公開鍵）」と照合することで、あなたを認証します。この「秘密のハンコ」はあなたのデバイスから決して外に出ることがなく、また「今日の合言葉の問い」は毎回変わるので、非常に安全な仕組みです。

認証ピラミッドと強度

認証強度が強い順に並んだピラミッドを示す。

パスワード < SMS OTP < OTP < プッシュ通知 < パスキー < PKI（公開鍵インフラ）の順で強い。

• パスワード：最も弱い。流出・リスト型攻撃の温床。
• SMS OTP（ワンタイムパスワード）：中間レベル。SIMスワップ攻撃に注意。
• OTP：アプリやトークンで生成。フィッシングには弱い。
• プッシュ通知：スマホで承認。UX良いが、端末紛失リスク。
• パスキー：フィッシング耐性が高く、UXも優秀。
• PKI：デジタル証明書で身元確認まで可能。最強クラス。

パスキー以上はフィッシングに強い！

『passkey』認証（およびパスキー）

ここからは、今後認証の主流となるであろう『passkey（パスキー）』について、その仕組みからメリット、そして考慮すべき点まで詳しく見ていきます。

passkeyとは?

passkey（パスキー）とは、パスワードレス認証を実現するための国際標準規格である「FIDO2」をベースに、Apple、Google、Microsoftといった主要なプラットフォーム企業が共同で推進している新しい認証情報のことです。従来のパスワードのようにユーザーが文字列を記憶・入力する必要がなく、代わりに自身が所有するデバイス（スマートフォンやPCなど）の生体認証（指紋や顔）やPINコードを使って、簡単かつ安全にサービスへサインインできるようになります。 パスキーを利用する上で重要な役割を担うのが「認証器」です。認証器には大きく分けて以下の2種類があります。

1. プラットフォーム認証器: PCやスマートフォンなど、ユーザーが日常的に利用しているデバイス自体が認証器として機能します。デバイスに搭載されたTPM (Trusted Platform Module) やセキュアエレメントといった安全な領域で認証情報が管理されます。
2. ローミング認証器: USB接続のセキュリティキーや、NFC、BluetoothでPC・スマートフォンに接続して使用する外部の物理的なセキュリティキーを指します。持ち運び可能で、複数のデバイスで利用できるのが特徴です。

これらの認証器が、安全な認証キー（公開鍵と秘密鍵のペア）の生成、保存、そして認証時の署名といった重要な処理を実行します。

認証フロー

パスキーを使った認証は、大きく「サインアップ（パスキーの登録）」と「サインイン（本人確認）」の2つのプロセスに分かれます。

サインアップ（パスキーの登録）

1. 登録開始: ユーザーがWebブラウザやアプリ（クライアント）を通じて、サービスの新規登録（サインアップ）操作を開始します。
2. チャレンジ送信: サービスを提供するサーバーは、「チャレンジ」と呼ばれる一度しか使えないランダムなデータを生成し、クライアントに送信します。これは、リプレイ攻撃（過去の通信データを再利用する攻撃）を防ぐための重要なステップです。
3. パスキー作成指示: クライアントは、PCやスマートフォン、セキュリティキーといった認証器に対し、新しいパスキーの作成を指示します。
4. ユーザー検証: 認証器はユーザーに本人確認を要求します。具体的には、指紋認証、顔認証、あるいはデバイスのPINコード入力などです。この「ユーザー検証」プロセスにより、権限のない第三者が勝手にパスキーを作成することを防ぎます。
5. キーペア生成: ユーザー検証が成功すると、認証器は新しいパスキー（公開鍵と秘密鍵のペア）を生成します。このうち、秘密鍵は認証器内部のセキュアな領域に厳重に保管され、決して外部に取り出されることはありません。これがパスキーのセキュリティの根幹です。
6. デジタル署名: 認証器は、生成した秘密鍵を使って、サーバーから受け取ったチャレンジに対してデジタル署名を行います。
7. 公開鍵と署名の送信: 認証器は、生成した公開鍵と、チャレンジへの署名を（多くの場合、認証器自体の情報と共に）サーバーへ送り返します。
8. 公開鍵の保存: サーバーは、受け取った公開鍵をユーザーのアカウント情報と紐づけて保存します。この公開鍵は、以降のサインイン時に、ユーザーから送られてくる署名を検証し、本人であることを確認するために使用されます。

サインイン（本人確認）

1. サインイン要求: ユーザーがクライアントを通じてサービスへのサインインを要求します。
2. チャレンジ送信: サーバーは、サインアップ時と同様に、新たな「チャレンジ」を生成し、クライアントに送信します。
3. 署名要求: クライアントは認証器に対し、この新しい「チャレンジ」への署名を要求します。
4. ユーザー検証: サインアップ時と同様に、ユーザーは認証器による本人確認（指紋認証、顔認証、PIN入力など）を行います。
5. デジタル署名: ユーザー検証が成功すると、認証器はサインアップ時に保存しておいた秘密鍵を使って、サーバーから受け取った「チャレンジ」に対してデジタル署名を行います。
6. 署名等の送信: クライアントは、このデジタル署名と、どのパスキー（公開鍵）に対応する署名であるかを示す情報（クレデンシャルIDなど）をサーバーに送り返します。
7. 署名検証: サーバーは、あらかじめ保存しておいたユーザーの公開鍵を使い、受け取った署名が正当なものであるかを検証します。
8. 認証成功: 署名が正しければ認証成功と判断され、ユーザーはサービスにサインインできます。

passkeyの主なメリット

パスキーの導入は、ユーザーとサービス提供者の双方に多くのメリットをもたらします。

• 驚くほど簡単なユーザー体験:

  従来のパスワード入力や複雑な文字列の記憶といった煩わしさから解放されます。多くの場合、デバイスの生体認証（指紋や顔）やPINコードを入力するだけで、まるでデバイスのロックを解除するような直感的かつ素早い操作でサインインやサインアップが完了します。これは、ユーザーにとって非常に大きな負担軽減となります。

• フィッシングに対する極めて高い耐性:

  パスキー最大の特長の一つが、フィッシング詐欺に対する強固な保護です。認証プロセスでは、ユーザーが正規のサービスサイトと通信していることを認証器が確認（オリジンバインディング）した上で、そのサイト専用の秘密鍵で署名を行います。たとえユーザーが悪意のある偽サイトに誘導されたとしても、その偽サイトは正規のサイトとはドメインが異なるため、パスキーは機能しません。結果として、認証情報が盗まれるリスクを劇的に低減します。

• チャレンジレスポンス方式による確かな安全性:

  認証の都度、サーバーから送られる「チャレンジ」（一度きりのランダムなデータ）に対して秘密鍵で署名する方式のため、仮に通信内容が傍受されたとしても、その署名は再利用できません。これにより、中間者攻撃などのリスクも効果的に低減されます。

• 統一された認証体験への期待:

  Apple、Google、Microsoftといったプラットフォームベンダーがパスキーを標準技術として推進しているため、将来的には様々なサービスで一貫性のある、よりシームレスな認証体験が提供されることが期待されます。「このサービスではこのパスワード、あのサービスではあのパスワードで、パスワードのルールもいちいち違う…」といったユーザーの混乱から解放され、より直感的にサービスを利用できるようになるでしょう。

• パスワード管理の煩雑さからの解放:

  「大文字小文字数字記号を組み合わせた8文字以上」といった複雑なパスワードポリシーや、定期的なパスワード変更の強要、サービスごとに異なるパスワードを記憶・管理するといった手間が一切不要になります。パスワードマネージャーを利用していても、一部サイトの特殊な入力フォーム（特定の記号が使えない、長すぎるパスワードが登録できないなど）に対応できないケースがありましたが、パスキーではそうした問題も解消されます。

技術的背景

パスキーの高いセキュリティと利便性は、公開鍵暗号方式を巧みに利用した技術に基づいています。

• デバイス固有の秘密鍵とサーバーへの公開鍵登録:

  パスキーを登録する際、ユーザーのデバイス（スマートフォンやセキュリティキーなど）内で秘密鍵と公開鍵のペアが生成されます。このうち、秘密鍵はデバイス内の安全な領域（セキュアエレメントやTPMなど）に厳重に保管され、決して外部に出ることはありません。 一方、公開鍵のみがサービス提供者のサーバーに登録されます。

• ローカルでのユーザー検証と署名:

  ユーザーがサインインする際には、まずデバイス上で生体認証（指紋、顔など）やPINコードによる本人確認（ユーザー検証）が行われます。これが成功すると、デバイスに保管されている秘密鍵を使って、サーバーから送られてきたチャレンジ（ランダムなデータ）に対してデジタル署名が生成されます。

• サーバーは署名を検証するだけ（パスワードレス）:

  サーバーは、登録されている公開鍵を使って、送られてきた署名が正当なものであるかを検証します。署名が正しければ認証成功となります。重要なのは、サーバー側には秘密鍵やパスワードそのものが保存されていないため、万が一サーバーが不正アクセスを受けても、ユーザーの認証情報が直接流出するリスクは極めて低いという点です。

• クロスデバイス利用と同期の仕組み:

  Apple、Google、Microsoftなどの大手プラットフォームプロバイダーは、自身のエコシステム内でパスキーを同期する仕組みを提供しています（例: iCloudキーチェーン、Googleパスワードマネージャー経由など）。これにより、例えばiPhoneで作成したパスキーを同じアカウントで紐づけられたiPadやMacでも利用できるようになり、利便性が大きく向上します。ただし、この同期メカニズム自体のセキュリティや、異なるエコシステム間での連携は今後の進展が期待される部分です。

主な課題と解決策

課題

1. 認証器（デバイス）の紛失・故障・機種変更時の対応:

   日常的に使用するスマートフォンを紛失したり、故障してしまったり、あるいは新しい機種に変更した場合、そのデバイスに保存されていたパスキーにアクセスできなくなる可能性があります。また、指紋センサーが反応しなくなったり、顔認証が一時的に利用できなくなったりといった生体情報の変化も考慮に入れる必要があります。このような事態に備えて、ユーザーがアカウントに再びアクセスできるための堅牢かつ使いやすいリカバリー方法を事前に設計しておくことが不可欠です。

2. リカバリー方法のセキュリティレベルのジレンマ:

   パスキー自体は非常に強力な認証手段ですが、アカウントリカバリーのために用意された代替手段（例えば、メールアドレスへのリカバリーコード送信、SMS認証、従来のパスワード認証など）のセキュリティレベルが低い場合、システム全体の認証強度はその最も弱いリカバリー手段のレベルに引きずられてしまうという大きなジレンマがあります。せっかくパスキーでセキュリティを高めても、リカバリープロセスが攻撃の脆弱性となってしまっては元も子もありません。

3. ユーザーの理解と受容性:

   パスキーによる認証は、従来のID・パスワード入力に慣れ親しんだユーザーにとっては「あまりにも簡単すぎる」と感じられ、「本当にこれで安全なの？」という漠然とした不安を抱かせる可能性があります。特に、技術的な背景に詳しくない方にとっては、目に見えないところで高度な暗号技術が機能していることを直感的に理解してもらうのは容易ではありません。新しい技術に対する心理的なハードルを下げ、信頼感を醸成するための啓蒙活動も重要になります。

解決策

• 段階的で柔軟なリカバリーオプションの提供:

  Googleなどのプラットフォームでは、ユーザー自身がリカバリー方法のセキュリティレベルを選択できるような設計を取り入れ始めています。例えば、セキュリティ意識の高いユーザー向けには、より強固なリカバリー方法（別の信頼済みデバイスでの承認や、事前に安全な場所に保管したリカバリーキーの使用など）を選択できるようにし、利便性を優先するユーザーには従来のメールやSMSによるリカバリーもオプションとして残す、といった多段階の選択肢を用意することが考えられます。

• リカバリー時の追加認証要素の組み合わせ:

  単一のリカバリー手段に依存するのではなく、複数の要素を組み合わせることでセキュリティ強度を維持する工夫も有効です。例えば、メールでのリカバリーコード送信に加え、過去の利用履歴（信頼済みデバイスからのアクセスか、普段利用するネットワーク環境かなど）をリスク評価の材料として加味することも考えられます。

• 全体の強度を極力下げないリカバリー方法の推奨:

  サービス提供者側は、デフォルトのリカバリー方法として、パスキーのセキュリティ強度を大きく損なわないような手法（例：別のパスキーが登録されたデバイスからの承認、事前に発行・保管しておいた復旧用コードなど）を推奨し、ユーザーをそちらへ誘導するUI/UXデザインを心がけることが望ましいです。

• コンテキストに応じた適応的な認証要求 (Risk-Based Authentication / Adaptive Authentication):

  常に最高レベルの認証をユーザーに強いるのではなく、ユーザーの行動や状況（コンテキスト）に応じて認証のレベルを動的に変更するアプローチも有効です。例えば、普段と異なる国からのアクセスや、高額な取引の実行、重要な個人情報の変更といったリスクの高い操作時のみ、追加の認証（例えば、パスキーによる再認証や、別の認証要素の確認）を要求することで、日常的な利便性と高度なセキュリティのバランスを取ることができます。

• ユーザーへの丁寧な説明と啓蒙活動:

  なぜパスキーが安全なのか、どのような仕組みでユーザーの情報が守られているのかを、非専門家にも分かりやすい言葉や図解を用いて説明するコンテンツ（FAQ、チュートリアル、ブログ記事など）を用意し、ユーザーの不安を取り除き、信頼感を育む努力が不可欠です。新しい認証方法への移行をスムーズに進めるためには、メリットを訴求するだけでなく、その仕組みの透明性を示すことも重要です。

まとめ

長年にわたり、私たちのデジタルライフにおける本人確認の主流であったID・パスワード認証は、フィッシング詐欺、リスト型攻撃、パスワードの使い回しといった数々の脅威に常にさらされ、その限界が繰り返し指摘されてきました。複雑なパスワードの記憶や定期的な変更といったユーザー側の負担も、決して小さくはありませんでした。

しかし今、FIDO2やそれを基盤とするpasskey（パスキー）といった新しい認証技術の登場により、私たちはついにその「パスワードの呪縛」から解放される具体的な道筋を手に入れました。パスキーは、ユーザーが日常的に持ち歩くスマートフォンなどの「所有物要素」と、指紋や顔認証といった「生体要素」を組み合わせることで、フィッシング攻撃に対する極めて高い耐性を持ち、かつユーザーにとって非常に簡単で直感的な認証体験を実現します。サーバー側でパスワード情報を保持する必要がなくなるため、大規模な情報流出事故のリスクも大幅に低減できるのです。

もちろん、認証器となるデバイスの紛失や故障に備えたリカバリープランの設計や、新しい技術に対するユーザーの理解と受容性の向上といった課題も残されています。しかし、これらの課題に対する解決策やベストプラクティスも活発に議論・開発されており、Apple、Google、Microsoftといった主要なプラットフォームベンダーがパスキーの普及を強力に推進している現状からも、その未来は非常に明るいと言えるでしょう。

サービス開発者や運営者の皆様にとって、ユーザーの大切な情報を守り抜き、同時に快適でストレスのない利用体験を提供することは、サービス価値を高める上で極めて重要な責務です。パスキーは、この「セキュリティ」と「UX（ユーザーエクスペリエンス）」という、時に相反しがちな二つの目標を、かつてない高いレベルで両立させる可能性を秘めています。

この記事が、あなたのサービスにおける認証方式を見直し、より安全で快適な次世代の認証へと一歩を踏み出すための、有益な情報となれば幸いです。