Web認証の実装でやりがちな危険な失敗例と正しい対策

ソフトウェア開発において、認証（Authentication）は開発者を最も油断させやすい機能の1つです。「とりあえず動くものを作る」だけなら数時間で実装できますが、「絶対に破られない堅牢な認証システム」を構築するのは極めて難易度が高い作業です。

世界中で発生している重大なデータ漏洩事故の多くは、高度なゼロデイ攻撃ではなく、自作した認証機能の初歩的な実装ミスから生じています。

1. 10歳でもわかる解説（ELI5）：頑丈な鉄扉と足拭きマットの下の鍵#

あなたが頑丈な家を建てようとしている場面を想像してみてください：

• 玄関には大金を払って厚さ20cmの巨大な防犯スチールドアを取り付けました（ユーザーに16文字以上の複雑なパスワードを強制）。
• しかし、予備の鍵を玄関マットの下に隠したままにしています（XSS脆弱性のあるサイトでJWTを localStorage に保存）。
• さらに、裏庭の窓の鍵を閉め忘れました（ログイン試行回数の制限・レートリミットを忘れる）。
• そして見知らぬ人がインターホンで「ボブさんはここに住んでいますか？」と聞いてきた時、正直に「はい、ボブはいますが今は寝ています」と答えました（アカウントの存在確認が可能なユーザー列挙脆弱性）。

玄関ドアがどれほど頑丈でも、泥棒は苦労することなく家の中に侵入できてしまいます。

flowchart TD
    subgraph Vulnerable["脆弱な認証パイプライン"]
        A1["パスワード間違い"] --> B1["エラー: 'メアドは存在しますがパスワード不一致' - 存在漏洩"]
        A2["総当たり攻撃"] --> B2["試行制限なし - パスワード解読成功"]
        A3["パスワードリセット"] --> B3["トークン無期限 + 既存セッション未破棄"]
    end

    subgraph Secure["堅牢な認証パイプライン"]
        C1["パスワード間違い"] --> D1["汎用応答: '認証情報が無効です'"]
        C2["5回連続失敗"] --> D2["15分間のIP遮断 + CAPTCHA"]
        C3["パスワードリセット"] --> D3["256bit乱数トークン(有効15分) + 全セッション強制切断"]
    end

2. 認証実装における7大危険ミス#

ミス 1: 高速なハッシュ関数（MD5, SHA-1, 単純なSHA-256）の使用#

「パスワードを生テキストで保存せず、SHA-256でハッシュ化しているから安心だ」と考える開発者が今でも多く存在します。これは致命的な誤解です。

• 理由: SHA-256 や MD5 は汎用の高速計算用アルゴリズムであり、1秒間に数十億回計算できるように設計されています。
• リスク: データベースが漏洩した場合、攻撃者は最新のGPUを使って毎秒数百億回のハッシュ計算を行い、レインボーテーブルや辞書攻撃で容易に元のパスワードを復元します。

[!TIP] 正しい対策: 計算が意図的に遅く、メモリを大量に消費するパスワード専用ハッシュアルゴリズム（Memory-hard）を使用してください：

1. Argon2id（現在OWASPが最も推奨）。
2. bcrypt（コスト係数 cost >= 12）。
3. scrypt または PBKDF2。

import argon2 from 'argon2';

// Argon2idによるセキュアなパスワードハッシュ化
export async function hashPassword(password: string): Promise<string> {
  return await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 65536, // 64 MB RAM
    timeCost: 3,       // 3 iterations
    parallelism: 4
  });
}

// タイミング攻撃を防ぐパスワード照合
export async function verifyPassword(hash: string, plain: string): Promise<boolean> {
  return await argon2.verify(hash, plain);
}

ミス 2: ユーザーの存在確認を許してしまう（User Enumeration）#

ログインやパスワード再発行の失敗時に、詳細すぎるエラーメッセージを返すケースです：

• ❌ 「このメールアドレスは登録されていません」
• ❌ 「パスワードが間違っています」

