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