パスワードの保存 — 漏れたあとに、何日持ちこたえられるか

What — 漏れたハッシュは、どう元に戻されるか

パスワードを保存するときにハッシュ化するのは、DB が漏れてもパスワードそのものを渡さないためです。ハッシュ関数は一方向で、値から入力を計算できません。

ところが、計算できないことと、見つけられないことは別です。

ハッシュ関数

入力から固定長の値を計算する関数。同じ入力は同じ値になり、値から入力は計算できない。

ソルト

利用者ごとに異なるランダムな値。パスワードに足してからハッシュ化し、同じパスワードでも違う値にする。

ストレッチング

ハッシュの計算を意図的に重くすること。1回の照合に時間やメモリを要するようにする。

ペッパー

DB とは別の場所に置く秘密の値。DB だけが漏れても、それが無ければ照合できない。

速さは、利用者ではなく攻撃者の味方

SHA-256 のような汎用のハッシュ関数は、速く計算できるように作られています。ファイルの改ざん検知や署名では、それが長所です。

パスワードの保存では、この速さが逆に働きます。

• 利用者がログインするとき: 1回計算するだけ。1回が1ミリ秒でも1秒でも、体感はあまり変わらない
• 攻撃者が総当たりするとき: 数十億回、数兆回と計算する。1回あたりの時間が、そのまま所要時間に掛かる

1回あたりの計算を重くすると、利用者の負担はほとんど変わらず、攻撃者の負担だけが桁違いに増えます。 パスワード用のハッシュ関数（Argon2id、scrypt、bcrypt）は、この重さを意図して設計され、重さを調整できるようになっています。

Why — なぜ「ハッシュ化」だけでは足りないのか

パスワードの保存で守りたいのは、流出を防ぐことだけではありません。流出は、脆弱性、内部不正、バックアップの紛失など、いくつもの経路で起きえます。

だから本当に問うべきは、**「漏れたあと、どれだけ時間を稼げるか」**です。

稼いだ時間で、サービス側は流出に気づき、全員にパスワードの変更を求め、使い回しの危険を知らせられます。数日で大半が割れるなら、知らせる前に被害が広がります。 数年かかるなら、ほとんどの会員は間に合います。

password = 'hunter2'

自分で組み合わせない

パスワード用のハッシュは、実績のあるライブラリの関数を、その推奨設定で使うのが基本です。

• ソルトの生成、ハッシュ値の文字列への埋め込み、照合時の比較は、ライブラリが面倒を見る
• 比較を == で自前に書くと、一致した文字数によって処理時間が変わり、手がかりを与えることがある
• bcrypt は入力の先頭72バイトまでしか使わないなど、関数ごとの制約がある。長い入力を前処理する場合は、その方法もライブラリの推奨に従う

重さの設定は、ログイン1回あたりに許容できる時間（数十〜数百ミリ秒）を目安にし、計算機が速くなるのに合わせて定期的に引き上げます。設定はハッシュ値の文字列に含まれるので、次のログインのときに新しい設定で作り直すことができます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。