多要素認証

読み：たようそにんしょう　／　英語表記：Multi-Factor Authentication

セキュリティ

本人の知識情報・所持情報・生体情報のうち、異なる種類を2つ以上組み合わせて本人を確認する認証方式である。同じ種類の確認を繰り返すだけでは該当せず、一つの要素が盗まれたり漏えいしたりした場合の不正ログインのリスクを下げる。

イマシルちゃんの解説

パスワードを他人に知られてしまうと、それだけで本人になりすまされることがあるよ。
多要素認証は、本人が知っていること・持っている物・身体の特徴の中から、違う種類を2つ以上組み合わせる認証方式だよ。
例えばパスワードの入力後に、登録したスマートフォンの認証アプリが表示するコードも確認するんだ。
パスワードだけを盗んだ人は、必要なコードを用意できないからログインしにくくなるよ。
大切なのは確認する回数を増やすことではなく、違う種類の証拠を組み合わせることなんだ。

より深い解説

何を組み合わせるのか

多要素認証はMFA（Multi-Factor Authentication）とも呼ばれる。本人を確かめる根拠を認証要素と呼び、次のように分類する。画面に入力する文字の数や、使う機器の台数を数えるものではない。

要素	何を確かめるか	代表例
知識情報	本人が知っている秘密を使えるか	パスワード、PIN
所持情報	本人に結び付けた物や認証器を使えるか	セキュリティキー、秘密情報を保持した認証アプリ、ICカード
生体情報	本人の身体などの特徴に合致するか	指紋、顔などを用いた照合

認証器とは、認証に必要な秘密情報などを使う装置やソフトウェアである。スマートフォンを画面の前に持ってきただけでは、所持する根拠にならない。登録した鍵や秘密情報を使った応答などを通じて、その認証器を使えることを確認する。

異なる2種類を使う場合は二要素認証（2FA）と呼ぶ。これはMFAの一種である。認証要素の分類と、複数の認証器を組み合わせる方法はNIST SP 800-63B-4に整理されている。

入力回数が多ければよいわけではない

パスワードの後に秘密の質問へ答える方式を考える。入力は二段階でも、両方とも覚えている秘密を答える方法である。この組合せだけでMFAにはならない。秘密の質問は分類を説明するための例であり、強い認証方式として勧めるものではない。

一方で、セキュリティキーをPINで解除して認証する場合は、一つの装置の中で「その装置を使えること」と「解除する秘密を知っていること」を組み合わせられる。見た目の操作が少なくても、異なる種類の確認を行っている場合がある。

組合せ	MFAになるか	判断する理由
パスワードと秘密の質問	この組合せだけではならない	どちらも覚えた秘密を答える
パスワードと登録済みのOTP認証器	なる	覚えた秘密と、登録した認証器を使えることを組み合わせる
PINで解除するセキュリティキー	要件を満たす構成ならなる	装置の保有と、装置内でのPIN確認を組み合わせる
パスワードと社内IPアドレスからの接続	これだけでMFAとは判断しない	接続元の制限と、本人に結び付いた認証要素は異なる

複数の手順を順に通過させることは多段階認証であり、MFAとは着目点が違う。段階数と要素の種類を分けて考える必要がある。端末内での確認についてはWebAuthnの認証要素モデル、接続元などの補助情報の扱いはNISTの保証レベルの説明を参照できる。

ワンタイムパスワードを使う場合

ワンタイムパスワードは、一定の条件で一度だけ使える認証用の値である。パスワードと組み合わせる方式では、利用者が登録した認証器で値を生成できることなどを追加の根拠にする。

時刻を使うTOTPでは、認証アプリとサーバが共有する秘密情報と現在時刻から値を計算する。双方が同じ条件で計算すれば、サーバは入力された値を照合できる。カウンタを進めて値を変えるHOTPという方式もある。

処理	何をするか
登録	アカウントと認証器を対応付け、値の生成に必要な秘密情報を設定する
ログイン	パスワードに加えて、認証器が表示した値を入力する
検証	サーバが期待する値と照合し、有効範囲や使用済みかどうかを確認する

時刻を使う方式でコードが合わない場合は、入力ミスだけでなく認証器の時計のずれも調べる。登録時に使うQRコードに共有秘密が含まれる構成では、その画像の流出も問題になる。表示中の短い数字だけが守るべき情報ではない。

また、ワンタイムパスワードという名前に「パスワード」が含まれていても、利用者が覚えている秘密を確認する方式と同じ分類にするとは限らない。何を根拠に本人を確認しているかを見て判断する。値の生成と検証条件はRFC 6238とRFC 4226に定められている。

フィッシングへの強さを分けて考える

MFAを導入しても、どの方式でも偽サイトに強くなるわけではない。攻撃者が本物そっくりの画面でパスワードとOTPを入力させ、有効なうちに本物のサービスへ中継すると、不正ログインが成立することがある。コードが短時間で変わるだけでは、この中継を防げない。

