認証・セッション管理

認証とは、ユーザーが主張するアイデンティティを検証するプロセスであり、適切な実装を怠ると不正アクセスの直接的な入り口となる。パスワード認証においては、強度要件の設定だけでなく、ブルートフォース攻撃に対するレート制限・アカウントロック・CAPTCHA等の複数の対策を組み合わせることが重要である。NIST SP 800-63BはNISTが定義したデジタルアイデンティティガイドラインであり、定期的なパスワード変更強制や複雑性ルールの強制よりも、長いパスフレーズとHIBP（Have I Been Pwned）を使った侵害済みパスワードの拒否を推奨している。

多要素認証（MFA）は、パスワード漏洩があっても不正ログインを防ぐ最も効果的な追加対策であり、TOTP（RFC 6238準拠のGoogleAuthenticator等）は多くのサービスで標準的に採用されている。FIDO2 / WebAuthnは、フィッシング耐性のある公開鍵暗号ベースの認証であり、次世代の強認証として急速に普及している。JWTはステートレスな認証トークンとして広く使われるが、alg:none攻撃（署名なしトークンの受け入れ）・適切な有効期限設定の欠如・署名検証の省略など、実装上の落とし穴が多い。

セッション管理では、セッション固定化攻撃（Session Fixation）を防ぐため、ログイン成功後に必ずセッションIDを再生成する必要がある。Cookieのセキュリティ属性（HttpOnly・Secure・SameSite=StrictまたはLax）は組み合わせて設定することで、XSSによるセッション窃取とCSRF攻撃の双方を軽減できる。OAuth 2.0 / OIDCを外部IdPと連携する際は、stateパラメータのCSRF検証とnonceの確認を実装することが必須となる。

コードレビューで着目するポイント

ログイン失敗時にレート制限（指数バックオフ等）が実装されているか
パスワードのハッシュにbcrypt・Argon2・scryptが使われているか（平文・MD5保存がないか）
JWTの署名アルゴリズムがサーバー側で明示的に検証されており、alg:noneを受け入れないか
ログイン成功後にセッションIDが再生成されているか（セッション固定化攻撃の防止）
CookieにHttpOnly・Secure・SameSite属性が設定されているか
JWTの有効期限（exp）が設定されており、期限切れトークンが拒否されるか
OAuth 2.0フローでstateパラメータのCSRF検証が実装されているか
MFAが実装されているサービスで、リカバリーコードも適切に保護されているか

典型的なアンチパターン

セッションIDの再生成なし: ログイン前から同一のセッションIDを使い続ける実装。攻撃者が事前にセッションIDを被害者に固定させてログイン後のセッションを乗っ取るセッション固定化攻撃が成立する。ログイン成功時に必ず新しいセッションIDを発行すること。

JWTの署名検証省略: JWTをBase64デコードしてペイロードのみを信頼し、署名を検証しない実装。任意のペイロードを持つ偽造トークンを受け入れてしまう。必ずライブラリのverify関数を使い、アルゴリズムをサーバー側で固定すること。

エラーメッセージによるユーザー存在確認: ログイン失敗時に「このメールアドレスは登録されていません」と表示すると、攻撃者がメールアドレスの有効性を確認できる（ユーザー列挙）。「メールアドレスまたはパスワードが正しくありません」というメッセージで統一すること。

参考リソース

NIST SP 800-63B: Digital Identity Guidelines — パスワード・MFA・フェデレーション認証の政府標準ガイドライン
OWASP Authentication Cheat Sheet — 認証実装の包括的なチェックリスト
WebAuthn Guide (https://webauthn.guide/) — FIDO2 / WebAuthn実装入門
Have I Been Pwned (https://haveibeenpwned.com/Passwords) — 侵害済みパスワードデータベースAPI（登録時の拒否に活用）
jwt.io — JWTのデコードと署名検証を行う開発者向けツール