「パスワードはデータベースに“そのまま”保存してはいけない」——ではどう保存するのか。その答えがハッシュ化です。仕組みと、安全にするための勘所を解説します（攻撃手順は載せません）。
ハッシュ化 ≠ 暗号化
混同されがちですが、目的が逆です。**暗号化は「後で読み返すために、鍵で元に戻せる」**変換。ハッシュ化は「元に戻せない（一方向）」変換です。パスワードは、運営側ですら本来読み返す必要がない情報なので、あえて戻せないハッシュ化が向いています。
暗号化（可逆）
平文 ⇄ 暗号文。鍵があれば元に戻せる。後で読み返すデータ向け
ハッシュ化（一方向）
パスワード → ハッシュ値。元には戻せない。パスワード保存向け
ログイン時は「入力されたパスワードを同じ手順でハッシュ化し、保存済みのハッシュと一致するか」を見ます。元のパスワードを取り出す必要はありません。
なぜ「素のMD5/SHA-256」では足りないのか
MD5 や SHA-256 は速いハッシュです。本来は便利な性質ですが、パスワード保存では弱点になります。攻撃者は流出したハッシュに対して、1秒あたり膨大な候補を計算して突き合わせられるからです。
- レインボーテーブル：「よくあるパスワード→そのハッシュ」を事前計算した巨大な対応表。素のハッシュだと、表を引くだけで一致が見つかってしまう。
- 総当たり（ブルートフォース）：速いハッシュほど、単位時間あたりに試せる候補が増える＝破られやすい。
安全にする2つの仕掛け
ソルト（ユーザーごとに違う値）を足す
保存前に、利用者ごとに異なるランダムな値（ソルト）を混ぜてからハッシュ化する。すると同じパスワードでも保存値が全員バラバラになり、レインボーテーブルが無効化され、使い回しの一括解析もできなくなる。
わざと遅い専用ハッシュを使う
bcrypt / Argon2 / scrypt は、計算を意図的に重くできる（コストパラメータ）。正規ログインの1回は気にならない遅さでも、攻撃者の総当たりは現実的でない速度に落ちる。ソルト付与もこれらに組み込まれている。
当サイトの視点：自前で組まない
「MD5にソルトを足せば十分でしょ？」——これが典型的な落とし穴です。安全なパスワード保存は、ソルトの生成・保管、計算コストの調整、タイミング差への配慮まで含めて初めて成立します。自前で寄せ集めるより、言語・フレームワークの公式パスワード関数（多くが内部で bcrypt/Argon2 を使う）に任せるのが、当サイトの立場では最も安全で確実です。新規なら Argon2id を第一候補に。
次に読む
- 用語：ソルトとは（使い回し攻撃を無効化する“味付け”）
- 対策：パスワードの安全な保存方法（ハッシュ化＋ソルト実践）
- 入門：パスワードの正しい保管（平文保存をやめる） / パスワードマネージャーの選び方
よくある質問
Qハッシュ化と暗号化は何が違いますか？
暗号化は『鍵があれば元に戻せる（復号できる）』変換で、データを後で読み返す用途に使います。ハッシュ化は『元に戻せない（一方向）』変換です。パスワードは本来こちらが運営側で読み返せる必要がないので、わざと戻せないハッシュ化が向いています。万一データベースが盗まれても、ハッシュからは元のパスワードを直接取り出せません。
QMD5やSHA-256でハッシュ化すれば安全ですか？
それだけでは不十分です。MD5/SHA-256は『速い』ハッシュで、攻撃者が1秒間に膨大な候補を試せてしまうため、よくあるパスワードは総当たりやレインボーテーブル（事前計算した対応表）で破られます。安全にするには、ユーザーごとに異なる『ソルト』を加え、さらに『わざと遅い』専用ハッシュ（bcrypt・Argon2・scrypt）を使います。
Q結局どれを使えばいいですか？
新規なら Argon2（特にArgon2id）が第一候補、次点で bcrypt か scrypt です。いずれもソルトの付与と計算コストの調整が仕組みに組み込まれています。自分でMD5+ソルトを組むより、これらの標準実装（言語/フレームワークの公式関数）を使うのが安全で確実です。