```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` - [Tweet](https://twitter.com/share?ref_src=twsrc%5Etfw) - [noteで書く](https://note.mu/intent/post?url=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235371%2F&ref=https%3A%2F%2Fjapan.zdnet.com%2Farticle%2F35235371%2F&hashtags=ZDNET) - - 印刷する - - メールで送る - テキスト - HTML - 電子書籍 - PDF - - ダウンロード - テキスト - 電子書籍 - PDF - - クリップした記事をMyページから読むことができます 　近年、ユーザー名とパスワードの漏えいは、最も深刻で、被害が甚大かつ高額なコストを伴うデータ侵害の主因となっている。強力なパスワードの選定やその適切な使用方法、さらにはソーシャルエンジニアリング攻撃に対する継続的な注意喚起が行われているにもかかわらず、こうした対策は脅威アクターの侵入を防ぐ上で、ほとんど効果を発揮していないのが現状である。 　SMSやメールによるワンタイムパスワード（OTP）の送信といった追加の認証要素は、欠陥のある認証システムに対する一時的な対処策と広く認識されており、それ自体が安全な手段とは見なされていない。実際、ほとんどの実装において、SMSもメールもエンドツーエンドの暗号化が施されておらず、通信の安全性に問題がある。特にメールは、複数の技術的手法によって容易に傍受される可能性があり、その皮肉な例として、パスワードの漏えいが挙げられる。 　BankInfoSecurity.comは2025年6月、アラブ首長国連邦中央銀行が金融機関に対し、「SMSおよびメールによるワンタイムパスワード（OTP）を含む脆弱（ぜいじゃく）な認証手段の廃止を求める指示を出した」と報じた。さらに、同年4月には、「Android」をベースとしたSMSメッセージ傍受用マルウェア「Gorilla」が開発中であることが明らかになった。こうした状況を踏まえ、AIがハッカーの主要な武器となる未来を見据え、Visaは2024年12月に、「AI駆動型詐欺の脅威に対応するため、オーストラリアの金融機関に対し、支払い認証における単一要素としてのSMS OTPの使用を廃止するよう求める」と発表した。 　過去5年間にわたり、従来とは全く異なる、より安全で、そして人間の不注意や知識不足に左右されにくい認証手段の必要性が高まってきた。こうした背景を受けて、FIDO Allianceに参加する主要なテクノロジー企業の一部は、ユーザー名とパスワードに代わる新たな認証方式の開発に取り組んできた。この新しい認証情報は、技術的には「FIDO2認証情報」と呼ばれているが、一般的には「パスキー」として知られている。 　パスキーとパスワードの主な違いは、ユーザーが安全なシステムにアクセスする際に秘密情報を共有する必要がない点にある。パスキーは公開鍵暗号方式に基づいており、ユーザーが「Relying Party（依拠当事者）」と呼ばれるウェブサイトやアプリに秘密を提出することはない。このアプローチの根本的な考え方は、正当な依拠当事者と秘密を共有する習慣そのものをなくすことで、悪意あるアクターに誤って秘密を渡してしまうリスクを根絶できるという点にある。 　しかし、パスキーにはいわゆる「鶏と卵」の問題が存在する。技術そのものはすでに整備されているが、それだけで即座に利用可能になるわけではない。実際にパスキーを使えるようにするためには、われわれが日常的に利用するすべてのウェブサイトやアプリが、認証情報および認証方式としてパスキーをサポートしている必要がある。 　本稿では、パスキーを設定する際の最初のステップとして、利用するウェブサイトやアプリ、すなわち依拠当事者がパスキーに対応しているかどうかを確認する方法について解説する。 ## 依拠当事者のパスキー機能の発見と利用 　われわれの多くは、依拠当事者において新しいユーザー名とパスワードを設定する一連の流れに慣れ親しんでいるだろう。通常、ウェブサイトにアクセスして「アカウント作成」などのボタンをクリックすると、ある段階でユーザー名とパスワードの入力を求められる。最近では、依拠当事者側が弱いパスワードを拒否する能力に長けてきており、セキュリティ面での配慮も進んでいる。このようなワークフローは、ユーザー名（多くの場合はメールアドレス）とパスワードを認証情報として登録する形式であり、従来型の認証情報の登録方法として広く定着している。 　従来のユーザー名とパスワードに基づく認証情報の登録と同様に、一部の依拠当事者では現在、ユーザー名とパスワードの代替手段として、パスキーを登録するためのワークフローを提供している。このパスキーは、ウェブサイトやアプリへのサインインにも使用可能な認証情報として機能する。 　現在、パスキーをサポートしている多くの依拠当事者では、まず従来のユーザー名とパスワードによる認証情報の登録から始め、その後、より安全なログイン手段としてパスキーの登録オプションを提供するという流れを採用している。また、一部の依拠当事者では、パスキーの登録を積極的に促進しており、ユーザーに対してその利点を強調しながら導入を後押ししている。 　そして、kayak.comのように、まれではあるが先進的な取り組みを見せる依拠当事者も存在する。こうしたサービスでは、従来のユーザー名とパスワードによる認証情報の登録ステップを省略し、代わりにパスキーによる認証から始める方式を採用している。実際、筆者が最近Kayakに登録した際には、ユーザー名やパスワードを作成する選択肢は一切提示されなかった。 　ここでは、shopify.comを例に取り、パスキーの発見から登録、認証、削除に至るまでの典型的な使い方を説明する。筆者が使用した環境は、「Mac」上で「Chrome」ブラウザーを実行している構成である。また、ブラウザーには「Bitwarden」のパスワードマネージャー拡張機能がインストールされている。なお、Bitwardenを選択したことは、特定の製品を推奨する意図によるものではない。ただし筆者は、ブラウザーやOSに組み込まれたパスワードマネージャーではなく、サードパーティー製のパスワードマネージャーを使用することを強く支持している。 　記事の内容を再現するに当たって、使用するブラウザーやOS、テスト対象のウェブサイト、あるいはパスワードマネージャーが異なる場合、ユーザーエクスペリエンスには細かな違いが生じる可能性がある。ただし、一般的に言えば、パスキーをめぐる一連の流れは、多少のばらつきや混乱を伴うことがあっても、環境の違いにかかわらずおおむね共通している。 ZDNET Japan 記事を毎朝メールでまとめ読み（登録無料） [メールマガジン登録のお申し込み](https://japan.zdnet.com/newsletter/) ## ZDNET Japan クイックポール 所属する組織のデータ活用状況はどの段階にありますか？ ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。 ITビジネス全般については、 [CNET Japan](https://japan.cnet.com/) をご覧ください。