多要素認証

Multifactor Authentication Cheat Sheet

原典: Multifactor Authentication Cheat Sheet（OWASP Cheat Sheet Series）
原文: GitHub 上の Markdown
底本: bac04fb5（2026-07-29 時点）
ライセンス: CC BY-SA 4.0（原典と同一。訳文も同ライセンスで再配布できます）

はじめに

多要素認証（MFA）または二要素認証（2FA）は、システムで認証を受けるために利用者が二種類以上の証拠の提示を求められる仕組みである。証拠（要素）には五つの種類があり、その任意の組み合わせを使えるが、実際には Web アプリケーションで一般的なのは最初の三つだけである。五種類は次のとおりである。

要素	例
知っていること	パスワードと PIN、秘密の質問
持っているもの	OTP トークン、U2F トークン、証明書、スマートカード、メール、SMS と電話
そのもの	指紋、顔認識、虹彩の走査
いる場所	送信元 IP アドレス、地理的位置、ジオフェンス
行うこと	行動プロファイリング、打鍵とマウスの動態、歩容の分析

同じ認証要素を複数回求めること（パスワードと PIN の両方を求めるなど）は MFA にあたらず、追加の安全性はほとんど得られないことに注意する。使う要素は互いに独立であるべきであり、同じ攻撃で侵害されないものであるべきである。以下の各節では各種の MFA の難点と弱点を論じるが、多くの場合それらは標的型の攻撃に対してのみ関係する。 どのような MFA であっても、MFA がないよりはよい。

利点

アプリケーションで利用者のアカウントが侵害される最も一般的な経路は、弱い、再利用された、あるいは盗まれたパスワードである。アプリケーションにどのような技術的な安全対策を実装しても、利用者は弱いパスワードを選びがちであり、異なるアプリケーションで同じパスワードを使いがちである。開発者やシステム管理者は、利用者のパスワードがいずれかの時点で侵害されると想定し、それに対して防御できるようシステムを設計するべきである。

MFA は、総当たり、クレデンシャルスタッフィング、パスワードスプレーを含むパスワードに関する攻撃の大半に対して、はるかに最良の防御である。 Microsoft の分析によれば、アカウント侵害の 99.9% を止められたとされる。

難点

MFA の最大の難点は、管理者とエンドユーザーの双方にとって管理の複雑さが増すことである。技術に詳しくない利用者の多くは、MFA の設定と利用を難しく感じうる。加えて、よく直面する問題がいくつもある。

利用者に特定のハードウェアを必要とする種類の MFA は、大きな費用と運用の手間をもたらしうる。
他の要素を失うか使えなくなった利用者が、アカウントから締め出されうる。
MFA はアプリケーションに追加の複雑さを持ち込む。
多くの MFA の仕組みはシステムに外部への依存を加え、それが脆弱性や単一障害点を持ち込みうる。
利用者が MFA を回避または再設定できるようにするために実装した手続きが、攻撃者に悪用されうる。
MFA を必須にすることで、一部の利用者がアプリケーションを使えなくなりうる。

手早い推奨

アプリケーションで MFA をいつどのように実装するかは、そのアプリケーションの脅威モデル、利用者の技術水準、利用者に対する管理上の統制の程度など、さまざまな要素によって変わる。これらはアプリケーションごとに検討する必要がある。

ただし次の推奨はほとんどのアプリケーションに一般に適しており、検討の出発点になる。

すべての利用者に何らかの形の MFA を必須にする。
利用者が TOTP を用いて自分のアカウントで MFA を有効にできる選択肢を与える。
管理者やその他の高い権限を持つ利用者には MFA を必須にする。
利用者が MFA を再設定できる安全な手続きを実装する。
MFA をサービスとして利用することを検討する。

MFA の実装

MFA は決定的に重要な安全対策であり、すべてのアプリケーションで推奨される。以下の節は MFA の実装方法と、考慮すべき点についての指針を示す。

規制と法令遵守の要件

多くの業界と国が MFA の使用を要求する規制を持つ。これはとくに金融と医療の分野で一般的であり、欧州連合の一般データ保護規則（GDPR）に準拠するためにしばしば要求される。 MFA を実装するときは、これらの要件を考慮することが重要である。

