認証の失敗（Identification and Authentication Failures）とは？OWASP A07の脆弱性と対策を現場目線で解説

「ログインエラー率が急に上がっている」「同じIPから何百回もログイン試行されている」——こんなアラートを見て不安になった経験はないでしょうか。認証の実装は「とりあえず動いている」では不十分で、小さな設定ミスが攻撃者に突破口を与えます。

この記事では、OWASP Top 10の「A07: 認証の失敗（Identification and Authentication Failures）」について、攻撃者がどこを狙うのか、そして情シスが今日から実践できる具体的な防御手順を解説します。

認証の失敗（OWASP A07）とは？

「認証の失敗」は、ログイン機能・セッション管理・認証情報の保存に関する実装上の不備を総称したカテゴリです。OWASPがWebアプリケーションのリスクをまとめた「OWASP Top 10」の2021年版で第7位（A07）に位置づけられています。

2017年版では「Broken Authentication（壊れた認証）」として第2位でしたが、2021年版で「Identification and Authentication Failures（識別と認証の失敗）」と名称を拡張し、単なるパスワード問題にとどまらず、「誰が操作しているか」を正しく検証できないすべての問題を対象に含めています。

このカテゴリに含まれる主な脆弱性は次のとおりです。

・アカウントロックアウトの欠如: 試行回数を制限しないため、ブルートフォース攻撃を許してしまう
・弱いパスワードポリシー: 単純なパスワードや使い回しを許容する実装になっている
・平文によるパスワード保存: DBが漏洩した際にパスワードが即座に判明する
・不適切なセッション管理: ログイン後にセッションIDを再生成しない、URLにセッションIDを含める
・ハードコードされた認証情報: ソースコードや設定ファイルにパスワードやAPIキーを直接記述している

なぜ今も深刻なのか — アカウントは攻撃者への最短ルート

セキュリティの世界では「IDとパスワードを奪えばシステムに正規ユーザーとして入れる」という事実があります。ファイアウォールや不正侵入検知システムを回避せずに済むため、攻撃者にとって認証突破は最も効率的なルートです。

認証の失敗が引き起こす典型的な被害は次のとおりです。

・アカウント乗っ取り（ATO）: 攻撃者が被害者として操作し、個人情報・業務データに自由にアクセスできる
・権限昇格への踏み台: 一般ユーザーアカウントを起点に権限昇格攻撃を試みる
・データ漏洩: 顧客データ・会計情報・知的財産への不正アクセスが発生する
・ランサムウェアの侵入経路: 正規アカウントで侵入してバックドアを設置される

アカウント乗っ取り（ATO）攻撃がどのように展開するかは、別記事で詳しく解説しています。

攻撃者が狙う認証の弱点4パターン

1. ブルートフォース攻撃・パスワードスプレー

ブルートフォース攻撃（総当たり攻撃）とは、パスワードの候補を機械的に試し続ける手法です。毎秒数千～数万回ものログイン試行を自動で行えるため、アカウントロックが設定されていないシステムでは時間の問題で突破されます。

パスワードスプレー攻撃はその亜種で、「1つのパスワードを多数のアカウントに試す」手法です。アカウントロック閾値を回避しながら、「password」「123456」「会社名+年号」のような弱いパスワードを使っているアカウントを効率的に探し出します。ブルートフォース攻撃の仕組みと対策の記事も合わせてご確認ください。

2. アカウントロック機能の欠如と不適切なエラーメッセージ

一定回数の認証失敗でアカウントをロックする機能がないシステムは、ブルートフォース攻撃の格好の標的です。また、「メールアドレスが存在しません」「パスワードが間違っています」と分けてメッセージを出すシステムは、攻撃者に「このメールアドレスは登録済み」という情報を与えてしまいます（ユーザー列挙攻撃）。

正しくは「メールアドレスまたはパスワードが正しくありません」のように、どちらが誤りかを明示しない汎用的なエラーメッセージを使うべきです。

3. セッション固定化（Session Fixation）

セッション固定化攻撃とは、攻撃者が事前に作成したセッションIDを被害者に使わせ、被害者がログインした後もそのセッションIDを使って「認証済みユーザーとして」操作できる状態を作る手法です。被害者は正常にログインしているのに、攻撃者も同じセッションで操作を行えます。

詳細な仕組みはセッション固定化攻撃の解説記事をご覧ください。防御の鍵は「ログイン成功後に必ずセッションIDを再生成する」ことです。

4. 予測可能なセッションIDと不適切なトークン管理

セッションIDが「時刻＋ユーザーID」の単純な組み合わせや連番になっているシステムは、攻撃者がセッションIDを推測できてしまいます。また、HTTPSを使わずにセッションIDをURLパラメータに含めると、参照元ヘッダー（Referer）やブラウザ履歴、プロキシログからセッションIDが漏洩します。

セッションIDは暗号論的に安全な乱数生成器（CSPRNG）で生成し、最低128ビット以上のエントロピーを確保する必要があります。

具体的な防御手順

1. パスワードポリシーとアカウントロックを設定する

まず、ログインエンドポイントへのリクエストをレート制限し、一定回数失敗したIPをブロックする仕組みを設けましょう。nginxを使っている場合、次のような設定が有効です。

# /etc/nginx/nginx.conf または site設定ファイル
# IPアドレス単位で1分あたり5リクエストを上限とするゾーン定義
http {
    limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;
}

server {
    # ログインエンドポイントに適用
    location /login {
        limit_req zone=login_zone burst=10 nodelay;
        limit_req_status 429;  # Too Many Requests を返す
    }
}

