パスワードはデータベースにそのまま保存してはいけません。では、どう保存するのか。その答えがハッシュ化です。仕組みと、安全にするための要点を解説します（攻撃手順は載せません）。
ハッシュ化 ≠ 暗号化
混同されがちですが、目的が逆です。暗号化は「後で読み返すために、鍵で元に戻せる」変換。**ハッシュ化は「元に戻せない（一方向）」**変換です。パスワードは、運営側ですら本来読み返す必要がない情報なので、あえて戻せないハッシュ化が向いています。
暗号化（可逆）
平文 ⇄ 暗号文。鍵があれば元に戻せる。後で読み返すデータ向け
ハッシュ化（一方向）
パスワード → ハッシュ値。元には戻せない。パスワード保存向け
ログイン時は「入力されたパスワードを同じ手順でハッシュ化し、保存済みのハッシュと一致するか」を見ます。元のパスワードを取り出す必要はありません。
なぜ「素のMD5/SHA-256」では足りないのか
MD5 や SHA-256 は速いハッシュです。本来は便利な性質ですが、パスワード保存では弱点になります。攻撃者は流出したハッシュに対して、1秒あたり膨大な候補を計算して突き合わせられるからです。
- レインボーテーブル：「よくあるパスワード→そのハッシュ」を事前計算した巨大な対応表。素のハッシュだと、表を引くだけで一致が見つかってしまう。
- 総当たり（ブルートフォース）：速いハッシュほど、単位時間あたりに試せる候補が増える＝破られやすい。
汎用ハッシュとパスワード用ハッシュの違い
同じ「ハッシュ」でも、作られた目的が違います。パスワードの保存に使うのは右の列だけです。
| 汎用ハッシュ（MD5・SHA-1・SHA-256） | パスワード用ハッシュ（Argon2id・bcrypt・scrypt・PBKDF2） | |
|---|---|---|
| 作られた目的 | ファイルの改ざん検知、署名など | パスワードの保存 |
| 計算の速さ | できるだけ速い | わざと遅い（重さを調整できる） |
| ソルト | 仕組みに含まれない | 仕組みに含まれる（PBKDF2は呼び出し側で渡す） |
| 計算の重さの調整 | できない | コスト・反復回数・メモリ量で調整し、年々引き上げる |
| パスワード保存に | 使わない | 使う |
NIST SP 800-63B-4 も、パスワードは「ソルト」と「コスト（計算の重さ）」を入力に取るパスワード用のハッシュ方式で保存し、コストは性能を損なわない範囲でできるだけ高くして、年々引き上げるよう求めています。
安全にする2つの方法
ソルト（ユーザーごとに違う値）を足す
保存前に、利用者ごとに異なるランダムな値（ソルト）を混ぜてからハッシュ化する。すると同じパスワードでも保存値が全員バラバラになり、レインボーテーブルが無効化され、使い回しの一括解析もできなくなる。
わざと遅い専用ハッシュを使う
bcrypt / Argon2 / scrypt は、計算を意図的に重くできる（コストパラメータ）。正規ログインの1回は気にならない遅さでも、攻撃者の総当たりは現実的でない速度に落ちる。ソルト付与もこれらに組み込まれている。
具体例：漏えいのお知らせに「ハッシュ化」と書かれていたら
企業の漏えい発表では、パスワードの扱いが「平文」「ハッシュ化」「暗号化」のどれだったかが書かれることがあります。当サイトで扱った事例を、保存方式の違いで並べます。
| 事例 | 発表されたパスワードの扱い | 利用者への意味 |
|---|---|---|
| 宅ふぁいる便（2019） | 平文で保存されていた | そのまま読める。同じパスワードを使うほかのサービスも危険 |
| さくらインターネット（2026） | 一部の初期パスワードがハッシュ化されていなかった | 初期パスワードを使い続けていた人は、すぐ変更が必要 |
| Gyazo（2026） | ハッシュ値が流出。方式は非公表 | 方式次第で元に戻されうる。運営会社は変更を要請 |
読み方のポイントは2つです。
- 「ハッシュ化されていた」だけでは安全かどうか分からない。素のMD5か、ソルト付きの低速ハッシュかで、元に戻されやすさが大きく変わる
- 方式が書かれていなければ、弱い方式だった場合を前提に動く。そのサービスと、同じパスワードを使うほかのサービスのパスワードを変える
自分のメールアドレスが過去の漏えいに含まれていないかは、パスワードが漏れていないか確認する方法で調べられます。
自分のサイト・アカウントで確認する方法
利用者として：パスワード再設定の動きを見る
「パスワードを忘れた」から手続きして、元のパスワードがそのままメールで届くなら、平文か元に戻せる形で保存されている可能性が高いです。そのサービスには、ほかと共通のパスワードを使わないでください。
利用者として：パスワードの強さを確認する
ハッシュ化の守りが効くのは、長くて推測されにくいパスワードです。パスワード強度チェックで目安を確認し、保管はパスワードマネージャーに任せます。
開発者として：保存に使っている関数を確認する
コードで、パスワードの保存と照合に使っている関数を探します。PHPの password_hash()、Djangoの標準認証、bcrypt・Argon2のライブラリなど、パスワード専用の関数なら基本は満たしています。md5()・sha1()・sha256 を直接呼んでいる箇所があれば移行の対象です。
開発者として：保存済みの値と設定値を確認する
保存済みハッシュの見分け方、OWASPが示す最低限の設定値、弱い方式からの移行手順は、パスワードの安全な保存方法にまとめています。
当サイトの視点：自前で組まない
「MD5にソルトを足せば十分」と考えるのは、よくある間違いです。安全なパスワード保存は、ソルトの生成・保管、計算コストの調整、タイミング差への配慮まで含めて初めて成立します。自前で寄せ集めるより、言語・フレームワークの公式パスワード関数（多くが内部で bcrypt/Argon2 を使う）に任せるのが、当サイトの立場では最も安全で確実です。新規なら Argon2id を第一候補に。
出典（一次情報）
- NIST「SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management」（2025年8月） — pages.nist.gov（ソルトとコストを入力に取るハッシュ方式、コストを年々引き上げること）
- OWASP「Password Storage Cheat Sheet」 — cheatsheetseries.owasp.org（ハッシュ化と暗号化の違い、推奨アルゴリズム、作業係数）
- RFC 9106「Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications」 — rfc-editor.org
- 各事例の出典（運営会社の発表）は、表からリンクした当サイトの各記事に記載しています
次に読む
- 用語：ソルトとは（ユーザーごとに混ぜるランダムな値）
- 対策：パスワードの安全な保存方法（ハッシュ化＋ソルト実践）
- 入門：パスワードの正しい保管（平文保存をやめる） / パスワードマネージャーの選び方
- 事例：宅ふぁいる便 情報漏洩事件（2019）（平文保管の実例）