パスワードにさよなら、パスキーにこんにちは: 認証の未来

パスキーの紹介

パスワードベースの認証は、長年にわたりデフォルトのモードでした。しかし、登録するすべての Web サイトのパスワードを覚えておきたいと思う人はいるでしょうか。ほとんどの人は、覚えやすいパスワードを多くの場所で使用しています。パスワード マネージャーを使用すると、資格情報の自動入力が容易になりますが、パスワードベースの認証システムに存在するセキュリティ上の懸念を設計から克服することはできません。そこで登場するのが Passkeys です。Passkeys はより安全で使いやすく、認証分野における新しいビジョンを備えたパスワードレス認証を提供し、将来有望です。

他のものと同様、パスキーにも利点と課題があります。この記事では、この認証モードの仕組み、安全性などについて説明しながら、それらについて説明します。

パスキーはどのように機能しますか?

パスキーは、単一の文字列ベースのパスワードに頼るのではなく、公開キー暗号化を利用して認証フローを生成します。ユーザーのデバイスは公開キーと秘密キーのペアを生成し、公開キーをサーバーに送信します。サーバーはそれを保存し、後でそのキーを使用してユーザーを認証します。秘密キーはユーザーのデバイスに保存されます。

登録の流れ

• ユーザーのデバイスは、Web サービスにバインドされた公開/秘密キーのペアを生成します。
• 公開鍵は Web サービスに送信され、秘密鍵はユーザーのデバイスに保存されます。
• Web サービスは、ユーザーに対する公開キーをデータベースに保存します。

認証フロー

• Web サービスはチャレンジ nonce をクライアントに送信します。
• ユーザーは、生体認証、PIN などの任意の方法を使用してローカルで自分自身を認証し、秘密鍵にアクセスします。
• ユーザー デバイスは、特定の Web サービスの秘密キーを使用してチャレンジに署名します。
• Web サービスは署名されたチャレンジを受信し、公開キーを使用してそれを検証します。これにより、クライアント デバイスが実際に秘密キーにアクセスできることが保証されます。
• 検証が成功すると、Web サービスはユーザーを認証します。

注意すべき点

• 公開鍵/秘密鍵のペアは、サービス/Web サイトごとに固有です。
• 公開鍵は登録時に 1 回だけネットワーク経由で Web サービスに送信されます。
• 秘密鍵は常にユーザーのデバイス上に保存され、ネットワーク経由で送信されることはありません。(パスワード マネージャーを使用してパスキーを同期する場合は例外です)
• ユーザー デバイスによって生成された署名付きペイロードはネットワーク経由で送信され、セッション固有であり、ユーザーが認証するたびに変更されます。

それらはどれほど安全で、パスワードよりも優れた代替手段となるのでしょうか?

通常、セキュリティが強化されると使いやすさは低下しますが、パスキーの場合はそうではありません。登録フェーズが完了すると、パスキーは使いやすくなります。パスワードを覚えておく負担はなく、認証は迅速、簡単、かつ安全です。

パスキーは攻撃対象領域を減らし、パスワードに対する一般的な脅威の一部を排除します。パスワードは通常、データベースに暗号化された形式で保存されます。プレーンテキストのパスワードを使用して Web サービスにログインすると、同じ暗号化テキストが生成され、すでに持っているテキストと比較されます。これがユーザーの認証方法です。これで、最も一般的な 2 つの脅威が残ります。

• データベース侵害
• フィッシング攻撃

データベースの侵害はよくあることで、サービスのデータが盗まれると、ダーク ウェブで売られることがよくあります。データにアクセスできる悪意のある人物は、オフラインで暗号化を破ろうとしますが、今日のコンピューター処理能力では、暗号化によっては数週間から数か月かかる可能性があります。パスキーでは、保存するパスワードがないため、この脅威が排除されます。漏洩が発生した場合、公開キーのみが露出し、悪意のある人物にとってはあまり役に立ちません。

フィッシング攻撃では、ターゲット Web サイトのクローンが作成され、ユーザーは本物のサイトと勘違いして認証情報を入力させられます。ただし、盗む認証情報がないため、Passkeys ではこれも機能しません。中間者攻撃と組み合わせた高度なフィッシング攻撃は依然として実行可能ですが、攻撃対象領域は大幅に縮小されます。