偽の認証先へ誘導されても認証情報を不正利用されにくくする性質をフィッシング耐性と呼ぶ。FIDO2やWebAuthnを利用する方式では、認証を行うサービスと公開鍵の資格情報を結び付ける。別のサイト向けの認証結果をそのまま本物のサイトへ流用できないようにする設計が重要である。

方式	主な注意点
SMSによるコード受信	電話番号の不正な移行や通信経路への攻撃、偽サイトへの入力に注意する
認証アプリのOTP	共有秘密の流出や、コードをリアルタイムに盗む偽サイトに注意する
プッシュ通知への承認	身に覚えのない要求でも、通知を繰り返されて承認してしまう危険がある
FIDO2・WebAuthnに基づく認証	接続先への結び付きに加え、必要な本人確認を行ったかサービス側も検証する

認証方式ごとの特徴はCISAの方式比較で確認できる。MFAかどうかと、どの攻撃に耐えられるかは別に評価する。

プッシュ通知を繰り返して承認を誘う攻撃はMFA疲労攻撃と呼ばれる。対策の一つであるナンバーマッチングでは、ログイン画面側の番号を認証アプリで照合させる。単に通知の承認ボタンを押す方式より、要求と操作を結び付けやすい。ただし、これだけで偽サイトによる中継への耐性と同じになるわけではない。Microsoftの実装説明に操作例がある。

パスキーと生体認証の関係

パスキーは、FIDOに基づく公開鍵の資格情報である。サービス側へ登録した公開鍵に対応する秘密鍵を使って、要求ごとに作られる値へ署名する。サービス側はその署名を検証する。利用者がパスワードを送る方式とは処理が異なる。

スマートフォンで指紋を確認してからパスキーを使う場合、その指紋は通常、端末内の認証器を使うための確認に用いられる。指紋画像をWebサイトへ送って照合するという意味ではない。所持する認証器と端末内での本人確認を組み合わせ、サービス側が本人確認の実施を要求・検証すればMFAとして使える。FIDO Allianceの説明はこの条件を明記している。

セキュリティキーに触れる操作も、そのまま指紋認証とは限らない。単なるタッチは「人が操作している」というUser Presenceの確認である。PINや指紋によって利用者を確かめるUser Verificationとは区別する。サービスが後者を必要とするなら、確認済みであることを示すUVフラグなども検証する。

生体認証には誤って一致する可能性や、本人でも一致しない可能性がある。顔や指紋はパスワードのように自由に交換できる秘密でもない。NISTのオンライン認証要件では、身体的な特徴だけを単独の認証器として扱わず、物理的な認証器と組み合わせる。NISTの認証器要件を参照できる。

登録・回復・例外も認証の一部になる

ログイン画面を強くしても、攻撃者が自分の認証器を他人のアカウントへ登録できれば意味がない。最初の登録、認証器の追加、紛失時の再設定についても本人確認が必要になる。認証器を変更したときは利用者へ通知し、身に覚えのない変更を発見できるようにする。

紛失に備える方法には、予備の認証器や一度だけ使うリカバリーコードがある。これらは本人を助ける経路であると同時に、攻撃者にも狙われる。パスワードだけでMFAを解除できるなど、通常のログインより弱い回復経路を安易に作らない。本人確認の厳しさと、利用者が業務を継続できる方法を一緒に決める。OWASPの運用資料に回復時の検討事項がある。

共通の障害で全部の認証器が使えなくならないようにすることも大切である。例えば同じスマートフォンにしか認証手段がなければ、故障時にまとめて使えなくなる。別の認証器を用意するか、管理された回復手順を持つかを選ぶ。

導入範囲と認証後の保護

企業でMFAを導入するときは、VPN、管理画面、クラウドサービスなどの入口を洗い出す。通常のWeb画面だけを対象にしても、別の接続方式で同じアカウントを使えるなら適用が抜ける可能性がある。SSOを使う構成でも、認証を集約しただけで自動的にMFAになるわけではない。

接続元や端末の状態から危険度を評価し、追加確認を求める仕組みをリスクベース認証と呼ぶ。これはMFAを要求する条件の調整に使えるが、IPアドレスがいつもと同じというだけで、新しい種類の認証要素を確認したことにはならない。

認証後はセッションも保護する必要がある。MFAを通過した後のセッション情報を盗まれると、認証画面をやり直さずに本人として扱われることがある。通信の暗号化、Cookieの適切な属性、セッションの期限管理、重要操作時の再確認を組み合わせる。認証とセッションの関係はOWASPのセッション管理資料で整理されている。

設計問題での考え方

例えば「パスワードと別の暗証番号を順に入力する仕組みをMFAと呼べるか」と問われたら、入力欄の数で判断しない。両方とも覚えている秘密なので、異なる種類を組み合わせた根拠がないと説明する。

「MFA導入後も偽サイトから不正ログインされた」という条件なら、入力されたコードをリアルタイムに中継できる方式かを確認する。また「認証アプリを変更した直後に被害が起きた」なら、ログイン方式だけでなく再登録時の本人確認を調べる。要素の分類、攻撃への耐性、運用上の抜け道を分けて考えると、必要な対策を具体化できる。