多段階認証

読み：ただんかいにんしょう

• セキュリティ

本人確認を複数の段階に分け、必要な各段階を通過した場合に認証を成立させる方式である。2段階で行うものは二段階認証と呼ばれる。認証の手順に着目した分類であり、異なる種類の認証要素を使うとは限らない。

イマシルちゃんの解説

ログインするとき、パスワードを入れたあとにスマホの認証アプリで表示されたコードも求められることがあるよ。
このように本人確認をいくつかの手順に分けて進めるのが「多段階認証」という認証方式なんだ。
最初の確認に成功しても、残りを通過するまではログイン完了にしないのが大切だよ。
ただし、確認を増やせばどれも同じように安全になるわけではないの。
パスワードのあとに秘密の質問へ答える場合は、どちらも知っている内容を確かめているだけなんだ。
何回確認したかに加えて、何を確かめたかを見る必要があるよ。

より深い解説

段階と認証要素は別の観点である

多段階認証は認証の処理を順番に進めることに着目した呼び方であり、特定の通信プロトコル名ではない。代表的な構成は、パスワードの検証後に追加の確認を行い、両方が成功した利用者だけにログインを許すものである。段階が2つなら二段階認証となるが、その名称だけでは安全性まで判断できない。

認証要素は、本人であることを確かめる根拠の種類である。パスワードなどの知識情報、認証器を持つことを示す所持情報、指紋などの生体情報を区別する。多要素認証は、このうち異なる種類を組み合わせる方式である。

したがって「多段階か」と「多要素か」は別々に判定する。同じ種類の情報を何回要求しても、種類が増えたことにはならない。OWASPの多要素認証ガイドも、パスワードとPINのような同種の組合せを区別している。

最後の例のように、一つの認証器で複数の要素を扱う構成もある。画面の枚数やコードの入力回数ではなく、実際に何を検証する仕組みかを確認する。認証器の種類と要素の組合せはNIST SP 800-63B-4の認証保証レベルでも整理されている。

秘密の質問は違いを説明する例であり、追加認証として採用を勧めるものではない。答えがSNSや公開情報から推測できる場合があり、パスワードと同じ攻撃で破られることもある。この点はOWASPの秘密の質問に関する資料を参照できる。

ログインをどの時点で成立させるか

多段階認証を安全に使うには、追加の画面を表示するだけでは足りない。サーバが認証の進行状態を管理し、必要な全段階を通過するまで保護対象へのアクセスを許可しないことが必要である。

パスワードとワンタイムパスワードを順に確認する構成を例にすると、処理は次のようになる。

1. ユーザーIDで対象アカウントを特定し、最初の認証情報を検証する。
2. 成功したら「追加認証待ち」という中間状態を作る。この状態では業務データを読み出せないようにする。
3. 同じアカウントと同じ認証処理に対する追加の証明を検証する。別人の成功結果を流用させない。
4. 必要な確認が完了した時点で認証済みのセッションを発行し、許可された操作へ進ませる。
5. 途中で失敗・期限切れ・取消しが起きた場合は、未完了の状態を残したまま通常のログインとして扱わない。

例えば、追加コードをまだ確認していないのに業務APIがデータを返すなら、画面上は二つの手順があっても認証を強制できていない。保護はブラウザの画面遷移ではなくサーバ側で実施する。OWASP WSTGは、Web画面だけでなくAPIや別のログイン経路でも認証が一貫して必須になっているかを確認対象としている。

追加確認に使うコードや通知の扱い

追加確認の方式には、認証アプリのワンタイムパスワード、登録端末への承認通知、セキュリティキーなどがある。多段階認証という語は、どの方式を採用するかまでは指定しない。方式ごとに防げる攻撃と運用条件が異なるため、単に「確認を一つ追加した」と扱わない。

使い捨てコードを用いる場合は有効期限と試行回数を制御し、いったん受け付けたコードの再利用を認めない。TOTPのように時間に応じて生成する方式では、端末と検証側の時計のずれも影響する。コードが届かないという症状と、入力したコードが期限や時刻の条件で拒否される症状を分けて調べる。ワンタイムパスワード自体の生成方法は別の学習対象である。

通知を承認する方式では、身に覚えのない要求を承認させる攻撃にも注意する。利用者が「ログインを求められたから承認する」ことを繰り返すと、追加の段階が意図した防御にならない。確認対象の操作を利用者が識別できる設計が必要である。