いつ MFA を必須にするか

アプリケーションで MFA を必須にする最も重要な箇所は、利用者がログインするときである。ただし利用できる機能に応じて、次のような機微な動作に対して MFA を必須にすることも適切でありうる。

パスワードや秘密の質問の変更
アカウントに紐づくメールアドレスの変更
MFA の無効化
利用者のセッションを管理者のセッションへ昇格させること

アプリケーションが複数の認証手段を提供している場合、そのすべてで MFA を必須にするか、他の保護を実装するべきである。見落とされやすいのは、アプリケーションがログインに使える別の API を提供している場合や、関連するモバイルアプリケーションを持つ場合である。

ワンタイムパスワード（OTP）の扱いと保存

OTP は認証のシークレットであり、パスワードと同様の衛生をもって扱うべきである。その安全性の特性は長期間有効なパスワードとは異なるが、扱いが不適切であれば利用者のアカウントの侵害につながりうる。

OTP の実装は、少なくとも次を行うべきである。

短い有効期間（TTL）を強制する
OTP が一度しか使えない状態にする
試行回数の厳しい上限を適用する
検証が成功した時点で OTP を無効にする

OTP の実装は次を行うべきではない。

OTP の値を記録する
OTP を長期間平文の形で保存する

リスクをさらに下げ、露出を限定するために、次が推奨される。

暗号論的に安全な乱数生成器を用いて OTP を生成する
使いやすさが許すなら 8 桁以上のコードを検討する
「再送」の際は新しい OTP を生成し、古い記録を上書きする

OTP のハッシュ化

OTP のハッシュ化はなお推奨されるが、その理由はパスワードのハッシュ化とは異なる。 OTP は通常、鍵空間が非常に小さい（6 桁のコードなら約 100 万通り）。これはデータベースを入手した攻撃者が、どの OTP のハッシュも短時間で総当たりできることを意味する。

そのため OTP のハッシュ化は、パスワードのハッシュ化のような形での、オフライン攻撃に対する強い耐性を与えない。

しかしハッシュ化には次の点でなお有用である。

ログ、計測値、デバッグの道具を通じた偶発的な露出を防ぐ
OTP の有効期間中にデータベースが短時間露出した場合の影響範囲を狭める
シークレットを扱う良い規律を強制し、既定で平文の保存を避ける

目的は短期の露出に対する保護であり、長期の暗号的な秘匿ではない。

利用者体験の改善

リスクに基づく認証

MFA で頻繁にログインしなければならないことは利用者に追加の負担をかけ、アプリケーションで MFA を無効にする動機になりうる。リスクに基づく認証を使えば、高リスクとみなされる動作を行うときにのみ MFA を求めることで、MFA の要求の頻度を下げられる。その例を挙げる。

利用者が新しい端末や場所からログインするときに MFA を求める。
利用者が高リスクとみなされる場所からログインするときに MFA を求める。
企業の IP 範囲を許可する（あるいは地理的位置を追加の要素として使う）。

パスキー

FIDO2 の標準に基づくパスキーは、持っているものによる認証と、知っていることまたはそのものによる認証の性質を組み合わせた新しい形の MFA である。利用者は物理的な機器（携帯電話など）を持ち、認証のために PIN を入力するか生体認証を使う必要がある。そのうえで利用者の機器が、サーバーとの認証に使う暗号鍵を生成する。これは非常に安全な形の MFA であり、フィッシング攻撃に耐えながら利用者にとって負担が少ない。

ログインの失敗した試行

利用者がパスワードを入力したものの第二要素での認証に失敗した場合、それは次の二つのいずれかを意味しうる。

利用者が第二要素を失った、あるいは手元にない（携帯電話を持っていない、電波がないなど）。
利用者のパスワードが侵害された。

これが起きたときに採るべき手順はいくつもある。

別の形の MFA を試すよう利用者に促す。
利用者が MFA の再設定を試せるようにする。
ログインの失敗した試行を利用者に通知し、心当たりがなければパスワードを変えるよう促す。
- 通知には、そのログイン試行の時刻、ブラウザ、地理的位置を含めるべきである。
- これは次回のログイン時に表示し、任意でメールでも送るべきである。

