こんにちは！新人IT担当者や、これからセキュリティの勉強を始める開発者の皆さん、日々の開発やお疲れ様です。
セキュリティの話題って、なんだか難解な専門用語や英語のガイドラインばかりで、少し身構えてしまいますよね。「パスワードはハッシュ化しなさい」と教わったものの、じゃあ具体的にどうすればいいのか、頭を悩ませている方も多いのではないでしょうか。
今回は、セキュリティの世界で私たちが日々頭を悩ませている「パスワードストレッチングのコスト設定（Work Factor）」について、専門用語の壁をすっと取り払って、身近な防犯の例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、しっかりと実務で使える知識を身につけていきましょう！
—
1. 家の鍵で例える「パスワードの保存とストレッチング」
まず、私たちが普段使っている「パスワード」が、サーバーの中でどう扱われているのかをイメージしてみましょう。
皆さんが自分の家を出るとき、玄関の鍵をしっかり閉めますよね。では、もし「鍵をそのまま机の上に置いて出かけてください」と言われたらどうでしょう？泥棒が入ってきたら、一瞬で侵入されてしまいます。
Webサービスにおけるパスワードの保存もこれとまったく同じです。昔のシステムは、ユーザーが登録したパスワードをそのまま（あるいは単純な暗号で）データベースに保存していました。これでは、データベースが万が一ハッカーに盗み見られた瞬間、全ユーザーの鍵がそのまま奪われ、別のサービスでも同じパスワードを使い回している人たちのプライベートが次々と暴かれてしまいます。これが「平文（ひらぶん）保存」の恐ろしさです。
「ハッシュ化」と「ストレッチング」という二重の防犯扉
この問題を解決するために登場したのがハッシュ化です。パスワードを特殊な計算機に通して、元の文字が絶対に分からない「別の文字列（ハッシュ値）」に変換して保存します。これなら、データベースを覗き見られても、元のパスワードは簡単には分かりません。
しかし、攻撃者もバカではありません。彼らは超高性能なコンピューターを使い、ありとあらゆる単語や文字列をハッシュ化して、「このハッシュ値になるのはあのパスワードだ！」と膨大な辞書（レインボーテーブルなど）を使って総当たりで破ろうとします。
そこで登場するのが、今回の主役である「パスワードストレッチング」です。
これは、ハッシュ化の計算をわざと何万回、何百万回と何重にも繰り返させる（引き延ばす＝ストレッチする）技術です。
イメージとしては、「玄関の鍵を開けるために、パズルを100万回解かないと開かない頑丈な金庫を置く」ようなものです。私たちがログインするときは100万回の計算なんて一瞬（コンマ数秒）で終わりますが、何億回もパスワードを試したい攻撃者からすると、1回試すのにわざわざ莫大な時間がかかるため、攻撃効率がガタ落ちするというわけです。
—
2. 攻撃者が狙う盲点と「コストパラメータ（Work Factor）」の正体
このストレッチングの「何万回計算させるか」という難易度の度合いを、セキュリティの世界ではコストパラメータ（Work Factor：作業係数）と呼びます。
現在、パスワードを安全に保存するためのアルゴリズムとして世界的に推奨されているのが Argon2id や bcrypt といった仕組みです。これらには、計算の重さを調整するツマミ（パラメータ）が用意されています。
ここで、新人エンジニアの皆さんが陥りがちな罠があります。
「セキュリティを高くしたいから、コストパラメータを限界まで高く（何億回も計算するように）設定しておけば完璧だよね？」
実は、ここに大きな盲点があります。コストを上げすぎると、正しくログインしようとした一般のユーザーまで、「ログインボタンを押してから画面が3秒もフリーズする」「サーバーが重くなってエラーになる」という深刻な被害を受けてしまいます。これを狙った「サービス妨害（DoS）攻撃」のような状態を、自らの手で引き起こしてしまうのです。
セキュリティとユーザビリティ（使いやすさ）は、常にシーソーの関係にあります。だからこそ、時代のハードウェアの進化スピードに合わせて、このコストパラメータを適切にチューニングし続ける必要があります。
—
3. 実装コードで学ぶ！適切なコスト設定と書き方
それでは、実際にPHPの password_hash() 関数を例に、安全なパスワード保存とコスト設定の実装を見てみましょう。現代の言語やフレームワークでは、標準機能でこの bcrypt や Argon2id がサポートされています。
以下のコードを参考に、実務での実装イメージを掴んでみてください。
<?php
/**
* ユーザー登録時のパスワードハッシュ化処理のサンプル
*
* 泥棒からパスワードを守るため、あえて重い計算（ストレッチング）を行わせます。
*/
// 1. ユーザーが入力したパスワード（実際にはフォームから受け取ります）
$rawPassword = "User_Secure_Password_123!";
// 2. パスワードハッシュ化のアルゴリズムとコストの設定
// PHP標準の bcrypt (PASSWORD_BCRYPT) を使用する場合のオプション設定
$options = [
// cost パラメータが「ストレッチングの計算コスト（Work Factor）」に該当します。
// この数字を大きくすればするほど、計算に時間がかかります。
// ※2024〜2025年現在の推奨値の目安として、サーバー性能に合わせて 10〜12 程度がよく使われます。
'cost' => 12,
];
// 3. パスワードをハッシュ化（同時に内部で安全なソルトも自動生成されます）
$hashedPassword = password_hash($rawPassword, PASSWORD_BCRYPT, $options);
// 生成されたハッシュ値をデータベースに保存します
// 出力例: $2y$12$e0... (ここにランダムな文字列が入ります)
echo "データベースに保存する値: " . htmlspecialchars($hashedPassword, ENT_QUOTES, 'UTF-8');
/**
* 【開発者へのアドバイス】
* コスト値（上の例では 12）は固定せず、サーバーのCPU性能が向上するにつれて、
* 定期的に（例えば1年に1回など）見直して数値を引き上げていくのがプロの現場の作法です。
* 既存ユーザーのパスワードは、次回のログイン成功時に自動で新しいコストで再ハッシュ化（Rehash）する仕組みを組み込みましょう。
*/このように、コードを書くときは単に動くだけではなく、「もし攻撃者にデータベースを見られたらどうなるか」「サーバーの負荷は許容範囲内か」という視点を持つことが何よりも大切です。
—
4. まとめ：一歩ずつ、安全なシステム作りを
今回は、パスワードストレッチングの仕組みと、コストパラメータ（Work Factor）の考え方について解説しました。
- パスワードはそのまま保存せず、ハッシュ化とストレッチングで「解読に膨大な時間がかかる金庫」に入れよう。
- コストパラメータ（Work Factor）は、セキュリティの堅牢性とユーザーの利便性（処理速度）のトレードオフで最適値を選ぼう。
- ハードウェアの進化に合わせて、コスト設定は定期的に見直そう。
セキュリティの対策に「これで絶対安心」というゴールはありません。しかし、こうした基礎的な仕組みを一つひとつ理解し、丁寧な実装を積み重ねていくことで、サイバー攻撃者にとって「割に合わない、面倒な標的」に作り変えることができます。
難しく考えすぎず、まずはご自身が関わっているシステムのパスワード処理がどうなっているか、コードを覗いてみることから始めてみませんか？ 一歩ずつ、確実に安全なエンジニアへの階段を上っていきましょう！
コメント