メール確認がなぜ重要か
メール確認には三つの主要な目的があります。第一に、ユーザーが提供したアドレスを実際に管理していることを確認します — [email protected] のようなタイプミスは驚くほど頻繁に発生します。第二に、偽のアドレスや使い捨てアドレスを使ったボットによる大量のアカウント自動作成を防ぎます。第三に — そして最も過小評価されているのですが — 確認済みメールアドレスはパスワードリセットのセキュリティ前提条件です。確認なしでは、攻撃者が他人のアドレスを登録してリセットメールを送信させることができます。OWASP Authentication Cheat Sheet でこれらのリスクを詳しく確認できます。
確認フローの全ステップ
メール転送プロトコルは RFC 5321 で定義されていますが、アプリケーション層の決定は完全に開発者に委ねられています。各ステップが重要です:
- ユーザーが登録フォームを送信する。メールフォーマットをサーバー側で検証する — クライアント側だけでなく。
- 暗号的にランダムなトークンを生成する。UUID、連番ID、タイムスタンプではなく — 最低32バイトのエントロピーを持つ真の暗号的ランダム性。
- トークンのハッシュをデータベースに保存する。生トークンではなくSHA-256ハッシュを、ユーザーID、作成タイムスタンプ、有効期限、「使用済み」フラグとともに保存する。
- 確認メールを送信する。リンクにはクエリパラメータとして生トークンを含める。常にHTTPSを使用する。
- ユーザーがリンクをクリックする。サーバーがクエリ文字列から生トークンを受け取る。
- トークンを検証する。受信トークンをハッシュし、データベースで一致を探し、有効期限と「使用済み」フラグを確認する。
- 成功時:メールアドレスを確認済みとしてマーク、トークンを使用済みとしてフラグ設定、ユーザーをログイン。
- 失敗時:新しいメールを要求するリンクを含む具体的で実行可能なエラーメッセージを表示する。
セキュアなトークン生成
最も一般的なミスはUUID v4を確認トークンとして使用することです。UUIDはデータベース識別子には適していますが、セキュリティトークンとして設計されていません。正しいアプローチ: ランタイムの暗号的乱数生成器を使用する。Node.js: crypto.randomBytes(32).toString('hex')。Python: secrets.token_urlsafe(32)。.NET: RandomNumberGenerator.GetBytes(32)。OWASP Authentication Cheat Sheet は最低32バイト(256ビット)のエントロピーを推奨しています。
保存方法: SHA-256ハッシュをデータベースに保存し、生トークンをメールリンクで送信する。検証時に受信トークンをハッシュし、保存されたハッシュと比較する。攻撃者がデータベースにアクセスしても、ハッシュは役に立ちません。定時比較関数を使用する: Node.jsでは crypto.timingSafeEqual()、Pythonでは hmac.compare_digest()。
確認フローの適切なテスト
確認フローの変更は必ず実際のインボックスへの実際のメールでテストする必要があります。一時的なメールアドレスを開いて登録フォームにコピーし、テストアカウントを作成して確認メールがリアルタイムで届くのを確認します。これにより、メールが実際に配信されていること — プロバイダーのAPIに受け入れられただけでなく — が確実に証明されます。
メール認証: SPF、DKIM、DMARC
正しいメール認証なしでは、確認メールはスパムに入ります。SPFはDNS TXTレコードで送信サーバーを承認します。DKIMは暗号署名を追加します。DMARCはSPFまたはDKIMが失敗した場合のポリシーを定義します。MXToolbox で三つの設定を確認します。送信プロバイダーのメール認証ドキュメントを参照してください。
よくある間違い
- 使用後にトークンを無効化しない。常に「使用済み」フラグを設定し、各検証でチェックする。
- 確認前にウェルカムメールを送信する。オンボーディングシーケンスは確認後にのみ有効化する。
- 再送エンドポイントのレート制限なし。アドレスごとの再送リクエストを例えば1時間に3回に制限する。
- HTTPで確認リンクを送信する。常にHTTPSを使用する — 例外なし。
- 確認イベントをログに記録しない。トークンがいつ作成、送信、クリックされたか — デバッグに不可欠。
- 複数の目的に同じトークンを使用する。確認、パスワードリセット、メール変更に別々のトークンを使用する。