MFA の再設定

MFA の実装における最大の課題の一つは、追加の要素を忘れたり失ったりした利用者への対応である。これは次のような多くの形で起こりうる。

デジタル証明書をバックアップせずにワークステーションを再インストールした。
OTP のコードをバックアップせずに携帯電話を初期化した、あるいは失った。
携帯電話の番号を変えた。

利用者がアプリケーションから締め出されることを防ぐため、既存の MFA が使えない場合にアカウントへのアクセスを取り戻す仕組みが必要である。しかしそれが攻撃者に MFA を回避してアカウントを奪う手段を与えないことも決定的に重要である。

これに決定的な「最良の方法」はなく、何が適切かはアプリケーションの安全性の要求と、利用者に対する統制の程度によって大きく変わる。職員が互いを知っている企業のアプリケーションで機能する解決策は、世界中に何千人もの利用者がいる公開のアプリケーションでは実現できない可能性が高い。どの復旧の方法にも独自の利点と難点があり、それをアプリケーションの文脈で評価する必要がある。

ありうる方法をいくつか挙げる。

利用者が最初に MFA を設定するときに、一度だけ使える復旧コードを複数与える。
複数の種類の MFA（デジタル証明書、OTP の種、SMS 用の電話番号など）の設定を利用者に求め、それらすべてへのアクセスを同時に失う可能性を低くする。
一度だけ使える復旧コード（または新しいハードウェアトークン）を、利用者の登録住所へ郵送する。
利用者にサポート担当への連絡を求め、その身元を検証する厳格な手続きを整えておく。
別の信頼された利用者による保証を求める。

MFA の要素の変更

利用者は、電話番号の変更、新しい認証アプリへの移行、失ったハードウェアトークンの交換など、認証の要素を更新する必要が生じうる。攻撃者はこの処理を悪用してアカウントを奪えるので、厳格に保護しなければならない。

最良の慣行を挙げる。

変更を許す前に、既に登録済みの要素による再認証を求める。
有効なセッションのみに依存しない。それは奪われている可能性がある。
要素の交換を高リスクの動作として扱い、リスクに基づく確認（新しい端末、通常と異なる場所など）を適用する。
MFA の要素が変更されたときは常に、帯域外の経路（メールやプッシュ通知など）で利用者へ通知する。
価値の高いアカウントには、遅延の導入や段階的な検証の適用を検討する。

これにより、セッションが侵害されても、攻撃者が利用者の MFA の要素を黙って置き換えて正当な利用者を締め出すことはできなくなる。

サードパーティのサービスの利用を検討する

MFA をサービスとして提供するサードパーティのサービスはいくつもある。自前で MFA を実装する資源のないアプリケーションや、MFA に高い確度を要求するアプリケーションにとって、これは良い選択肢になりうる。ただしそのサードパーティのサービスの安全性と、それを使うことの帰結を検討することが重要である。たとえばそのサービスが侵害されれば、それを使うすべてのアプリケーションで攻撃者が MFA を回避できてしまう。

知っていること

知識に基づくもの、すなわち最も一般的な認証の種類は、利用者が知っていること（通常はパスワード）に基づく。この要素の最大の利点は、開発者にもエンドユーザーにも要求が非常に少ないことである。特別なハードウェアも、他のサービスとの統合も必要としない。

パスワードと PIN

パスワードと PIN は、実装の単純さゆえに最も一般的な認証の形である。強固なパスワードの方針の実装については認証に、パスワードの安全な保存についてはパスワードの保存に指針がある。ほとんどの多要素認証の仕組みは、パスワードと、少なくとも他の一つの要素を使う。

利点

単純でよく理解されている。
あらゆる認証の枠組みが標準で対応している。
実装が容易である。

難点

利用者は弱いパスワードを選びがちである。
パスワードはシステム間で再利用されることが多い。
フィッシングを受けやすい。

秘密の質問

NIST SP 800-63 によれば、秘密の質問はもはや許容される認証要素として認められていない。 アカウントの復旧は認証の別経路にすぎないので、通常の認証より弱くあってはならない。