攻撃者は10万件のメールリストを使ってスクリプトを実行するだけで、誰があなたのサービスを利用しているかを簡単にリストアップ（列挙）できてしまいます。

[!NOTE] 正しい対策: 常に中立的で統一されたメッセージを返します：

• ログイン失敗時：「メールアドレスまたはパスワードが正しくありません」
• パスワード再発行時：「該当するアカウントが存在する場合、再設定用のリンクを送信しました」

ミス 3: レートリミットとタイミング攻撃（Timing Attack）の対策漏れ#

ログインエンドポイントにレートリミット（回数制限）を設けていない場合、パスワードスプレー攻撃やDoS攻撃の標的になります。

また、文字列の通常の比較（===）は一致する文字数によって処理時間が微妙に変化するため、タイミング攻撃によってトークンが推測される危険があります：

import crypto from 'crypto';

// ❌ 危険: 実行時間の差で文字一致数が漏洩する
// if (userProvidedToken === secretToken) ...

// ✅ 安全: 固定時間比較（Constant-time comparison）
export function safeEqual(a: string, b: string): boolean {
  const bufA = Buffer.from(a);
  const bufB = Buffer.from(b);
  
  if (bufA.length !== bufB.length) return false;
  return crypto.timingSafeEqual(bufA, bufB);
}

ミス 4: パスワードリセット機能の脆弱性#

パスワード再設定フローは、システム全体の中で最も攻撃者に狙われやすいポイントです：

1. 短すぎる・推測可能なトークン: 4桁の数字や Math.random() の使用。
2. 有効期限（TTL）のないリンク: メール内のURLが無期限で有効な状態。
3. 既存セッションの破棄漏れ: パスワードを変更しても、既存端末でログイン中のセッションCookieやRefresh Tokenが有効なまま残ってしまう。

[!WARNING] パスワード変更またはリセットが成功した際は、接続中のすべての端末のセッションおよびRefresh Tokenを即座に無効化（Revoke）してください！

ミス 5: 認証（Who）と認可（What）の混同（IDOR脆弱性）#

• Authentication（401 Unauthorized）: あなたは誰か？（例: ユーザーA）
• Authorization（403 Forbidden）: あなたはそのデータを操作する権限があるか？

ログイン確認ミドルウェアを通しただけで安心し、他人のリソースにアクセスできてしまう IDOR（Insecure Direct Object References） が多発しています：

// ❌ IDOR脆弱性: ログイン済みユーザーであれば誰でも他人の請求書を閲覧可能！
app.get('/api/invoices/:id', authenticateUser, async (req, res) => {
  const invoice = await db.invoices.findById(req.params.id);
  // 所有者チェックの欠落: if (invoice.userId !== req.user.id) return res.status(403);
  return res.json(invoice);
});

ミス 6: クライアント側での危険なトークン保存#

• localStorage へのJWT保存: 悪意あるサードパーティ製npmパッケージやXSS攻撃により、1行のスクリプトで全トークンが持ち去られます。
• セキュリティ属性のないCookie: HttpOnly, Secure, SameSite=Lax/Strict を設定し忘れ、CSRF攻撃に晒される。

ミス 7: 暗号化の自作（Rolling Your Own Crypto）#

「独自開発した難読化ロジックだからハッカーにも解けないはずだ」という考えは、暗号学において最も危険な「隠蔽によるセキュリティ（Security through Obscurity）」です。

OAuth 2.0、OpenID Connect、WebAuthn/Passkeysなどの実績ある標準規格を採用しましょう。

3. デプロイ前の認証セキュリティ・チェックリスト#

4. まとめ#

強固な認証システムとは、ユーザーに無理な複雑パスワードを強制することではなく、設計と実装のすべての接合部において防御的なアプローチを徹底することです。

自作の認証機能に潜む盲点を本記事のチェックリストで点検し、安全なプロダクトをリリースしましょう。

参考文献#

• OWASP Authentication Cheat Sheet ↗
• OWASP Password Storage Cheat Sheet ↗
• OWASP Forgot Password Cheat Sheet ↗
• RFC 9106: Argon2 Memory-Hard Function for Password Hashing ↗