アプリケーション側でも、5回失敗したらIPまたはアカウント単位でロックし、指定時間後に自動解除する仕組みを実装します。ロック期間は「指数バックオフ（失敗するたびに待機時間を伸ばす）」が効果的です。

パスワードポリシーについては、長さ（最低12文字以上）を重視し、複雑さよりもパスフレーズの利用を推奨するのが現代の設計です（NIST SP 800-63B準拠）。「記号を1つ必ず含む」よりも「16文字以上のランダムな文字列」のほうが実際のエントロピーが高くなります。

2. 多要素認証（MFA）を全アカウントに導入する

パスワードが漏洩しても不正ログインを防げる多要素認証（MFA）は、認証の失敗対策の中で最も費用対効果が高い手段です。特に管理者アカウント・VPN・クラウドコンソールには必須と考えましょう。

注意点として、SMSによるワンタイムパスワードはSIMスワップ攻撃に脆弱なため、TOTP（Google Authenticatorなど）またはFIDO2/パスキーへの移行が推奨されます。パスキー（FIDO2）はフィッシングにも強い最新の認証手段です。

また、MFA導入後もMFA疲労攻撃（MFA Fatigue Attack）には注意が必要です。「承認を押してしまうまで通知を送り続ける」手口に対しては、番号マッチング（Number Matching）機能のある認証アプリを使うことで対策できます。

3. セッションをログイン後に必ず再生成する

セッション固定化攻撃を防ぐ最重要の対策は、認証成功後にセッションIDを必ず新規生成することです。PHPの場合、次のように実装します。

# PHP: ログイン処理内で認証成功後に実行
# 古いセッションを削除しながらIDを再生成（true = 古いファイルを削除）
session_regenerate_id(true);

# セキュアなセッションCookie設定
session_set_cookie_params([
    'lifetime' => 0,
    'path'     => '/',
    'domain'   => '',
    'secure'   => true,      # HTTPSのみ送信
    'httponly' => true,      # JavaScriptからアクセス不可
    'samesite' => 'Strict',  # CSRF対策
]);

ログアウト時も同様に、サーバー側のセッションデータを完全に削除することが重要です。Cookieを削除するだけでは、セッションIDを知っている攻撃者は引き続きアクセスできてしまいます。

4. パスワードをbcrypt / Argon2でハッシュ保存する

DBが漏洩したときに「平文パスワードがそのまま使われる」事態を防ぐため、パスワードは必ずソルト付きの強力なハッシュ関数で保存します。MD5・SHA-1・SHA-256のような汎用ハッシュは高速すぎて、現代のGPUでは秒間数百億回の試行が可能です。

パスワード保存に適したアルゴリズムは次のとおりです。

・bcrypt: 推奨コストファクターは12以上。ほぼすべてのWebフレームワークで標準サポートされている
・Argon2id: PHC（Password Hashing Competition）優勝アルゴリズム。メモリハード設計でGPU攻撃に強い
・scrypt: Argon2が使えない環境での次善策として有効

詳細はパスワードハッシュ化とソルト・bcrypt・Argon2の実践ガイドを参照してください。

中小企業でも今日からできること

自社でWebアプリを開発していない企業でも、SaaSやクラウドサービスの認証設定を見直すだけでリスクを大幅に下げられます。

・Microsoft 365 / Google Workspace でMFAを必須化: 管理者コンソールから条件付きアクセスまたは2段階認証を全ユーザーに強制する
・VPN・リモートデスクトップにMFAを追加: パスワード単独のVPNは狙われやすいため、OTPやハードウェアトークンと組み合わせる
・退職者アカウントの即時無効化: 退職・異動時に24時間以内にアカウントを無効化するフローを整備する
・デフォルトパスワードの変更: ルーター・NAS・プリンターなど機器のデフォルト認証情報は必ず変更する
・パスワードマネージャーの全社導入: 強力で一意なパスワードを全員が使えるようにする（LastPass・1Password・Bitwardenなど）

LinuxサーバーへのSSH認証強化については、姉妹サイトLinuxMaster.JPでも実践的な手順を解説しています。

よくある誤解と注意点

【誤解1】「HTTPSさえ使えば認証は安全」

HTTPSは通信経路を暗号化しますが、アプリケーション内部の認証ロジックの欠陥には無力です。平文保存・アカウントロック不在・セッション固定化はHTTPS環境でも発生します。「HTTPS = 安全」と考えるとアプリ層の防御がおろそかになりがちなので注意が必要です。

【誤解2】「CAPTCHAがあればブルートフォースを防げる」

CAPTCHAは自動化ツールへの障壁になりますが、OCRやAIを使った突破手法も存在します。単体での対策としては不十分で、アカウントロック・レートリミットとの組み合わせが必要です。CAPTCHAを「唯一の認証防御」と考えるのは危険です。

【注意】MFA導入後も「リカバリーコード」の管理を忘れない

MFAのリカバリーコード（緊急時のバックアップコード）はパスワードと同等の価値があります。スプレッドシートやメールに平文で保存すると、クラウドアカウントが侵害されたときに一緒に奪われます。暗号化されたパスワードマネージャーで厳重に管理しましょう。

本記事のまとめ

認証の失敗（OWASP A07）は、ログイン機能・セッション管理・パスワード保存のあらゆる実装ミスを攻撃者に突かれる脆弱性です。次の表で対策の全体像を確認してください。

認証の失敗は「OWASP Top 10の中でも対策コストが低く、効果が大きい」カテゴリのひとつです。フレームワークのデフォルト設定を活用しつつ、MFAの必須化・アカウントロック・セッション再生成の3点から着手してください。

関連記事としてアクセス制御の不備（OWASP A01）や暗号化の失敗（OWASP A02）も合わせて読むことで、OWASP Top 10への理解が深まります。