利点

パスワードにも存在しないような利点はない。

難点

もはや許容される認証要素として認められていない。
質問の答えは推測しやすいことが多い。
質問への答えは、ソーシャルメディアやその他の情報源から得られることが多い。
利用者が何年後にも答えを覚えているよう、質問は注意深く選ばなければならない。
フィッシングを受けやすい。

持っているもの

所持に基づく認証は、認証に必要な物理的またはデジタルの品を利用者が持つことに基づく。これは最も一般的な形の MFA であり、しばしばパスワードと併用される。所持に基づく認証で最も一般的な種類は、ハードウェアトークンとソフトウェアトークン、そしてデジタル証明書である。適切に実装されれば、リモートの攻撃者が侵害することは著しく難しくなる。しかし利用者には追加の負担が生じる。使いたいときには常にその認証要素を携えていなければならない。

ワンタイムパスワードのトークン

ワンタイムパスワード（OTP）のトークンは所持に基づく認証の一形態であり、認証のために絶えず変化する数字のコードを利用者が入力する必要がある。最も一般的なのは時刻に基づくワンタイムパスワード（TOTP）のトークンであり、ハードウェアとソフトウェアの両方がある。

ハードウェアの OTP トークン

ハードウェアの OTP トークンは絶えず変化する数字のコードを生成し、認証時にそれを入力しなければならない。最もよく知られたものは RSA SecurID であり、60 秒ごとに変わる 6 桁の数字を生成する。

利点

トークンが独立した物理的な機器なので、攻撃者がリモートから侵害することはほぼ不可能である。
利用者が携帯電話やその他の機器を持つことを必要とせずに使える。

難点

物理的なトークンを利用者へ配ることは費用がかかり煩雑である。
利用者がトークンを失った場合、新しいものを購入して発送するのに相当の時間がかかりうる。
実装によってはバックエンドのサーバーを必要とし、それが新しい脆弱性と単一障害点を持ち込みうる。
盗まれたトークンは、PIN や機器の解除コードなしに使えてしまう。
フィッシングを受けやすい（ただし有効時間は短い）。

ソフトウェアの OTP トークン

ハードウェアトークンより安価で容易な代替は、ソフトウェアで時刻に基づくワンタイムパスワード（TOTP）のコードを生成することである。通常、利用者が携帯電話に TOTP のアプリケーションを導入し、Web アプリケーションが提示する QR コード（初期の種を与える）を読み取る形になる。その認証アプリは、ハードウェアトークンとほぼ同じように 60 秒ごとに 6 桁の数字を生成する。

ほとんどのサイトは標準化された TOTP のトークンを使い、利用者は TOTP に対応する任意の認証アプリを導入できる。しかし少数のアプリケーションは独自の変種を使っており（Symantec など）、そのサービスを使うには特定のアプリの導入が必要になる。標準に基づく方法を選び、これは避けるべきである。

利点

物理的なトークンがないので、この仕組みを実装する費用と運用の手間が大きく減る。
利用者が TOTP のアプリへのアクセスを失っても、物理的なトークンを発送せずに新しいものを設定できる。
TOTP は広く使われており、多くの利用者はすでに TOTP のアプリを少なくとも一つ導入している。
利用者が携帯電話に画面ロックをかけていれば、攻撃者がその電話を盗んでもコードを使えない。

難点

TOTP のアプリは通常モバイル端末に導入され、その端末は侵害されうる。
TOTP のアプリが、認証に使う同じモバイル端末（またはワークステーション）に導入されていることがある。
利用者がバックアップの種を安全でない形で保存しうる。
すべての利用者が TOTP に使えるモバイル端末を持つわけではない。
利用者のモバイル端末が失われた、盗まれた、あるいは電池が切れた場合、認証できなくなる。
フィッシングを受けやすい（ただし有効時間は短い）。

Universal Second Factor

ハードウェアの U2F トークン。

