** 本記事は、The future of MFA is clear – but is it here yet? の翻訳です。最新の情報は英語記事をご覧ください。**
長年にわたり、業界は二要素認証 (2FA)、二段階認証、多要素認証 (MFA) や、ユニバーサル二段階認証 (U2F)、Fast IDentity Online 2 (FIDO2) 、WebAuthn、パスキーなど、あらゆる種類の最新かつ複雑な方式を使ってパスワードの補強 (またはアップグレード) を試み、自らに制約を課してきました。
これまでは、ほとんどの人がいずれかの認証方法を採用するだけで満足していました。パスワード以上の認証方式であれば進歩と言えるでしょうが、今や最低基準の引き上げが必要なところまで来ています。本記事では、「より強力な」認証方法をバイパスする手法を確認し、最良の道を指し示すつもりです。
二要素認証の過信は禁物
最も単純な「2FA」オプションの多くは、二要素認証の本来の趣旨に忠実ではありません。理想的には、「二要素」はユーザーが知る何か (パスワード、PIN など)、ユーザーが所持する何か (USB/Bluetooth トークン、スマートカード、公開/秘密鍵のペアなど)、ユーザーを証明する何か (指紋、顔写真など) の 異なる 3 つの要素から 異なる 2 つの要素を利用するべきです。残念ながら、初期のソリューションの大部分は、ユーザーが知る何かとユーザーが知る別の何かという同じ要素から 2 つを利用しています。
RSA トークン、SMS テキストメッセージ、TOTP (Google Authenticator や Authy などの時間ベースのワンタイムパスワード) スタイルの「2FA」を例にとると、ほとんどの場合、30 秒ごとに 6 桁のコードが表示されます。SIM スワップの可能性があることから SMS による認証が批判されていますが、実際には上述のいずれも脆弱で、容易に傍受されます。
たとえば、よく作り込まれた (おそらく AI 作成された) フィッシングメールを受け取ったとしましょう。この段階で詐欺師が侵害を成功させるには、多要素認証の使用の有無にかかわらず、受け取ったメールが正規のものだと受信者が信じなければなりません。ここで、ユーザーが知る 2 つの情報 (パスワードと動的に生成される秘密のコード) を認証のために要求すると、悲劇的な結末を迎えることになります。銀行、電子メール、あるいは企業アカウントにログインしていると信じ込んでいるユーザーは、パスワードだけでなく秘密のコードも疑いなく入力するでしょう。この種の認証は一方向でしか行われません。詐欺師はユーザーの身元を確認していますが、ユーザーは証明を求めるエンティティの身元を確認していません。
実際、この「ごまかし」を自動化するツールが数多く利用できます。中でも特に有名なのが evilginx2 です。元々は人気のある Web サーバー nginx をベースにしていましたが、今ではスタンドアロンの Go アプリケーションとなっており、知識ベースの多要素認証をフィッシングし、認証をバイパスするためにセッション Cookie を盗むオールインワンツールとして機能しています。そのため、攻撃を実行するハードルがかつてないほどに引き下げられています。
これまでの経緯
認証情報の侵害の歴史は、暗号化されていない Wi-Fi のスニッフィングや、暗号化される前のネットワークベースの攻撃に端を発します。2010 年には、FireSheep と呼ばれる悪名高いツールが存在し、カフェを訪れた攻撃者が、暗号化されていない Web を通じて人々のログイン情報を受動的に窃取できるように設計されていました。
こうした攻撃や 2013 年のエドワード・スノーデンによるリークに対応するため、私たちはオンラインのほぼすべての暗号化を進めました。この変更により、中間者 (MitM) 攻撃と呼ばれる攻撃に対する安全性が確保されました。現在では Web 全体、そしてスマートフォンアプリでさえも、HTTPS が使用されるようになり、結果として、通りすがりの第三者がオンラインでの閲覧や操作内容を盗み見るのを防げるようになっています。
その後、犯罪者は認証情報の窃取に移行し、私たちの多くは多要素認証のバリエーションに移行しましたが、これまた多くの場合、最もチープで簡単なバリエーションに過ぎません。ユーザーが知る何かに、ユーザーが瞬間的に知る何か他のものを加えただけのものです。この手法にほとんど効果はなく、私たちはもう一度前進する必要があります。
業界のコンセンサスは、多くの委員会や標準化団体の設立を経て、Web Authentication API (WebAuthn) として知られる広く合意された標準に落ち着きました。こうした混乱の詳細を知りたいのであれば、こちらの Reddit のスレッドが参考になりますが、本記事では深入りしません。
WebAuthn の概要
WebAuthn/passkeys は、多要素認証をフィッシング防止に役立てる試みです。もちろん完璧なものではなく、最近の研究では、特殊なハードウェアデバイスを使用した、限定的な (だが興味深い) MitM 攻撃手法 (CVE はパッチ適用済み) が発見されています。とはいえ、以下ではフィッシングに強い多要素認証としてご紹介します。
実際の手順を見てみましょう。たとえば、人気のソーシャルメディアサイトにアカウントを作成するとします。まず、パスキー対応のスマートフォンまたはパソコンを使って、パスキーで新しいアカウントを作成します。すると、使いたいユーザー名 (通常はメールアドレス) の入力を Web サイトが求めてきます。デバイスがユーザー名をサイトに送信すると、Web サイトはユーザー名、認証用の課題、サイトのドメイン名を返信します。デバイスは固有の暗号キーペアを生成し、Web サイト名とユーザー名と一緒に安全な場所に保存し、サイトからの課題に署名し、サイトがユーザーの識別子として使用できるよう関連の公開鍵を紐付けます。
ユーザーが次にこのサイトを訪れる際には、パスワードは不要です。しかし、このパスワードは定義上、単なる共有シークレットであり、窃取されたり、再現されたりする可能性があります。WebAuthn/passkeys はその代わりに、図 1 に示す通り、デバイスがサイトのドメイン名と一致するユーザー名を送信します。Web サイトは課題を返信します。デバイスはそのドメイン名の鍵を検索し、その鍵を用いて課題に署名し、ユーザーの身元を証明します。
図 1: WebAuthn 認可のユーザーエクスペリエンスの流れはスムーズで、ほとんどのアクションはユーザーの認証情報プロバイダー、ブラウザ、サイト間で発生します。
詳細については、vertx.io が開発者を中心にプロセスの仕組みを掘り下げています。
WebAuthn/passkeys の欠点
これらのデータ項目の組み合わせにより、鍵は簡単に盗まれたり再利用されたりすることなく、よく似たドメイン名の偽サイトにサインインしようとして騙されることもなくなります。(ここにも小さな攻撃対象領域があります。たとえば、ユーザーが zuzax.com のパスキーを追加した場合、攻撃者が自身の管理下に phish.zuzax.com というサブドメインを作成できれば、攻撃者はユーザーに、再現された課題への署名をさせることができます。)
デバイス自体を超えて、鍵がどこに保管されているかが、盗難や悪用に対する安全性を左右します。YubiKey や SmartCard のようなハードウェア U2F トークンを使えば、鍵はそのデバイスにロックされるため、窃取できなくなります。この場合に可能なのは物理的な窃取のみです。ハードウェアトークンの中には、ロック解除にバイオメトリクス、PIN、パスフレーズを必要とするものもあります。パスキーの登場により、秘密鍵は OS ベンダーのクラウド (iCloud、Google Drive、OneDrive) やパスワードマネージャー (Bitwarden、1password など) を通じて同期されるようになり、アカウントが侵害された場合に窃取されやすくなりました。
そしてもちろん、パスキーは実装されていなければ使えません。実装の責任は各 Web サイトにあります (この 1 年で、この件に関してそれなりの進歩を遂げました)。また、これまでと同様、特定の環境で MFA を有効にして使用しなければならない企業にもあります。私たちがセキュリティ担当者に対して、MFA を (パッチの適用や不要な RDP の無効化と同じく) 基本的なサイバーハイジーンとして扱うようアドバイスしていることとさほど変わりはありませんが、それでも予算を組んで実施する必要があります。
最後の欠点は、ログイン時にセットされるセッション Cookie ですが、これについては別の記事で取り上げます。
双方向 (かつ進歩的)
ユーザーは PIN、指紋、または顔認証を使用して自身のデバイスに対して身元を証明し、その後の認証プロセスはデバイスが双方に対して実行すべきです。こうした双方向性が、このトランザクションの最も重要な部分です。
私たちは皆、パスワードの窃取が問題であることを理解しています。この問題には、ナレッジベースの認証を追加することで対処しようとしてきましたが、結局のところ、ただその寿命を延ばしているだけに過ぎません。情報は窃取され、傍受され、再現される可能性があります。本当に多要素認証を実現するのであれば、知識だけに依存するのを止め、より強力な証明を要求する必要があります。
これは、セキュリティがユーザーの障害となっている現状を脱却するチャンスです。実際には、障害を軽減しながら、セキュリティを強化させることができます。現在のパスキーの実装は不安定で使いづらい部分もありますが、パスキーの利用者が大きな恩恵を受けることを確信しています。ユーザーインターフェースの問題も近いうちに解決されるはずです。私たちに選択肢はありません。パスキーこそが私たちにできる最善の解決策であり、犯罪者は私たちがその是非を論じるのを待ってはくれません。
