Table of Contents

    2要素認証でアカウントを保護する方法

    特定のサービスを利用する際の認証の目的は、サービスにアクセスするユーザーの本人確認を行い、なりすましを防止することです。認証は、質問に対する答えをユーザーに求めることによって実行されます。質問の内容は次のとおりです。

    • 記憶情報(ユーザーが知っていること):通常はユーザーのパスワードまたはPIN。
    • 生体情報(ユーザーの身体的特性):ユーザーの生体認証データ(指紋、顔認証、虹彩スキャン、筆跡など)。
    • 所持情報(ユーザーが持っているもの):ここでモダンな2要素認証(2FA)アプリケーションが登場します。アプリは、設定された時間が経過すると期限切れになるセキュアなランダムトークン(通常は6桁の数字)を生成します。スマートカード、USBキー、SMSベースのワンタイムパスワード(OTP)を認証に使用することもできます。
    • ユーザーが提示したいずれか2種類の回答を2要素認証に使用したユーザーの本人確認:2要素認証はユーザーのパスワードが漏洩または侵害された場合にセキュリティを提供するよう設計されています。また、多層防御の追加の保護層としても役立ちます。

    職場のアカウントの2要素認証

    2FAを回避する方法を説明する前に、2FAの動作の大まかな流れを見てみましょう。

    ここでは、Webアプリケーションの管理者ジェームズがMyWorkAppというアプリケーションを管理し、従業員のアリスがMyWorkAppを使用すると想定したシナリオを考察します。

    1. ジェームズが2FAサービスを設定し、ユーザーが使えるように有効化する。
    2. 2FAが有効になった後、アリスがこのアプリケーションに初めてログインする。ログインにはユーザー名とパスワードを使用。
    3. アプリケーションにQRコードとテキストボックスが表示され、携帯電話でQRコードをスキャンして生成された番号を入力するよう指示される。このステップをSETUPと呼ぶことにしましょう。このステップに関連する情報はhttps://myworkapp.com/2fa/setupでご覧ください。
    4. アリスは携帯電話の認証アプリでQRコードをスキャンし、生成された番号を入力する。
    5. MyWorkAppは、緊急用にいくつかのバックアップコードをアリスに提供する。
    6. 次回からは、アリスがユーザー名とパスワードを入力したときにQRコードは表示されず、生成されたコードの入力を求められる。このステップをVERIFYと呼ぶことにしましょう。このステップに関連する情報はhttps://myworkapp.com/2fa/verifyでご覧ください。
    7. アリスは認証アプリのコードを入力し、ログインする。
    architecture

    図1:通常のアプリケーションフロー

    攻撃シナリオ

    大まかな流れを見てきたところで、ソーシャルエンジニアリングなどの方法でアリスのパスワードを入手した攻撃者ボブの登場です。ボブはアリスの携帯電話で生成された2FAコードを持っていないので、本来ならアリスのアカウントを乗っ取ることはできないはずですが、

    MyWorkAppには構成ミスがあり、複数のデバイスで2FAを構成できるようになっています。つまりアリスは、同じコード生成ツールを実行する2台以上の携帯電話またはデバイスで2FAを設定できます。ボブはこの情報を使用して、次の方法でアプリケーションに対するエクスプロイト攻撃を仕掛けます。

    1. ログインページに移動し、アリスのユーザー名と盗んだパスワードを入力する。
    2. このリクエストに対する応答を受信する。この応答には、VERIFYステップ(https://myworkapp.com/2fa/verify)へのリダイレクトを示すURLが含まれています。
    3. この応答を傍受し、URLをSETUPステップ(https://myworkapp.com/2fa/setup)に変更する。
    4. アプリケーションサーバーがこのリクエストを受信すると、ボブにQRコードを使用して2FAを設定するよう求めるプロンプトが表示される。
    5. ボブは携帯電話のアプリで、取得したQRコードをスキャンする。
    6. 2FAコード生成ツールを手に入れたボブは、それを利用してアリスのアカウントを乗っ取ることができる。
    attack-scenerio

    攻撃者がユーザーのOTPにアクセスする

    攻撃の仕組み

    ボブがアリスのOTP(ワンタイムパスワード)生成ツールを制御できた理由

    • 生成ツールは、OTPを確認するために複数のデバイスを登録することができる。
    • アプリケーションサーバーは、クライアント側のコードに依存してログイン後の次の宛先URLを生成する。
    • アプリケーションは、ユーザーが以前に2FAデバイスを登録したかどうかを確認せずに/2fa/setupへのリクエストを受け入れる。

    2FAは同じユーザーと結合されているため、同じQRコードが表示される可能性があります。

    2要素認証の強化

    2FA設定のセキュアな実装では、トークンを生成するためのQRコードなどの重要情報の応答を開始する前に、ユーザーの本人確認を行う必要があります。2FAを初めて設定するユーザーは、生成されたトークンの代わりに使用できるバックアップ・コードを受け取ることをお勧めします。バックアップコードは、ユーザーがトークンの生成に使用されたデバイスにアクセスできなくなった場合のバックアップとして機能します。アプリケーションが有効なバックアップコードを検出すると、以前に設定したデバイスを無効にして新しいデバイスを登録するように求めるメッセージが表示されることがあります。また、認識されないログインが発生したときに、ユーザーに通知が送信されます。システムまたはユーザープロファイルの状態を変更するユーザー操作はサーバー側で制御し、妥当性を検査する必要があります。

    このようなリスクと脅威について詳しく理解したい方は、アプリケーションセキュリティの脅威およびリスク評価 を参照ください。