Universal Second Factor（U2F）は、USB や NFC のハードウェアトークンの標準であり、利用者が手作業でコードを入力するのではなく、チャレンジとレスポンスに基づく認証を実装する。通常、利用者はトークンのボタンを押すか、NFC の読み取り機にかざす。最も一般的な U2F のトークンは YubiKey である。

利点

秘密鍵がトークンから出ないので、U2F のトークンはフィッシングに耐性がある。
利用者はコードを打つのではなく、ボタンを押すだけでよい。
トークンが独立した物理的な機器なので、攻撃者がリモートから侵害することはほぼ不可能である。
U2F は主要なブラウザのいくつかが標準で対応している。
利用者が携帯電話やその他の機器を持つことを必要とせずに使える。

難点

ハードウェアの OTP トークンと同じく、物理的なトークンの使用は大きな費用と運用の手間をもたらす。
盗まれたトークンは、PIN や機器の解除コードなしに使えてしまう。
トークンは通常 USB でワークステーションに接続されるので、利用者が忘れやすい。

証明書

デジタル証明書は利用者の機器に保存されるファイルであり、認証の際に利用者のパスワードとともに自動的に提示される。最も一般的な種類は X.509 の証明書であり、クライアント証明書としてよく知られる。証明書は主要なすべてのブラウザが対応しており、いったん導入すれば利用者側の操作は不要になる。利用者が他のアカウントに対して認証を試みることを防ぐため、証明書は個々の利用者アカウントに結びつけるべきである。

利点

ハードウェアトークンを購入し管理する必要がない。
いったん導入すれば、利用者にとって非常に簡単である。
証明書は集中管理と失効ができる。
フィッシングに耐性がある。

難点

デジタル証明書の使用には、バックエンドの公開鍵基盤（PKI）が必要である。
とくに制限の厳しい環境では、証明書の導入が利用者にとって難しいことがある。
SSL の復号を行う企業のプロキシサーバーは、証明書の使用を妨げる。
証明書は利用者のワークステーションに保存されるので、その機器が侵害されれば盗まれうる。

スマートカード

スマートカードはクレジットカード大のカードであり、利用者のデジタル証明書を含むチップを持ち、PIN で解除される。 OS の認証によく使われるが、Web アプリケーションで使われることは稀である。

利点

盗まれたスマートカードは PIN なしには使えない。
スマートカードは複数のアプリケーションとシステムで使える。
フィッシングに耐性がある。

難点

スマートカードの管理と配布には、ハードウェアトークンと同じ費用と手間がかかる。
現代のブラウザはスマートカードに標準で対応していないので、サードパーティのソフトウェアが必要になる。
業務用のノート PC のほとんどはスマートカードの読み取り機を内蔵しているが、家庭のシステムはそうでないことが多い。
スマートカードの使用にはバックエンドの PKI が必要である。

SMS と電話

警告 NIST SP 800-63B-4 は、SS7 の傍受、SIM の入れ替え、番号の移転による攻撃のため、SMS と公衆電話網で配信されるコードを制限された認証手段に位置づけている。価値の高いアプリケーションや個人情報を扱うアプリケーションに SMS を使わない。これが唯一使える要素である場合は、リスクの受容を文書化し、アカウントごとの流量の上限を強制し、SIM の入れ替えの兆候を監視し、TOTP、プッシュ通知、WebAuthn／FIDO2 への移行を計画する。

SMS や電話を使って、追加の要素として入力する一度だけ使えるコードを利用者へ渡せる。これらの方法が抱えるリスクのため、個人を特定できる情報（PII）を保持するアプリケーションや、金銭的なリスクがあるアプリケーション（医療や銀行など）の保護には使うべきではない。 NIST SP 800-63B はこれらを制限された認証手段に分類し、PII を含むアプリケーションでの使用を推奨していない。

利点

実装が比較的単純である。
利用者にアカウントと携帯電話番号の紐づけを求める。

難点

利用者がモバイル端末または固定電話を持つ必要がある。
電話やメッセージを受け取るために、利用者が電波かインターネットのアクセスを持つ必要がある。
電話や SMS の送信には費用がかかりうるので、攻撃者が大量のメッセージを要求して資金を枯渇させることに対する保護が必要である。
SIM の入れ替え攻撃を受けやすい。
SMS が、利用者が認証している同じ端末で受信されることがある。
フィッシングを受けやすい。
端末がロックされていても SMS のプレビューが表示されることがある。
SMS が悪意ある、あるいは安全でないアプリケーションによって読まれうる。

