Shikata Ga Nai

Private? There is no such things.

パスワードリセット機能の落とし穴:安全に実装しないとアカウントが乗っ取られる

Hello there, ('ω')ノ

🎯 なぜパスワードリセットは危険なのか?

パスワードリセットは、通常の認証プロセスをスキップしてアカウントの重要情報を変更する機能です。そのため、「本当に本人かどうか」を確認する代替の検証手段が求められます。


✉️ パスワードをメールで送る方式の問題点

❌ 悪い例:

  • サイトがユーザーの現在のパスワードを平文で送信してくる。
  • または、新しいパスワードを生成し、それをメールで送信する。

🔐 なぜ危険なのか?

  • パスワードを平文で保持している証拠
  • メールは暗号化されていない可能性が高く、中間者攻撃に弱い
  • 多くのユーザーは複数デバイスでメールを同期しており、盗聴や端末紛失リスクがある。

🔗 URLでパスワードをリセットする方式

✅ 良い例:

https://secure-website.com/reset-password?token=ランダムで推測困難な値
  • トークンは高エントロピー(長くて複雑なランダム文字列)
  • 誰のパスワードをリセットするのか、URLから推測できない。
  • トークンは一度だけ使用可能で短時間で失効する。

❌ 悪い例:

http://vulnerable-website.com/reset-password?user=carlos
  • ユーザー名を変えれば誰のパスワードでもリセット可能
  • 簡単に自分のページから他人のページにアクセスされる。

⚠️ よくある実装ミス:フォーム側でのトークン検証忘れ

  1. 攻撃者がパスワードリセットリンク(トークン付き)を取得。
  2. その後、リセット画面のHTMLだけを保存 or トークンを削除。
  3. リセットフォームがトークンを再チェックしない場合、自分のトークンで他人のパスワードを変更可能。

🛡 開発者向けのベストプラクティス

対策 説明
ハッシュ化されたトークンを使用 データベースに保存する際はSHA-256などで保護
ユーザー名ベースではなくトークンベースの認証 トークンだけでユーザーを識別
トークンの使い回し防止 リセット後は必ずトークンを無効化・削除
短時間での有効期限切れ 例:15分程度で自動失効
トークンの再検証を必須に フォーム送信時にもサーバーでトークン確認を行う

✅ まとめ

  • パスワードリセット機能は便利だが危険
  • 重要なのは「本人確認が十分か」と「情報が推測・流出しない設計」。
  • 攻撃者は小さな実装ミスを突いてアカウント乗っ取りを狙う。

🔐 ペネトレーションテストでは、パスワードリセットのリクエストからどんな情報が使われているか、何がチェックされているかを徹底的に確認しましょう。見落とされやすいリセットフォーム側の検証漏れが狙い目です!

Best regards, (^^ゞ