パスワードのハッシュ化と暗号化の違い｜鍵ごと盗まれる保存をやめ、遅いハッシュとソルトへ移す手順を実測で解説

パスワードのハッシュ化と暗号化の違いは、事故が起きたときに初めて差が出ます。暗号化は鍵で元に戻せる処理なので、鍵と復号の仕組みを盗まれると、保存していた全件が平文に戻ります。ハッシュ化は戻す手段を持たない処理で、攻撃者には推測を1件ずつ試す道しか残りません。

連載「事故から逆算するWebセキュリティ」の第1回は、2026年10月のソースネクストの情報漏洩を入口に、パスワードを何で保存するかを整理します。

事案の経緯は ソースネクスト情報漏洩の記事 に、インシデントの読み方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

ソースネクストの説明とPCI DSSの読み方のタイムライン

この説明の文言は、当サイトが検索結果に載った報道の本文で確認したもので、同社の発表本文では確認できていません。発表本文は保存形式を説明していないとされます。ここでは「暗号化して保存し、復号の仕組みごと取られた」という説明を前提に、保存方式の側から考えます。

X上の議論では、PCI DSS 3.2.1 の要件8.2.1「強力な暗号化を使用して、すべてのシステムコンポーネントで、送信と保存中に認証情報（パスワードなど）をすべて読み取り不能にする」（当サイト訳）を字面どおり読むと「パスワードを暗号化せよ」に見え、可逆な暗号化を選ぶ理由になったのではないか、という見方が出ていました。

規格の側を確かめると、PCI DSS v4.0 では同じ趣旨が要件8.3.2に移り、対象は「認証要素」に広がっています。PCI SSC の FAQ 1253（2025年7月）は、強力な暗号を使ってパスワードをハッシュ化すれば8.3.2の意図を満たすと答えています。規格が求めるのは「読み取り不能」であって、戻せる暗号化ではありません。

・要件の文言は、規格の対応表を載せた複数のサイトの本文で確認した
・FAQ 1253 の回答は、PCI SSC のページが開けず検索結果の本文で確認した
・v4.0.1 の8.3.2のガイダンスがソルトに触れているかは未検証

なお v4.0 で加わった「鍵付きハッシュ」の要件は、カード番号（PAN）を保存するときのもので、パスワードの要件ではありません（PCI SSC の FAQ を検索結果で確認）。

パスワードのハッシュ化と暗号化の違い

X上では、初心者向けにこんな説明が広く読まれていました。暗号化は鍵で元に戻せるが、ハッシュ化は戻せない。password123 をハッシュ化すると全く違う文字列になる。戻せないのにログインをどう判定するのかといえば、入力されたパスワードを登録時と同じ方法でハッシュ化し、保存値と照合すればよい。

ここまでは正しい出発点です。ただ「ハッシュ化したから安全」で止まると、事故は防げません。足りないのは2点です。

・ソルト：パスワードごとに違う乱数を混ぜる。ないと同じパスワードは同じ値になり、事前計算の表（レインボーテーブル）で一度に引かれる。使い回している会員も値の一致で一度に分かる
・コスト：1回の計算をわざと重くする。SHA-256 のような速いハッシュは、総当たりや辞書攻撃で1秒に何百万回も試せる

「登録時と同じ方法で」の中身も、実装では注意が要ります。Argon2id や bcrypt の保存値には、方式・コスト・ソルト・ハッシュがひと続きの文字列で入っています。照合では、この文字列と入力をライブラリの verify 関数に渡すだけで、ソルトを自分で取り出して計算し == で比べる実装は書きません。比べ終わるまでの時間が一致した位置で変わると、手がかりを与えるからです。argon2-cffi が使う libargon2 の比較関数は、全バイトを最後まで比べる一定時間の実装でした（ソースで確認）。

速いハッシュでは足りない理由を実測する

1コアの Python で、パスワード1件のハッシュ計算が1秒に何回できるかを測りました。2026年10月17日、Xeon 2.1GHz・Python 3.13.16・argon2-cffi 25.1.0・bcrypt 5.0.0 です。実際に実行したコードは次のとおりです（pip install argon2-cffi==25.1.0 bcrypt==5.0.0 の後に python3 rate.py）。

import hashlib, time, bcrypt
from argon2 import PasswordHasher

def rate(f, n):
    t = time.perf_counter()
    for _ in range(n):
        f()
    return n / (time.perf_counter() - t)

pw = b"password123"
ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1)
print("SHA-256      :", round(rate(lambda: hashlib.sha256(pw).digest(), 1_000_000)), "回/秒")
print("Argon2id     :", round(rate(lambda: ph.hash(pw), 20), 1), "回/秒")
print("bcrypt(10)   :", round(rate(lambda: bcrypt.hashpw(pw, bcrypt.gensalt(10)), 20), 1), "回/秒")
print(hashlib.sha256(pw).hexdigest() == hashlib.sha256(pw).hexdigest())  # True: 同じ値
print(ph.hash(pw) == ph.hash(pw))                                        # False: ソルトで毎回違う