メール

メールによる確認は、利用者がメールアドレスへ送られたコードを入力するか、リンクをクリックすることを求める。メールが MFA の一形態にあたるかについては議論がある。利用者がメールのアカウントで MFA を設定していなければ、それは単に利用者のメールのパスワード（アプリケーションのパスワードと同じであることが多い）を知っていることを求めるにすぎないからである。ただし網羅性のためにここに含める。

利点

実装が非常に容易である。
別のハードウェアやモバイル端末を必要としない。

難点

メールのアカウントの安全性に完全に依存するが、そこには MFA がないことが多い。
メールのパスワードはアプリケーションのパスワードと同じであることが多い。
利用者のメールが先に侵害されている場合は何の保護も与えない。
メールが、利用者が認証している同じ端末で受信されることがある。
フィッシングを受けやすい。

そのもの

生来の性質に基づく認証は、利用者の身体的な属性に基づく。利用者に特定のハードウェアを必要とするため Web アプリケーションではあまり一般的でなく、プライバシーの面では最も侵襲的とみなされることが多い。ただし OS の認証にはよく使われ、一部のモバイルアプリケーションでも使われる。

生体情報

よく使われる生体情報の種類はいくつもある。

指紋の走査
顔認識
虹彩の走査
声の認識

利点

よく実装された生体情報は偽装が難しく、標的型の攻撃を要する。
利用者にとって速く便利である。

難点

利用者に手作業での登録が必要である。
生体情報を読み取るために、独自の（時に高価な）ハードウェアがしばしば必要になる。
プライバシーの懸念。利用者についての機微な身体情報を保存しなければならない。
侵害された場合、生体情報のデータは変更が難しいことがある。
ハードウェアが追加の攻撃経路に脆弱でありうる。

いる場所

場所に基づく認証は、利用者の物理的な位置に基づく。（前述のように）MFA を要求するかどうかの判断に位置が使われる、という言い方をされることもあるが、それは実質的に位置をそれ自体一つの要素とみなすことと同じである。その顕著な例は、Microsoft Azure で使える条件付きアクセスのポリシーと、BitLocker の Network Unlock の機能である。

送信元 IP アドレス

利用者が接続してくる送信元 IP アドレスを要素として使える。通常は許可リストに基づく方法である。静的な一覧（企業の事務所の範囲など）に基づく場合も、動的な一覧（その利用者が過去に認証した IP アドレスなど）に基づく場合もある。

利点

利用者にとって非常に簡単である。
管理担当者による設定と管理が最小限で済む。

難点

利用者の機器が侵害されている場合は何の保護も与えない。
内部の不正な者に対して何の保護も与えない。
信頼する IP アドレスは注意深く限定しなければならない（たとえば公開の来客用 Wi-Fi が企業の主要な IP 範囲を使っている場合など）。

地理的位置

利用者の正確な IP アドレスを使うのではなく、その IP アドレスが登録されている地理的な位置を使える。精度は落ちるが、IP アドレスが静的でない環境では実装しやすいことがある。よくある使い方は、利用者の通常の国以外から認証が試みられたときに追加の認証要素を求めることである。

利点

利用者にとって非常に簡単である。

難点

利用者の機器が侵害されている場合は何の保護も与えない。
内部の不正な者に対して何の保護も与えない。
信頼された国や場所の IP アドレスを得れば、攻撃者は容易に回避できる。
Apple の iCloud プライベートリレーや VPN のようなプライバシー機能によって精度が下がりうる。

ジオフェンス

ジオフェンスは地理的位置のより精密な版であり、認証を許す特定の領域を定義できる。これはモバイルアプリケーションでよく使われる。 GPS のような測位のハードウェアを用いて利用者の位置を高い精度で判定できるからである。

利点

利用者にとって非常に簡単である。
リモートの攻撃者に対して高い水準の保護を与える。

難点

