こんにちは！セキュリティの世界へようこそ。
新人のIT担当者や、これからWebアプリケーションの開発に挑む皆さんにとって、「パスワードの管理」は最初にぶ壁の一つですよね。
今回は、Webサービスには欠かせない「パスワードリセット機能」の裏側にあるセキュリティの落とし穴と、それを安全に実装するための「ハッシュ化トークン」の仕組みについて、一緒に紐解いていきましょう。難しい言葉も、身近な防犯に例えて優しく解説していきますので、一歩ずつマスターしていきましょうね！
—
1. 家の鍵の「予備キー」をどう扱いますか？
まずは、パスワードリセット機能がどんなものか、私たちの日常生活に置き換えて考えてみましょう。
あなたが大切なお家の鍵をうっかり忘れてしまい、中に入れなくなってしまったとします。困ったあなたは、管理会社に連絡して「予備の鍵」を発行してもらうはずです。
このとき、管理会社が「予備キーですので、その辺の道路にポンと置いておきますね」なんて言ったら、どう思いますか？ 「泥棒に入ってくださいと言っているようなものだ！」と怒ってしまいますよね。
Webサイトにおける「パスワードリセット用URL」も、まさにこれと同じです。
ユーザーが「パスワードを忘れちゃった！」とヘルプを求めたとき、システムは一時的に「新しいパスワードを登録するための権利（＝予備キー）」をURLという形で発行します。もし、このURLの作り方や保存の仕方を間違えてしまうと、悪意ある攻撃者に予備キーを奪われ、簡単にアカウントを乗っ取られてしまうのです。
—
2. パスワードリセットの裏側で起きていること
パスワードリセットの流れを、もう少し技術的な視点から見てみましょう。大まかなステップは以下の通りです。
1. ユーザーが「パスワードを忘れた」画面でメールアドレスを入力する。
2. システムが「この人にはパスワードを変える権利がありますよ」という証明書（トークン）を生成する。
3. そのトークンを組み込んだURL（例: https://example.com/reset?token=abc123xyz）をメールで送信する。
4. ユーザーがそのURLをクリックし、新しいパスワードを入力して送信する。
5. システムがトークンを確認し、正しければパスワードを書き換える。
この仕組みの中で、セキュリティ担当者や開発者が特に気をつけなければならないポイントが2つあります。それが「推測不可能なランダム値の生成」と「データベースでのハッシュ化保存」です。
—
3. 攻撃者はどうやって「予備キー」を狙うのか？
もし、パスワードリセット用トークンをテキトーに作ってしまったり、データベースにそのまま保存したりしていると、どのようなサイバー攻撃を受けるでしょうか？
危険なパターンA：予測可能なトークン
例えば、トークンを作るのに「今の時刻（タイムスタンプ）」や「ユーザーのID（1, 2, 3…）」をそのまま使っていたとします。
攻撃者は、「おっ、さっきあのユーザーがパスワードリセットを要求したな。今の時間は○時○分だから、トークンはこの辺りの数字の組み合わせのどれかだな！」と推測し、総当たりで次々にURLを叩いてしまいます。これを「推測攻撃」や「ブルートフォース攻撃」と呼びます。
危険なパターンB：データベースのぞき見（SQLインジェクションや情報漏洩）
仮に、トークン自体はめちゃくちゃ複雑なランダム文字列にしたとしましょう。しかし、そのトークンをデータベースにそのまま（平文で）保存していたらどうなるでしょうか？
万が一、データベースが不正アクセスを受けて中身が盗み見られたとき、攻撃者はそこに保存されている「有効なリセットURLのリスト」をそっくりそのまま手に入れてしまいます。これでは、どんなに複雑な文字列でも意味がありません。
—
4. 安全なトークンの作り方と保存の仕組み
では、こうした脅威からユーザーを守るためには、どうすればよいのでしょうか？
ここからは、実際の開発で使える具体的なアプローチを見ていきましょう。
① 暗号学的安全な乱数（CSPRNG）を使う
まず、トークンは絶対に「予測不可能なランダムな値」で作る必要があります。プログラミング言語が標準で用意している適当な乱数生成器ではなく、「暗号学的に安全な擬似乱数生成器（CSPRNG）」を必ず使いましょう。
PHPを例に、安全なトークンの生成コードを見てみましょう。
<?php
// random_bytes() は暗号学的に安全なランダムなバイト列を生成します
// bin2hex() で人間が扱いやすい16進数の文字列に変換します
$raw_token = random_bytes(32); // 32バイト（256ビット）の十分な長さのランダム値
$token = bin2hex($raw_token);
// 生成されたトークンの例: a7f8c9d0e1f2... (非常に推測困難な文字列)
?>② データベースには「ハッシュ化」して保存する
ここが一番のキモです。生成したトークンをそのままデータベースに保存してはいけません。
パスワードを保存するときと同様に、SHA-256やSHA-3などのハッシュ関数を使ってハッシュ化（不可逆な変換）してから保存します。
「あれ？ ハッシュ化しちゃうと、ユーザーから送られてきたトークンと照合できなくない？」と思った方、素晴らしい着眼点です！
実は、データベースにはハッシュ化した値を保存しておき、ユーザーから送信されてきた生のトークンを同じハッシュ関数で変換して、データベースの値と見比べるという手法をとります。これなら、万が一データベースが盗まれても、元のトークンは攻撃者にバレません（※ハッシュ化は一方向にしか変換できないためです）。
以下は、その仕組みをイメージしたPHPのコード例です。
<?php
// 1. ユーザーに送信する用の生トークンを生成
$raw_token = bin2hex(random_bytes(32));
// 2. データベースに保存するためにハッシュ化する（SHA-256を使用）
// ※実際の現場ではソルトやより強力なハッシュアルゴリズム（password_hash等）を応用することもあります
$hashed_token = hash('sha256', $raw_token);
// --- ここで $raw_token を含んだURLをメールでユーザーに送信し、
// --- データベースには $hashed_token を保存しておきます。
// 3. ユーザーがURLをクリックしてアクセスしてきたときの検証処理
$user_input_token = $_GET['token'] ?? ''; // URLから送られてきた生のトークン
// ユーザーから送られたトークンを同じ方式でハッシュ化する
$calculated_hash = hash('sha256', $user_input_token);
// データベースに保存されているハッシュ値と一致するか比較する
// ※タイミング攻撃を防ぐために hash_equals() を使うのがプロの技です！
if (hash_equals($hashed_token, $calculated_hash)) {
// 一致したので、パスワード変更画面へ進める！
echo "トークンが有効です。新しいパスワードを入力してください。";
} else {
// 一致しない場合はエラー
echo "無効なURL、または有効期限が切れています。";
}
?>—
5. 現場のプロが教える、さらに強固にするためのプラスアルファ
基本の仕組みが分かったところで、現場でシステムを運用する際に意識しておきたい「実践的なセキュリティのコツ」をいくつかご紹介します。
- 有効期限を短く設定する
パスワードリセット用トークンは、「発行されてから15分〜30分程度」で無効になるように必ず有効期限（Expire）を設けましょう。長く放置された予備キーほど危険なものはありません。
- 1回使ったら二度と使えないようにする（使い捨て）
トークンを使って無事にパスワードを変更した直後、そのトークンは即座にデータベースから削除（または無効化）してください。同じURLを何度も再利用できてしまうのはご法度です。
- HTTPSを強制する
どれだけ安全なトークンを作っても、通信が暗号化されていない（HTTP）と、途中でネットワークを盗聴されてトークンをごっそり奪われてしまいます。すべてのページでHTTPS通信を徹底しましょう。
—
おわりに
パスワードリセット機能は、一見するとシンプルで短いコードで実装できるように思えます。だからこそ、新人の頃は「動けばいいや」とセキュリティの細かい部分を見落としがちになってしまうポイントでもあります。
ですが、今回学んだ「推測不可能なランダム値（CSPRNG）」と「データベースでのハッシュ化保存（hash() や hash_equals()）」の原則をしっかり押さえておけば、悪意ある攻撃者からサービスと大切なユーザーをしっかりと守ることができます。
「どうしてこのコードを書く必要があるんだっけ？」と迷ったときは、「これはお家の予備キーなんだ」という原点を思い出してみてくださいね。
日々の開発の中で、セキュリティを意識する楽しさを感じながら、一緒に頼りになるエンジニアへの階段を登っていきましょう！
コメント