どうもTORAです。
最初に言葉の説明をしておくと、MFAはMulti-Factor Authenticationの略で、日本語では「多要素認証」と呼ばれています。Multiは複数、Factorは要素、Authenticationは本人かどうかを確かめる「認証」のことで、知っているもの（パスワードなど）と持っているもの（スマホや専用の鍵など）のように、種類の違う要素を2つ以上組み合わせてログインする仕組みです。なので、パスワードを2回聞かれるような、同じ種類の確認を重ねただけのものは多要素にはなりません[1]。
ログインのたびに、スマホに届いた数字を打ち込んだり、通知の「承認」を押したり。ちょっと面倒だなと思いながら使っている人も多いと思います。でも僕は、セキュリティ攻撃への対策として、多要素認証（MFA）はすごく効果の高い対策の一つだと思っています。
理由は単純で、パスワードだけが盗まれても、それとは別の種類の確認がもう一つ残るからです。攻撃者がその2つ目を持っていなければ、ログインを最後まで進められません。ただ、同じMFAでも方式によって強さにはかなり差があります。選べるなら、フィッシングに強い方式を選びたいところです。
説明の根拠には、主に二つの資料を使っています。一つは、アメリカ国立標準技術研究所（NIST）が2025年7月に確定版を公表した認証ガイドライン「SP 800-63B-4」です[2]。もう一つは、アメリカのサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が2022年10月付で出したMFAの資料です[3]。NISTの文書はアメリカ政府の情報システムでの認証を対象にしたもので[1]、日本の利用者やサービスに義務を課すものではありません。この記事では、方式の強さを比べるための技術的な物差しとして読んでいます。
MFA・2要素認証・2段階認証の違い
MFAは、種類の違う認証要素を2つ以上使う認証のことです[1]。要素は3種類あります。パスワードやPINのような「知っていること」、スマホや専用の鍵のような「持っているもの」、指紋や顔のような「その人自身の特徴」です[1][3]。
2要素認証は、このうち2種類を組み合わせたものの呼び方で、MFAの一つの形です。2段階認証は、ログインの手順が2回に分かれていることに注目した呼び方です。言葉としては、要素の種類が違うかどうかまでは表していません。とはいえ、画面に「2段階認証」と書かれていても、中身はMFAということもあります。名前ではなく、2つ目に何を使っているかで見分けるのが確実です。
たとえば、パスワードのあとに「最初に飼ったペットの名前は？」のような秘密の質問に答える方式を考えてみます。手順は2段階でも、どちらも記憶している情報です。パスワードは「知っていること」の要素で[1]、秘密の質問も同じ種類です。なので、種類の違う要素を2つ使うという条件を満たしません。
NISTの基準では、指紋や顔は、それだけでは認証手段として認められていません[1]。理由の一つは、秘密とは言えないことです。顔は写真に撮れますし、指紋は触った物に残ります[1]。そのため、手元の端末のような「持っているもの」と組み合わせて使う前提になっています[1]。
では、同じスマホでログインもコードの受け取りもする場合はどうでしょう。2つの経路が同じ端末で終わっていても、端末が一方の情報をもう一方へ勝手に漏らさなければ、別経路の確認として扱えます[1]。一方で、端末に入り込んだ悪意のあるアプリがSMSのコードを読み取り、攻撃者がそのコードでログインする例も示されています[1]。同じ端末でもMFAは成立します。ただ、その端末自体が乗っ取られると、2つの確認がまとめて崩れるおそれがあると考えておけばいいと思います。
パスワードが盗まれても止められる理由
MFAを有効にしていれば、パスワードのような一つの要素が漏れても、攻撃者は2つ目の要素を出せない限りアカウントに入れません[3]。暗号鍵の入った認証器を盗んだうえでパスワードも当てる必要があるなら、両方をそろえる手間は攻撃者にとって高すぎるものになり得ます[1]。
ここからは説明のための仮の話です。ある通販サイトからパスワードが漏れて、同じパスワードをメールでも使い回していたとします。パスワードだけで守られていれば、攻撃者はそのままメールに入れてしまいます。MFAを設定していれば、パスワードは合っていても、最後に本人のスマホや鍵での確認を求められます。それを持っていない攻撃者は、そこで止まります。
攻撃の手口ごとに見ると、こうなります。
- サービスからの流出：データベースが侵害されて、変換（ハッシュ化）して保存されたパスワードが盗まれると、攻撃者は自分の環境で回数制限なしに解読を試せます[1]。解読されても、2つ目の要素は残っています。
- リスト型攻撃：あるサイトで漏れたパスワードを使って、別のサイトにある同じ人のアカウントに入ろうとする攻撃です[1]。原因は使い回しですが、MFAがあれば正しいパスワードだけでは入れません。
- パスワードスプレー：よく使われるパスワードを、たくさんのアカウントに試していく攻撃です。MFAで止められる手口の例に挙げられています[3]。
- 通常のフィッシング：本物そっくりの偽サイトにパスワードを入力させる手口です[1]。偽サイトがパスワードだけを集めてあとで使う形なら、2つ目の要素がないのでログインできません。
ちなみに、パスワードを長く複雑にしても、キー入力の盗み取りやフィッシング、ソーシャルエンジニアリングには同じように破られます[1]。パスワードの強さとは別の軸で守りを足しておく意味は、ここにあります。
ただし、この理屈が成り立つのは、攻撃者が2つ目の要素を持っておらず、横取りもできない場合だけです。MFAで止められるのはよくある手口の「一部」とされていて[3]、すべての攻撃を防げるわけではありません。破られる場面は後半で扱います。
登録とログインの流れ
MFAは、認証アプリや鍵などの認証器を、自分のアカウントに結びつける登録から始まります[1]。認証器が追加されたときは、その操作とは別の経路で本人に通知する仕組みが求められています[1]。
仮の一般的な例で言うと、認証アプリを使う場合はこんな流れです。まず、アカウントの設定画面で認証アプリを登録します。アプリに表示されたコードを一度入力すると、登録が終わります。それ以降のログインでは、パスワードを入れたあとにアプリのコードを求められます。画面や手順はサービスごとに違います。
暗号鍵を使う方式では、サービスが毎回違う問いかけ（チャレンジ）を送り、手元の認証器が鍵で署名した答えを返します[1]。サービス側は、その認証器に対応する公開鍵で答えを確かめます[1]。
方式ごとの強さの違い
同じMFAでも、方式によって強さは違います[3]。代表的な方式を比べると、次のようになります。
- SMS・音声通話：電話番号にコードを送る方式です。三つの攻撃に弱いとされています。フィッシング、電話網の仕組み（SS7）の弱点を突く攻撃、そしてSIMスワップ（電話番号を攻撃者のSIMに移させる手口）です。そのため、最後の手段であり、より強い方式に移るまでの一時的な手段と位置づけられています[3]。NISTでも「制限付き」の扱いです。この方式を使うサービスには、代替手段の用意やリスクの説明が求められます[1]。
- 認証アプリのワンタイムコード（TOTPなど）：アプリに表示される使い捨ての数字を入力する方式です。SS7やSIMスワップは関係しませんが、フィッシングには弱い方式です[1][3]。
- 承認ボタンだけのプッシュ通知：届いた通知の「承認」を押すだけの方式です。通知を何度も送りつけて押させる攻撃に弱いとされています[3]。SP 800-63B-4は、承認を求める方式でも、ログイン画面に出た番号などを端末側へ入力させることを求めています。画面と端末の番号を見比べて承認するだけの方式も、もう容認できないとしています[1]。
- 番号照合つきのプッシュ通知：ログイン画面に出た番号をアプリに入力してから承認する方式です。通知の連打には耐えますが、フィッシングには弱い方式です[3]。なお、アプリに並んだいくつかの候補から選ばせるだけの方式は不十分とされています。当てずっぽうで正解できてしまうからです[1]。
- FIDO2／WebAuthn（パスキーを含む）：手元の端末や専用の鍵にある暗号鍵で答える方式です。広く使えるフィッシング耐性のある認証は、FIDO/WebAuthnだけとされています。通知の連打、SS7、SIMスワップのどれも関係しません[3]。
パスキーは、多くのサービスで使われている呼び方です。このうち、ほかの端末へ鍵をコピーして同期するものは、NISTの文書でいう「同期可能な認証器」にあたります。その多くは、WebAuthnという仕様の上に作られています[1]。一方、専用のセキュリティキーのように、鍵を外へコピーできない作りの認証器もあります[1]。
フィッシングに強いとはどういうことか
フィッシング耐性とは、利用者の注意力に頼らずに、認証の秘密や有効な認証結果が偽のサービスに渡るのを防げる性質のことです[1]。メールで誘導されたのか、検索結果から偽サイトに来たのかは関係ありません[1]。「気をつけていれば見抜けるはず」という前提に頼らない点が、コードの方式との一番の違いです。
手で打ち込むコードは、どのログイン操作のためのものかに結びついていません。だから偽サイトは、受け取ったコードを本物のサイトに中継するだけでログインできてしまいます[1]。偽のログイン画面に、ユーザー名とパスワード、さらに認証アプリのコードまで入力させる手口は、よく使われるフィッシングの例です[3]。
WebAuthnの鍵は、サイトのドメイン名と結びついています。サービスのドメイン名をもとに認証の秘密を選ぶ仕組みなので、正しく設定された鍵は、作られたドメインでしか使えません[1]。偽のページが答えを横取りして使い回すこともできません[1]。見た目がどれだけ本物そっくりでも、ドメインが違えば、本物のサイト向けの答えは出てきません。
公開鍵の仕組みも効いています。サービス側が持つのは、利用者の認証器に対応する公開鍵です[1]。NISTの最も高い保証レベルでは、サービス側が侵害されても認証の秘密を守れるよう、公開鍵暗号を使うことが要件になっています[1]。パスワードのように、ログインに使える答えそのものをサービス側に預けていません。そのため、サービスから公開鍵が漏れても、それだけではなりすましに使えません。
指紋や顔は「鍵を使う許可」を出している
パスキーでログインするとき、指紋や顔を求められることがあります。暗号鍵の方式では、指紋や顔は、端末の中にある鍵を使う許可を出すために使われます。この場合、「持っているもの」にあたるのは認証器自体です[1]。生体の照合は、サーバーで行うより端末の中で行う方が望ましいとされています[1]。PINで解除する場合も、そのPINは認証器と端末の中にとどまります[1]。
この仕組みから、パスワードを使わないこと（パスワードレス）と多要素であることが両立する条件が分かります。鍵を持っていることに加えて、ログインのたびに端末でPINや生体による本人確認が行われていれば、多要素になります[1]。
ただし、すべてのパスキーが常に多要素というわけではありません。認証のたびに、本人確認をしたかどうかを示す目印が付きます。本人確認が行われなかった場合、その認証は単要素として扱われます。NISTは、この目印を確認するようサービス側に求めています[1]。パスキーという名前だけで、多要素だと決めつけない方がいいと思います。
同期型のパスキーには、別の注意点もあります。鍵がクラウドを通じてほかの端末に複製されるので、クラウド側のアカウント復旧手続きが潜在的な弱点になります。そのため、同期の基盤にある鍵へのアクセスには、多要素認証相当の保護が求められています[1]。パスキーを同期しているなら、同期に使っているクラウドのアカウントも、同じように守りを固めておく必要があります。
MFAでも破られる場面
弱点を知っておくと、方式の選び方や設定の見直しに役立ちます。
- リアルタイムの中継：攻撃者が利用者と正規サイトの間に入り、入力されたパスワードとコードを、その場で正規サイトに送る攻撃です。一般にAiTM（Adversary-in-the-Middle）と呼ばれます。コードの方式はログイン操作に結びついていないので、この中継を防げません[1][3]。対策は、フィッシング耐性のある方式を使うことです[1]。
- MFA疲労（通知の連打）：承認の通知を何度も送り、うっとうしさから承認させる攻撃です[1][3]。番号照合が対策になります[1][3]。
- SIMスワップ：携帯電話会社をだまして電話番号を攻撃者のSIMに移させ、SMSのコードを受け取る手口です[1][3]。
- ログイン後の乗っ取りとマルウェア：MFAが働くのはログインの時点です。ログインが済むと、ブラウザやアプリはクッキーなどのセッションの秘密を持って、ログイン状態を続けます[1]。このセッションを乗っ取られたり、セッションの秘密を盗み出されたりする危険があります[1]。盗まれると、攻撃者はMFAを通らずにログイン状態を使えるおそれがあります。アクセストークンも、認証のセッションが終わったあと長く有効なことがあります[1]。端末の悪意のあるコードに、認証器を勝手に使われる危険もあります[1]。
- 復旧と代替手段：多くの認証の仕組みで弱いのは、認証器をなくした人がそれを置き換える手続きです[1]。費用の都合から、安価で安全性の低い予備の方法が使われがちです。人が対応する復旧には、ソーシャルエンジニアリングの危険もあります[1]。このことから考えると、パスキーを登録しても、弱いSMSなどの代替手段や古い経路が残っていれば、攻撃者はそちらを狙えると見ておくのが自然です。
- だまされて自分から渡してしまう場合：利用者がだまされて秘密を伝えてしまうソーシャルエンジニアリングも、認証への脅威に挙げられています[1]。たとえば、電話で「確認のためにコードを教えて」と言われて読み上げてしまえば、コードの方式ではMFAでも止められません。
それと、MFAはソフトウェアの更新や権限の設計、バックアップの代わりにはなりません。MFAが減らすのは、盗まれた認証情報でログインされる危険です。ほかの対策とは役割が違うだけで、この危険に対する効果は大きいと思っています。
どのアカウントから、どの方式で設定するか
優先したいのは、乗っ取られたときの被害が大きく、ほかのアカウントの入口にもなるアカウントです。
- メール：多くのサービスで、パスワードの再設定や復旧の連絡はメールに届きます。復旧用コードの送り先になることもあります[1]。CISAも、メールを含むすべてのサービスでMFAを使うよう、組織に強く勧めています[3]。
- 金融：金融口座へのアクセスも、MFAを使うべき例に挙げられています[3]。
- クラウドや管理者のアカウント：攻撃者は、メールシステムやファイルサーバー、IDを管理するサーバーを狙います。システム管理者のアカウントが乗っ取られれば、組織のあらゆるシステムとデータに手が届き得ます[3]。また、2022年時点の資料では、ホスト型のメールやシングルサインオンの多くがFIDOに対応しているとして、最初に取り組む対象に向いているとされていました[3]。
方式は、次の順で考えると迷いにくいと思います。
- パスキーや物理的なセキュリティキーなど、フィッシング耐性のある方式が選べるなら、それを使う。CISAは、これをMFAの「ゴールドスタンダード」と呼んでいます[3]。
- 選べなければ、認証アプリのコードか、番号照合つきのプッシュ通知を使う。フィッシング耐性のある方式をすぐには導入できない中小企業にとって、これらが最善の選択肢とされています[3]。
- SMSしか選べないなら、SMSで有効にしておく。強い方式が使えるようになったら切り替える。
3番目には条件があります。CISAの考え方では、どんな形のMFAでもMFAなしよりはよく、SMSも、より強い方式へ移るまでの一時的な手段になり得ます[3]。ただ、この資料は組織のIT担当者やネットワークを守る人に向けたもので[3]、個人のアカウント向けの指示ではありません。それでも、パスワードだけを手に入れた攻撃者をMFAが止めるという理屈は、個人のアカウントでも変わりません。流出や使い回し、スプレーで手に入れたパスワードは、2つ目の確認の前で役に立たなくなります。SMSに弱点があるからといって、MFAそのものを先送りしない方がいいと思います。
設定したら確認しておきたいこと
- 普段使う方法とは別に予備も登録して、認証の手段を合わせて2つ以上にしておく。復旧が必要になる事態を減らすため、別々の認証手段を少なくとも2つ持つよう利用者に勧めることが、サービス側に推奨されています[1]。
- バックアップコードは印刷するか書き留めて、オフラインで安全に保管する。保存型の復旧コードは、そういう保管を想定しています[1]。スマホのメモやメールに置くと、そのスマホやメールを乗っ取られたときに、一緒に奪われるおそれがあります。
- 自分がログインしていないときに届いた承認通知は、押さずに拒否する。通知を連打して承認させる攻撃があるからです[1][3]。通知にはアクセス先のサービス名などを含めるべきとされているので[1]、表示されていればそこも確認できます。覚えのない通知が届くのは、パスワードがすでに知られているサインかもしれません。念のため、パスワードも変えておくと安心です。
- 「認証手段が追加されました」のような通知が来たら、身に覚えがあるか確かめる。この通知は、不正に気づくための仕組みです[1]。
- ログインは、メールやSMSのリンクからではなく、ブックマークや公式アプリから行う。コードの方式のままでも、偽サイトに入力してしまう機会を減らせます。
- スマホやパソコンのOSを更新しておく。端末にマルウェアがないことが、安全の前提になるからです[1]。盗難に備えて、画面ロックもかけておきたいところです。
- 使わなくなった電話番号や、パスキーを登録したあとも残っているSMSなどの代替手段を見直す。
どの方式が選べるかは、サービスごとに違います。まずはメールのアカウントの設定画面を開いて、いま何が登録されているかを見るところから始めれば十分だと思います。
