パスワードベースの認証は、長年にわたりデフォルトのモードでした。しかし、登録するすべての Web サイトのパスワードを覚えておきたいと思う人はいるでしょうか。ほとんどの人は、覚えやすいパスワードを多くの場所で使用しています。パスワード マネージャーを使用すると、資格情報の自動入力が容易になりますが、パスワードベースの認証システムに存在するセキュリティ上の懸念を設計から克服することはできません。そこで登場するのが Passkeys です。Passkeys はより安全で使いやすく、認証分野における新しいビジョンを備えたパスワードレス認証を提供し、将来有望です。
他のものと同様、パスキーにも利点と課題があります。この記事では、この認証モードの仕組み、安全性などについて説明しながら、それらについて説明します。
パスキーは、単一の文字列ベースのパスワードに頼るのではなく、公開キー暗号化を利用して認証フローを生成します。ユーザーのデバイスは公開キーと秘密キーのペアを生成し、公開キーをサーバーに送信します。サーバーはそれを保存し、後でそのキーを使用してユーザーを認証します。秘密キーはユーザーのデバイスに保存されます。
登録の流れ
認証フロー
注意すべき点
通常、セキュリティが強化されると使いやすさは低下しますが、パスキーの場合はそうではありません。登録フェーズが完了すると、パスキーは使いやすくなります。パスワードを覚えておく負担はなく、認証は迅速、簡単、かつ安全です。
パスキーは攻撃対象領域を減らし、パスワードに対する一般的な脅威の一部を排除します。パスワードは通常、データベースに暗号化された形式で保存されます。プレーンテキストのパスワードを使用して Web サービスにログインすると、同じ暗号化テキストが生成され、すでに持っているテキストと比較されます。これがユーザーの認証方法です。これで、最も一般的な 2 つの脅威が残ります。
データベースの侵害はよくあることで、サービスのデータが盗まれると、ダーク ウェブで売られることがよくあります。データにアクセスできる悪意のある人物は、オフラインで暗号化を破ろうとしますが、今日のコンピューター処理能力では、暗号化によっては数週間から数か月かかる可能性があります。パスキーでは、保存するパスワードがないため、この脅威が排除されます。漏洩が発生した場合、公開キーのみが露出し、悪意のある人物にとってはあまり役に立ちません。
フィッシング攻撃では、ターゲット Web サイトのクローンが作成され、ユーザーは本物のサイトと勘違いして認証情報を入力させられます。ただし、盗む認証情報がないため、Passkeys ではこれも機能しません。中間者攻撃と組み合わせた高度なフィッシング攻撃は依然として実行可能ですが、攻撃対象領域は大幅に縮小されます。
前のセクションですでに説明したように、パスキーはデバイス間で同期できるため、ポータブルであることがわかります。プロバイダー (Google、iCloud) にサインインしている限り、パスキーをすべてのデバイスで使用できます。ここで、友人のコンピューターやライブラリなど、基本的に 1 回だけ使用するデバイスなど、自分のものではないデバイスでパスキーを使用する方法という疑問が生じます。パスキーはこのケースにも対応します。2 つのシステムがパスキーをサポートしている場合、Bluetooth 経由で相互に通信してアクセスを共有できます。その仕組みをステップごとに見ていきましょう。
パスキーは、クライアント認証プロトコル (CTAP) と Web 認証 API (WebAuthn) を組み合わせた FIDO2 標準に基づいており、FIDO アライアンスと W3C の共同プロジェクトです。これらの標準化の取り組みは、採用と適切な実装を増やすことを目的としています。Google、Apple、Microsoft などの企業によって、OS およびブラウザ レベルでパスキーのネイティブ サポートが追加されており、パスキーの採用を促進するのに大いに役立っています。
業界ではパスワードが長年利用されてきたため、パスキーの導入は技術的な課題だけでなく、心理的な課題でもあります。エンド ユーザーは、パスワード ベースのシステムに慣れているため、最初はパスキーに不安を感じるかもしれません。パスキーはパスワードよりも安全で使いやすいですが、ほとんどの場合、既知のオプションに対する安心感が勝ります。パスキーを大規模に導入するにはユーザー教育が必要であり、最初は回復と使いやすさに関する疑問が残ります。
一方、十分なユーザー採用が見込めない場合、企業はパスキー認証の提供に消極的になる可能性があります。公共部門では、政府が政策変更を通じて採用を奨励することができます。
パスキーは認証の分野を変革する可能性を秘めています。安全で使いやすいです。パスワードベースの認証に共通する脅威を排除しますが、課題や制限も伴います。アカウントの回復や資格情報のポータビリティは、適切に対処する必要がある問題です。次のステップは、ハイブリッド認証モード、つまりパスワードとパスキーを併用することだと思います。実際の導入が増えるにつれて、完全にパスワードのない未来に移行する前に、次にどこに向かうべきかを決めるためのより良いポイントとなる議論が増えるでしょう。
**