SHA-256 と Argon2id の差は約5万倍でした。これは1コアの CPU の数字で、GPU を並べる攻撃者の速度ではありません。それでも、同じ機械で試せる推測の数が5万分の1になる、という比は変わりません。陽性対照として、SHA-256 は同じ入力で毎回同じ値、Argon2id はソルトで毎回違う値になることも確かめています。

暗号化の側も測りました。AES-256-GCM で10万件を暗号化しておき、同じ鍵で全件を復号すると0.07秒でした。暗号の強さは関係なく、鍵と復号の手順が手に入れば、この速さで全件が戻ります。

パスワードのハッシュ化の推奨値：OWASPとNIST

OWASP Password Storage Cheat Sheet（2026年10月17日時点の公式リポジトリ）は、「ほぼすべての場合、パスワードは暗号化でも平文でもなく、現代的な適応型ハッシュでハッシュ化する」としています。暗号化を使うのは、他のシステムへのログインに元のパスワードが要るような例外だけで、その場合も OpenID Connect などで保存しない設計を先に探すよう書いています。

NIST SP 800-63B-4（2025年8月）の3.1.1.2は、パスワードを「オフライン攻撃に耐える形」で保存することを求めています。公式の原稿リポジトリで確認した要点は次の3つです。

・ソルトを付け、パスワードハッシュ方式でハッシュ化する（SHALL）。ソルトは32ビット以上
・コストは性能を損なわない範囲でできるだけ高くし、計算機の進歩に合わせて上げる（SHOULD）
・検証側だけが知る秘密鍵で鍵付きハッシュか暗号化をもう1段かける（SHOULD）。鍵はハッシュと別に、HSM など保護された領域に置く

3つ目がペッパーです。OWASP も、ペッパーはハッシュと同じ場所に置かず、シークレット保管庫か HSM に置くとしています。DB だけが漏れた場合は、推測を試すことすらできなくなります。ペッパーを替えるには全員のパスワード再設定が要る点も同じく書かれています。鍵をどこに置けば守れるかは、連載の次回で扱います。

対策：照合の実装と、暗号化からの移行

照合と作り直しは、ライブラリの関数に任せます。次のコードは実行して出力を確かめたものです（argon2-cffi 25.1.0）。

from argon2 import PasswordHasher
from argon2.exceptions import VerifyMismatchError

ph = PasswordHasher(time_cost=2, memory_cost=19456, parallelism=1)
stored = ph.hash("password123")          # 登録時：この文字列だけを保存する
print(stored)

try:
    ph.verify(stored, "password124")     # ログイン時：保存値と入力を渡すだけ
except VerifyMismatchError:
    print("不一致")
print(ph.verify(stored, "password123"))

new_ph = PasswordHasher(time_cost=3, memory_cost=19456, parallelism=1)
print(new_ph.check_needs_rehash(stored)) # コストを上げたら True → 次のログインで作り直す

出力は $argon2id$v=19$m=19456,t=2,p=1$<ソルト>$<ハッシュ>・不一致・True・True でした。コストを上げたら、ログインに成功したときに check_needs_rehash を見て、その場でハッシュを作り直して保存します。

今のシステムの保存方式ごとに、移行の手順は変わります。

漏えいの告知を受けた利用者の側の備え（使い回しの洗い出し）は、メルカリ情報漏洩の主張の記事 にまとめています。

包む方式（OWASP の言う Layering）は、元のパスワードを知らずに全件を一度に強くできますが、二重のハッシュは単体より割れやすくなることがあるため、次のログインで置き換えるまでのつなぎです。暗号化からの一括変換は、平文が一時的にメモリに載るので、ログを残さない隔離した処理で行うのが無難です（当サイトの判断）。

影響を受けるシステムの見分け方

保存値の形で、影響範囲をおおよそ見分けられます。

コード側では、保存処理の周りに encrypt・decrypt・AES・Cipher があるか、パスワードを画面やメールで本人に返す機能があるかを見ます。パスワードを「教えられる」システムは、元に戻せる形で持っています。

参照ソース

• OWASP Password Storage Cheat Sheet（公式リポジトリ OWASP/CheatSheetSeries の原稿で2026-10-17に確認）
• NIST SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management（2025年8月）3.1.1.2 Password Verifiers（公開ページは開けず、公式原稿リポジトリ usnistgov/800-63-4 の同じ節で確認）
• PCI SSC FAQ 1253「Does hashing of passwords meet the intent of PCI DSS Requirement 8.3.2?」（この環境から開けず、検索結果の本文で確認）
• RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications（パラメータの定義）
• ソースネクスト「当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ」2026-10-15（当サイトの環境からは開けず、検索結果に載った本文で確認）