利用者の機器が侵害されている場合は何の保護も与えない。
内部の不正な者に対して何の保護も与えない。
信頼された場所の物理的に近くにいる攻撃者に対して何の保護も与えない。

行うこと

振る舞いに基づく認証は、打鍵の仕方、マウスの動かし方、モバイル端末の使い方といった利用者の振る舞いに基づく。これは最も一般的でない形の MFA であり、利用者の身元に対する確度を高めるために他の要素と組み合わせられる。また実装が最も難しく、利用者の振る舞いを分析するために特定のハードウェアと、大量のデータおよび処理能力を必要としうる。

行動プロファイリング

行動プロファイリングは、ログインする時刻、使う端末、アプリケーション内の移動の仕方といった、利用者のアプリケーションとの関わり方に基づく。これはリスクに基づく認証と利用者および実体の行動分析（UEBA）のシステムと組み合わせられる形で、Web アプリケーションで急速に一般化している。

利点

利用者の操作を必要としない。
利用者を継続的に認証するのに使える。
利用者の身元に対する確度を高めるため、他の要素とよく組み合わせられる。

難点

行動プロファイリングの初期の実装はしばしば不正確で、相当な数の誤検知を引き起こした。
利用者の振る舞いを分析するために大量のデータと処理能力を必要とする。
利用者の振る舞いが頻繁に変わりうる環境では、実装が難しいことがある。

打鍵とマウスの動態

打鍵とマウスの動態は、利用者の打鍵の仕方とマウスの動かし方に基づく。たとえばキーを押す間隔、キーを押してから離すまでの時間、マウスの速度と加速である。おおむね理論的なものであり、実際には広く使われていない。

利点

追加のハードウェアを必要とせずに使える。
利用者の追加の操作を必要とせずに使える。
利用者を継続的に認証するのに使える。
そのシステムを使っているのが本人でないことを検知するのに使える。
利用者が強要されている状況を検知するのに使える。
利用者がそのシステムを使える状態にないことを検知するのに使える。

難点

単独の要素として使えるほど正確である可能性は低い。
AI やその他の高度な攻撃によって偽装されうる。

歩容の分析

歩容の分析は、カメラとセンサーを用いた利用者の歩き方に基づく。物理的な安全対策のシステムでよく使われるが、Web アプリケーションでは広く使われていない。モバイル端末のアプリケーションは加速度センサーで利用者の歩容を検知し、それを追加の要素として使えるかもしれないが、これはなお概ね理論的である。

利点

偽装が非常に難しい。
利用者の追加の操作を必要とせずに使えることがある。

難点

実装に特定のハードウェアを必要とする。
物理的な安全対策のシステム以外での使用は、広く検証されていない。

適応的認証、リスクに基づく認証

適応的認証（リスクに基づく認証）は、ログイン試行の文脈に基づいて認証の要件を動的に調整する。この手法は、リスクが高まったときにのみ追加の検証の段階を適用することで、安全性を強めながら利用者体験を改善する助けになる。

リスクの判定に使われる一般的な信号を挙げる。

地理的位置と IP の評判
端末のフィンガープリント
アクセスの時刻（午前 3 時のログインなど）
行動の生体的特徴（打鍵の速度やマウスの動きなど）
侵害が知られている資格情報

リスクが検知された場合、システムは次のことを行える。

追加の要素（OTP など）を求める
再認証を強制する
アクセスを拒否し、警報やアカウント保護の流れを発動させる

アカウントの復旧や疑わしい活動のような高リスクの事象のあとにいつ再認証を発動させるかについてさらに詳しくは、認証のチートシートのリスク事象のあとの再認証の節を参照する。

この方法は、使いやすさと安全性の釣り合いをとるために現代の認証の仕組みで広く使われている。ただし開発者は、リスクの信号が偽装できないこと、そして代替の仕組みが主要な MFA の方法より弱くないことを確かにしなければならない。

利用の例：利用者が通常の場所で信頼された端末からログインする場合、追加の要求は不要である。しかし Tor の出口ノードを使って新しい国からログインした場合、システムは SMS による検証を求めるか、さらなる検証までアカウントをロックする。