パスキーの種類

• 単一デバイスまたはデバイスバウンド
  • 秘密鍵はデバイス外に漏れることはありません。
  • 認証は、秘密鍵が存在する特定のデバイス上でのみ実行できます。
  • キーは単一のデバイスにのみ存在するため、デバイスへのアクセスが失われた場合に備えて、回復パスをトリガーする必要があります。
• 複数のデバイスまたは同期
  • 秘密鍵はユーザーのデバイス間で同期されます。
  • 一般的なオプションとしては、Google パスワード マネージャー、iCloud キーチェーンなどの使用が挙げられます。
  • キーはエンドツーエンドで暗号化されているため、プロバイダーはキーを保存していても、それを見たり使用したりすることはできません。
  • これにより、ユーザーは 1 つのデバイスのみを登録し、デバイス間で同じキーを再利用できるため、使いやすさが向上します。

パスキーのポータビリティ

前のセクションですでに説明したように、パスキーはデバイス間で同期できるため、ポータブルであることがわかります。プロバイダー (Google、iCloud) にサインインしている限り、パスキーをすべてのデバイスで使用できます。ここで、友人のコンピューターやライブラリなど、基本的に 1 回だけ使用するデバイスなど、自分のものではないデバイスでパスキーを使用する方法という疑問が生じます。パスキーはこのケースにも対応します。2 つのシステムがパスキーをサポートしている場合、Bluetooth 経由で相互に通信してアクセスを共有できます。その仕組みをステップごとに見ていきましょう。

• パスキーがないデスクトップで Web サイト xyz.com を開きます。
• 別のデバイスでパスキーを使用してサインインするオプションを使用できます。
• デスクトップには、近くにある利用可能なデバイスのオプション、または QR コードが表示されます。
• デバイスを選択するか、QR をスキャンすることができます。
• その後、モバイル デバイスを使用して自分自身を認証し、デスクトップがモバイルからのパスキーを使用できるようにします。
• 認証されると、登録プロセスを経ずにデスクトップでパスキーを作成するオプションも表示されます。このオプションを選択すると、次回以降はモバイル デバイスは必要なくなり、デスクトップ用に新しいパスキー セットが作成されます。
• 1 回のみ使用することを選択した場合、新しいパスキーは作成されません。

採用に関するポイント

パスキーは、クライアント認証プロトコル (CTAP) と Web 認証 API (WebAuthn) を組み合わせた FIDO2 標準に基づいており、FIDO アライアンスと W3C の共同プロジェクトです。これらの標準化の取り組みは、採用と適切な実装を増やすことを目的としています。Google、Apple、Microsoft などの企業によって、OS およびブラウザ レベルでパスキーのネイティブ サポートが追加されており、パスキーの採用を促進するのに大いに役立っています。

業界ではパスワードが長年利用されてきたため、パスキーの導入は技術的な課題だけでなく、心理的な課題でもあります。エンド ユーザーは、パスワード ベースのシステムに慣れているため、最初はパスキーに不安を感じるかもしれません。パスキーはパスワードよりも安全で使いやすいですが、ほとんどの場合、既知のオプションに対する安心感が勝ります。パスキーを大規模に導入するにはユーザー教育が必要であり、最初は回復と使いやすさに関する疑問が残ります。

一方、十分なユーザー採用が見込めない場合、企業はパスキー認証の提供に消極的になる可能性があります。公共部門では、政府が政策変更を通じて採用を奨励することができます。

結論

パスキーは認証の分野を変革する可能性を秘めています。安全で使いやすいです。パスワードベースの認証に共通する脅威を排除しますが、課題や制限も伴います。アカウントの回復や資格情報のポータビリティは、適切に対処する必要がある問題です。次のステップは、ハイブリッド認証モード、つまりパスワードとパスキーを併用することだと思います。実際の導入が増えるにつれて、完全にパスワードのない未来に移行する前に、次にどこに向かうべきかを決めるためのより良いポイントとなる議論が増えるでしょう。

**