管理者ガイド パート 3：パスワードレスの定義、本当にフィッシングを防げるのか？
『パスワードレス化に向けた管理者ガイド』ブログシリーズ
この記事は、Tech Lead である Jeremy Erickson によるブログ「Administrator’s Guide, Part 3: What Makes Passwordless, Dare We Say It, Phish-Proof?
」（2021/7/15）の抄訳です。
ある意味では、「パスワードレス」という用語は間違っています。もちろん、パスワードが不要な認証方式であり、ログインエクスペリエンスが大幅に効率的になるのは大きなメリットではありますが、認証セキュリティ自体が強化されるわけではありません。
パスワードレス認証では、1 つのステップで複数の要素が使用されます。オーセンティケータデバイスのロックをローカルで解除することで、クレデンシャルが再利用されたり、秘密キーが共有されたりするリスクが排除されます。それだけではなく、フィッシング攻撃のリスクを大幅に軽減または完全に排除することで、セキュリティが強化されます。この条件を満たしていない「パスワードレス」ソリューションは、セキュリティ面で劣っています。
すべてのパスワードレス ソリューションでフィッシング対策が必要だと言っているのではありません。読者が検討している認証ソリューションには自社の環境に適した他の特性があり、認証要素を追加することでフィッシングのリスクを軽減できる場合があります。すべてのソリューションがフィッシング対策に同じメカニズムを使用するわけではありませんが、実際にフィッシングに対応しているソリューションにはいくつか共通の特性があります。
認証ソリューションでフィッシングを防止するには、以下のようないくつかの一般的な特性が必要です。
秘密キーが共有されない：秘密キーが決して共有されず、常にローカルのオーセンティケータデバイスに保持されています。オーセンティケータはその秘密キーを使用してメッセージに署名します。このメッセージは、オーセンティケータデバイスからのみ送信されたものであることが相手によって検証されます。パスワードや他の共有秘密キーベースのアプローチとは異なり、このソリューションでは、1 つの Web サイトで使用される秘密キーが、他の Web サイトで使用される秘密キーとは異なる別のものであることが保証されます。
送信元バインディング：ユーザがログインしようとしているサイトが、ユーザが実際にアクセスしているサイトのドメインまたは送信元と一致している必要があるという特性です。これまでのアクティブフィッシングの経緯から、これらが一致しているとは限らないことがわかっています。そのため、すべてのソリューションは、認証前にドメインをチェックすることをユーザに委ねないようにする必要があります。
秘密キー（クレデンシャル）は、登録されたドメインにリンクされている必要があります。また、ユーザが実際にそのページにアクセスしていることを自動的に確認する仕組みがない場合、ロックを解除してはいけません。最初の「秘密キーが共有されない」という特性によって、サイトごとにクレデンシャルが異なっていることが保証されます。そのため、フィッシングサイトは、自身のドメインのクレデンシャルにはアクセスできても、別のサイトのクレデンシャルにはアクセスできません。
チャネルバインディング：オーセンティケータから Web サイトへの通信チャネルを、認証を試みるブラウザセッションに強く結び付けるという特性です。つまり、攻撃者が攻撃対象者になりすましてログインしようとしても、ユーザのオーセンティケータにアクセスしてユーザにログインさせることはできないということです。一方、バインディングしていないと、プッシュフィッシング攻撃を仕掛けられる可能性があります。ユーザのブラウザ（またはその他の正規のソフトウェア）だけがオーセンティケータデバイスをアクティブにできるようにしなければなりません。そのために、ブラウザとオーセンティケータ間のチャネルをバインドする必要があります。これは 3 つの特性の中で最も曖昧で、認証ソリューションで欠けている場合が多いものです。
次に、WebAuthn と FIDO2 がこれらの特性をどのように実装して、非常に強力なフィッシング対策を実施しているかを確認していきましょう。まず、FIDO2 に準拠したオーセンティケータデバイスは、設計上、秘密キーを共有しません。オーセンティケータは、すべての Web サイトに対して新しいキーペア（クレデンシャル）を生成し、公開キーを Web サイトに登録します。これにより、後でログインする際に署名されたメッセージを検証できます。
WebAuthn ログインでは、Web サイトではなく、ブラウザ自体が、ページの送信元情報を署名済みアサーション応答に含めて、オーセンティケータデバイスに渡します。そのため、署名済みアサーションは、送信元と一致するページでのみ使用できます。他のサイトでは受け入れられません。その結果、パッシブフィッシング（被害にあったサイトの UI をまねたサイトなど）が排除されます。送信元には https:// スキームも含まれているため（WebAuthn には TLS が必要）、TLS ストリッピング攻撃を使用するようなアクティブフィッシング攻撃でも防御できます。
WebAuthn プロトコルでサポートされている、オーセンティケータを呼び出すメカニズムは、限定されています。その 1 つが、Windows Hello、Touch ID/Face ID、Fingerprint/Face Unlock（それぞれ、Windows/Apple/Android デバイスの機能）などの、アクセスデバイスに組み込まれたプラットフォーム オーセンティケータを検索する仕組みです。このオーセンティケータは、アクセスデバイス自体に組み込まれているため、オーセンティケータとブラウザセッション間のチャネルをバインディングするのは簡単です。攻撃者は、攻撃対象のデバイスに対して十分な権限がなければ、攻撃対象のプラットフォーム オーセンティケータを呼び出して、フィッシング攻撃を仕掛けることはできません。
WebAuthn 準拠のオーセンティケータのもう 1 つのカテゴリは、ローミング オーセンティケータです。このオーセンティケータは、アクセスデバイス自体からは独立していて、さまざまなデバイスで使用できます。YuBikey などの USB ポートに接続するものや、Bluetooth または近距離無線通信（NFC）で接続したりするものがあります。いずれの場合も、攻撃者がオーセンティケータを呼び出せないことが重要です。
USB 接続のオーセンティケータの場合、オーセンティケータをアクセスデバイスに接続することで、通常は、プラットフォーム オーセンティケータと同様に、アクセスデバイスからオーセンティケータに排他的にアクセスして制御できるようになります。Bluetooth 接続オーセンティケータの場合、アクセスデバイスと Bluetooth 接続オーセンティケータをリンクするために、ユーザが自分でペアリングする必要があります。攻撃者は、何らかの方法で攻撃対象者をだまして Bluetooth 接続オーセンティケータを攻撃者のデバイスにペアリングさせない限り、リモートから Bluetooth 接続オーセンティケータを呼び出すことはできません。
NFC は、数センチの短距離でのみ使用できます。そのため、USB 接続オーセンティケータと同様に、攻撃者は、物理デバイスを攻撃対象者のオーセンティケータと非常に近いとろこにもっていかなければなりません。NFC などのプロキシミティベースの制御は、重要なチャネルバインディング特性を突破する可能性がある、リレー攻撃に対しては脆弱です。しかし実際には、リレー攻撃は一般的に標的型で、個別の標的を対象としています。現在のパスワードや 2FA に対して広く使用されているフィッシング攻撃よりも、複雑さと対象が限定されている点で、生体情報スプーフィング攻撃に似ています。
WebAuthn と FIDO2 は、このようなセキュリティ特性を備えているため、WebAuthn と FIDO2 に準拠した製品は、フィッシング攻撃に対応した最も安全な認証方式として認識される傾向にあります。しかしここで、パスワードレス ソリューションに共通するアンチパターン（これらの特性に反している場合や、導入される脆弱性など）について説明します。
プッシュ型 2FA
プッシュ通知ベースの方式は、パスワードベース認証のリスクを軽減する点では優れていますが、多くの場合、フィッシングが可能です。通知が SMS メッセージやアプリから送信されたものであれ、プッシュするのに生体認証（多要素化）が必要なものであれ、プッシュベースのソリューションは、通常、チャネルバインディング機能が脆弱か、または存在しません。プッシュ通知を開始するように設定されたログインプロンプトに攻撃対象者のユーザ名を入力できる攻撃者であれば、オンデマンドで対象者のスマホにプッシュ通知を送信できます。これは、通常の操作では、ユーザのブラウザセッションとユーザのスマホ間のチャネルがバインドされないため、攻撃者のブラウザが攻撃対象者のスマホにプッシュ通知を送信していることを識別してブロックすることが難しいからです。
プッシュ通知を第 2 の要素として、パスワードなどの第 1 の要素と組み合わせて使用すれば、攻撃者が攻撃対象者のパスワードも知っていなくてはならないため、このリスクは軽減されます。ただし、プッシュベースの認証が第 1 要素として使用される場合、プッシュフィッシングはかなり大きな脅威になります。
ヒント：プッシュベースのパスワードレス ソリューションを評価する場合は、匿名の攻撃者がプッシュフィッシングをユーザに仕掛けられないように、アクセスデバイスのブラウザセッションをプッシュデバイスにバインドする方法に関するドキュメントを確認してください。
QR コードスキャン
一部の認証ソリューションでは、1 つのデバイス（多くの場合、スマートフォン）から別のデバイス（多くの場合、PC）に信頼ステータスをブート/転送するために QR コードを使用しています。次の例を見てみましょう。ユーザが PC で Web サイトにログインしようとしています。Web サイトには、ユーザがスマホでスキャンするための QR コードが表示されます。ユーザが QR コードをスキャンすると、スマホが Face ID スキャンなどの認証処理を開始します。ユーザが Face ID スキャンを完了すると、スマホから Web サイトにユーザの ID が通知され、Web サイトは、そのユーザが PC からログインできるようにします。
残念ながら、この認証モデルでは、必要なチャネルバインディングが機能していません。つまり、攻撃対象者はフィッシングされて、ログインしようとしているサイトと同じように見える別のページに誘導される可能性があります。表示された QR コードは攻撃者によるもので、QR コードをスキャンすると、最終的には、攻撃者が自分のブラウザセッションを利用して、攻撃対象者としてログインできるようになってしまいます。この一般的な攻撃カテゴリは、QRLJacking と呼ばれています。
被害者がフィッシングサイトにアクセスしなくても、QRLJacking 攻撃は有効になってしまいます。QR コードは人間が判読できませんが、さまざまな URI スキームを含む、事実上あらゆる文字列を含めることができます。App Links や Universal Links は、モバイルアプリケーションを自動的に開いて起動するように設計されたリンクです。たとえば、誰かがデジタルビルボードで QR コードをスキャンすると、オーセンティケータアプリが起動されます。そこで、Face Unlock と WebAuthn を使用して認証し、確認ボタンを 1 回クリックするだけで、攻撃者がユーザのアカウントにログインできるような応答が返されてしまいます。QR コードを使用してデバイス間でプロキシ認証を行う方式は恐ろしいものです。
ただし、QR コードスキャンのリスクは、実行される状況によっては低くなることもあります。最初の OTP シードの作成時など、初めてアカウントまたはオーセンティケータをセットアップする際に QR コードを使用するソリューションが多く存在します。通常これらの QR コードは、アカウントをセットアップするために 1 回だけスキャンされ、ユーザは特定の登録セッションをすでに開いているため、ログインのたびに QR コードを使用するソリューションと比べ、QR コードに中間者攻撃を仕掛けることで攻撃者がチャネルバインディングを突破するリスクは、非常に低くなります。
ヒント：認証製品がソリューションに FIDO2 または WebAuthn を使用しているというだけで、ベースプロトコルと同じようにフィッシング攻撃に対応できるという保証はありません。各ソリューションは、全体として評価する必要があります。
フォールバック認証方式
ちょっと待ってください。パスワードレスでない認証方式は、パスワードレス方式のアンチパターンでしょうか。
答えは、いいえですが、はいともいえます。
組織にパスワードレス認証を導入する場合（このシリーズのパート 4 で詳しく説明します）、ユーザは、最も脆弱な認証方式で守られているレベルです。パスワードレス認証は、迅速かつ簡単に利用できますが、攻撃者がユーザのパスワードをフィッシングし、2 番目の要素もプッシュフィッシングできる場合、組織は攻撃を受けやすい状態のままです。
リカバリフローも重要です。自社の環境からパスワードを完全に排除しても、ユーザがアカウントからロックアウトされた際に、自動電子メールリカバリフローを使用してアクセスを回復できる場合、電子メールリカバリフローは攻撃の対象となります。リカバリフローを開始するためにユーザがクリックした電子メール内のリンクは、一時的なアクセスコード（コピーして正しいフィールドに貼り付ける必要がある）よりもフィッシングを受けにくくなっています。電子メールで送信されたリカバリリンクは、通常、上記のようなプッシュフィッシング攻撃の対象にはなりません。リカバリリンクによって、ユーザのデバイスで新たなブラウザセッションが作成されるため、攻撃者のデバイスで開始された既存のブラウザセッションは認証されないからです。
パスワードレス認証用の新しいリカバリフローが早い段階から検討されていますが、フォールバック認証方式と現在のリカバリ方式は、今後もある程度利用される可能性があります。パスワードレス認証の導入を評価する際は、実現可能な最高のレベルだけでなく、サポートする最低のレベルも考慮する必要があります。
