先に読むと理解しやすい記事:認証・認可 / 共通鍵暗号・公開鍵暗号
種類の違う認証要素を組み合わせる
多要素認証は、知っているもの、持っているもの、身体の特徴など、異なる種類の要素を組み合わせる方式です。MFAはMulti-Factor Authenticationの略です。パスワードと認証アプリのコードなどを使います。
パスワードと秘密の質問は、どちらも知っている情報です。入力画面が二つあるだけでは多要素になりません。パスワードだけが漏れても、別の要素を持たない攻撃者のログインを止めることが狙いです。
参照:出典 s1
SMSと認証アプリではコードの作り方が違う
SMSでは、サービスが一時コードを登録電話番号へ送ります。登録された番号で受信できることを確認します。ただし、番号の乗っ取りや、偽サイトが入力コードを中継する攻撃には注意が必要です。
TOTP方式の認証アプリは、登録時にサービスと共有した秘密と現在時刻からコードを計算します。サーバーも同じ条件で検証します。登録用QRコードは共有秘密を含み得るため公開しません。短時間だけ有効なコードでも、即座に中継されると盗用され得ます。
参照:出典 s1
パスキーはサイトに結び付いた鍵で応答する
パスキーは公開鍵暗号に基づくログイン用の資格情報です。登録時に作る公開鍵をサービスへ渡し、秘密鍵は端末や資格情報を管理する仕組みで保護します。ログインのたびにパスワードを送る方式とは異なります。
サービスは今回のログイン用に作ったチャレンジというランダムな値を送ります。認証器が応答へ署名し、サービスが公開鍵で検証します。チャレンジやサイト情報を確認するため、過去の署名のコピーだけでは新しいログインを証明できません。
- 登録時に認証器が鍵を作り、サービスが公開鍵を保存
- ログイン時にサービスが新しいチャレンジを送信
- 利用者がPINや生体認証などで端末上の確認を実施
- 認証器が署名した応答を返す
- サービスがチャレンジ・サイト情報・署名を検証
参照:出典 s2
偽サイトに本物のサイト用の証明を渡さない
WebAuthnというブラウザの認証機能は、資格情報をサービスのドメインなどに結び付けます。別ドメインの偽サイトが、本物用のパスキーで自由に署名させることを防ぎます。サーバー側でもオリジンなどを検証します。
指紋や顔を使う構成では、端末内で鍵の利用を許す確認に使います。サービスへ指紋画像を送るという意味ではありません。利用者の検証を必須にするか、鍵を端末に固定するか同期するかなど、設定によって得られる保証も変わります。
参照:出典 s2
復旧手段も認証の一部として設計する
復旧をメール一通だけで無条件に許可すると、攻撃者はパスキーなどでの認証をせずに、復旧手段からアカウントを使える状態にできるおそれがあります。復旧コード、複数の認証器、認証要素の変更時の再認証と通知などを設計します。
同期型のパスキーは複数端末で使える一方、同期サービスのアカウントの保護と復旧も重要です。端末だけに保持する方式では、紛失時に別の認証手段を確保できるか確認します。
ログイン後のセッションも守る
確認問題:多要素認証があればセッションIDの盗難も無害でしょうか。答えは限りません。ログイン後のIDを持つ相手を受け入れる設計なら、そのIDで被害者として操作されるおそれがあります。
セッションの保護、期限、重要操作前の再認証、紛失時の失効を整えます。身に覚えのないプッシュ通知を何度も承認させる攻撃もあるため、対象の操作が分かる表示や試行制限を用意します。
参照:出典 s1
出典・確認範囲
- [s1] Multifactor Authentication Cheat SheetOWASP / 確認日 2026-11-03
- [s2] Web Authentication: An API for accessing Public Key Credentials — Level 3W3C / 確認日 2026-11-03
通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。