ログイン後に確認を追加する場合

通常のログインとは別に、送金や認証器の変更などの重要操作を実行する直前に追加の確認を求めることがある。必要な保証を引き上げるための追加認証をステップアップ認証と呼ぶ。一方、時間が経過した利用者にもう一度本人確認を求めることは再認証であり、毎回新しい種類の要素を追加するとは限らない。

重要操作では、過去にログインした事実だけでなく、どの方法で、いつ確認されたかも判断材料になる。例えば長時間前の通常ログインを、そのまま認証器の登録変更を許可する根拠にはしない。認証時刻や認証方法を確認し、操作に必要な条件を満たさなければ追加確認を行う。OWASP Authentication Cheat Sheetでは、重要な操作やアカウント回復後などの再認証を扱っている。

また、本人確認と操作権限は異なる。認証を十分に行った利用者でも、その利用者に許されていないデータを読めてよいわけではない。誰が何を実行できるかを制御する認可も、操作のたびに適切に確認する。

認証後のセッションと回復経路を守る

各段階を通過した後は、セッションIDなどによってログイン状態を維持する。認証が強くても、その識別子を盗まれて再利用されれば利用者になりすまされるおそれがある。このため通信のTLS保護とCookie属性の設定に加え、認証完了時のセッションID更新、期限管理、ログアウト時の無効化が必要になる。認証前後の状態を分離する考え方はOWASP Session Management Cheat Sheetを参照できる。

端末を紛失した場合の回復手順も、通常のログインと一緒に設計する。追加認証を簡単な申告だけで解除できるなら、攻撃者は通常の手順を通らず回復窓口を狙う可能性がある。事前に発行した回復コードなどを使う場合は安全に保管し、使用済みのものを無効にする。パスワードの再設定と認証器の回復は目的が異なるため、片方の成功だけで両方を無条件に解除しない。OWASP Forgot Password Cheat Sheetも、認証器の回復を別に考える必要性を示している。

「この端末では次回の確認を省く」という機能は、端末を信頼する情報が失われたり盗まれたりした場合まで含めて評価する。省略の期限や取消し方法を用意し、重要操作では別途確認する。利便性のための例外が、恒久的な迂回経路にならないようにする。

安全性と利用者の負担を両方評価する

手順が増えると入力ミスや端末紛失時の問い合わせも増える。どの段階で失敗したかを運用ログで区別できるようにすると、パスワード誤り、コード期限切れ、通知未達、アカウント状態の問題を切り分けやすい。ただし、パスワード・使い捨てコード・セッションIDそのものは記録しない。

繰り返し試行に対するレート制限も各段階へ適用する。一方、失敗しただけで長期間すべての利用を停止すると、第三者に業務を妨害されるおそれもある。制限、利用者通知、回復手順を組み合わせて設計する。

多段階にしただけでフィッシングを防げるわけでもない。利用者が偽サイトへパスワードと有効なコードを入力すれば、攻撃者がそれらを正規サイトへ中継できる方式がある。要素の種類、認証器と接続先の結び付き、認証後のセッション保護まで確認して初めて、どの攻撃に強い構成かを説明できる。

午後問題につながる判断

認証画面が二つ描かれている構成図では、最初に「各画面で何を確かめているか」を書き出す。パスワードと秘密の質問なら、確認は増えても認証要素は同じ種類である。パスワードと登録済み認証器の証明なら、異なる種類を組み合わせているかを検討できる。

実装や運用上の問題を問われた場合は、途中状態でアクセスできないか、回復経路だけ保護が弱くないか、認証後の識別子が守られているかを追う。例えば「追加認証待ちの利用者が業務データを取得できる」という問題には、確認画面を増やす対策では不十分である。データを返す処理で認証完了状態を検証する必要がある。

参考資料

• OWASP：Multifactor Authentication Cheat Sheet — 認証要素の区別と追加確認の運用を確認できる。
• NIST SP 800-63B-4：Authentication Assurance Levels — 要素の組合せと認証保証を確認できる。
• OWASP WSTG：Testing Multi-Factor Authentication — 複数段階の認証を強制する際の確認点を読める。
• OWASP：Session Management Cheat Sheet — 認証前後の状態とセッションの保護を確認できる。

この用語が出てくる記事

• 多要素認証