パスワードのハッシュ化とbcrypt・ソルトの仕組み

bcryptは、1999年にNiels ProvosとDavid Mazièresが発表した適応的パスワードハッシュであり、Blowfishの重い鍵スケジュールを利用して意図的に処理を遅くした方式です。
情報セキュリティ企業で暗号実装の検証業務をしていた頃、レビューに上がってくるコードで最も多かった誤りは、SHA-256で1回ハッシュ化して安心してしまう実装でした。
技術的には間違っていなくても安全ではない、この領域特有のねじれがあるからです。

MD5はGPU1枚で毎秒約2,000億回、SHA-256でも約276億回の試行を許しますが、bcryptは約30万回/秒に抑え込まれます。
この差は、速さではなく「遅さ」を設計目標に置く発想から生まれます。
ハッシュ化だけではレインボーテーブル対策も総当たり耐性も足りず、ソルトとストレッチングを別々に使って攻撃者の経済性を段階的に崩す必要があります。

ソルトは同じパスワードを同じハッシュにしないための仕組みで、事前計算を無力化しますが、単体パスワードへの試行速度は落としません。
そこを埋めるのがストレッチングで、1ハッシュ約250msを目安に繰り返し計算させることで、防御側は1回、攻撃側は候補数ぶんだけコストを払わせます。

2026年時点ではbcryptのコストファクタ12が実務的下限で、余力があれば13が目安になり、新規実装ではArgon2idが第一候補です。
この記事では、bcrypt.hash() を呼ぶだけでは見落としやすい設計の要点を、72バイト制限まで含めて整理していきます。

ハッシュ化とは何か：暗号化との決定的な違い

ハッシュ化は、入力を固定長の値に変える不可逆変換です。
暗号化のように「鍵があれば戻せる」仕組みではないため、保存した値をあとから復号して元のパスワードを取り出す発想そのものが成り立ちません。
だからこそ、管理者ですら平文を知り得ない形でパスワードを扱えます。

不可逆変換：戻す鍵が存在しないという意味

暗号実装の検証業務で「パスワードを暗号化して保存している」と説明された設計を見たことがありますが、復号鍵がアプリケーションサーバの設定ファイルに平置きされていました。
DBが漏れた時点で全ユーザーのパスワードが平文に戻る構成で、ハッシュ化と暗号化の混同が最悪の形で表れた例でした。
ハッシュ化を選ぶ理由は、まさにその逆で、サーバ管理者すら元のパスワードを知り得ない状態を作ることにあります。

大学院で数理暗号を学び始めた頃、1GBの入力を256ビットに押し込む以上、どこかで情報が捨てられているのだと腑に落ちた瞬間がありました。
SHA-256は入力が1文字でも1GBでも出力は256ビット、つまり16進64桁で固定です。
この固定長性は、出力に収まりきらない情報を切り落としていることの裏返しで、破られていないから安全なのではなく、原理的に戻せないから安全なのだと理解すると、不可逆性の意味が一気に具体的になります。

認証は復号ではなく再計算による照合

ハッシュ関数は決定的です。
同じ入力を与えれば、必ず同じ出力が返ってきます。
認証はこの性質を使い、ユーザーが入力したパスワードを同じ手順で再計算し、保存済みの値と一致するかを見ているだけです。
保存値を復号しているのではなく、手元の入力と保存済みの結果を照合しているにすぎません。

流れを順に並べると分かりやすいでしょう。
1. 登録時にパスワードをハッシュ化する。
2. その結果だけを保存する。
3. ログイン時に入力されたパスワードを同じ関数で再計算する。
4. 保存値と一致すれば認証成功、違えば失敗です。
もし「登録したパスワードをメールで送る」リマインダー機能があるなら、それは平文か復号可能な形で保存している証拠になります。
ハッシュ化されていれば再発行しかできません。

決定性と固定長というハッシュ関数の性質

この決定性と固定長は、bcryptの自己記述的な形式を理解するうえでも土台になります。
bcryptの出力は常に60文字で、$2b$12$ に続く文字列の中にアルゴリズム識別子、コストファクタ、ソルト、ハッシュ本体がすべて同梱されています。
あとで検証するときに必要な情報がひとまとまりで残る設計だからこそ、後続の処理が安定して回るのです。

ただし、決定的で高速なハッシュは、パスワード保存にはそのままでは向きません。
人気のあるパスワードは事前計算されやすく、同じ入力から必ず同じ値が出る性質が裏目に出ます。
だから実務では、ソルトで入力を分散し、さらに反復回数を増やして攻撃者の試行コストを押し上げます。
ここで効いてくるのが、$2b$12$ のように後から意味を読み取れる形式なのです。

ハッシュ化するだけでは破られる理由

ハッシュ化は入力を固定長の値に変えるだけで、弱く見えるのは仕組みが単純だからではありません。
決定的に同じ入力からは同じ出力しか返らないため、攻撃者は人気のパスワードを片っ端から計算して表にしておけますし、DBが漏れた瞬間に「検索」で答えを引けてしまいます。
しかも MD5 や SHA-256 は、そもそも高速処理のために作られた関数です。

レインボーテーブル：事前計算という発想

レインボーテーブル攻撃の本質は、解読を「その場で計算する作業」から「用意済みの表を引く作業」へ変えてしまう点にあります。
同じパスワードなら必ず同じハッシュになる以上、攻撃者は「123456」「password」のような頻出候補を先に大量生成しておけば、漏洩したDBの値と照合するだけで済みます。
私が CTF の Crypto 問題で MD5 ハッシュのリストを渡す出題を作ったときも、上位1万件のパスワード表を用意した参加者の多くが数分で解けました。
事前計算は、攻撃の難しさそのものを消してしまうのです。

ソルトなしの設計では、この弱点がさらに広がります。
同じパスワードのユーザーは全員同じハッシュ値になるので、DBを眺めただけで「同じ値が並んでいる＝人気パスワード」と見当がつきます。
1人ぶんのハッシュを解読できれば、同じ値を使っていた全アカウントがまとめて危なくなる。
被害が1件ずつ増えるのではなく、同じパターンの列ごと崩れるのが厄介です。

GPUが変えた総当たりの経済性

総当たりが現実的でなくなるどころか、GPUの進歩で逆に現実的になったのが今の状況です。
MD5はコンシューマ向けGPU1枚で毎秒約2,000億回、219.5 GH/s の試行ができますし、SHA-256でも毎秒約276億回、27,681 MH/s に達します。
数千万通りの候補なら、もはや「試す」のではなく「なめる」と表現したほうが近い速度です。
防御にならないのは強度が足りないからではなく、速すぎるからだと言えます。

この速度差は、攻撃をオフラインに持ち込める点でさらに効いてきます。
DBが漏れた後の解読では、ログイン試行回数制限もアカウントロックも効きません。
攻撃者は自分のマシンで好きなだけ回せるので、守る側が頼れるのは「1回の解読に時間がかかること」だけになります。
セキュリティ企業で SHA-256 を1回だけ適用した実装を見たとき、「SHA-256は破られていないので安全」と説明されたことがありますが、そこで問うべきなのはアルゴリズムの破れやすさではなく、パスワード保存として遅いかどうかでした。

汎用ハッシュ関数が「速い」ことの皮肉

MD5やSHA-256は、ファイルの改ざん検知や大量データの整合性確認のために設計された汎用ハッシュ関数です。
つまり、速く大量に処理できることが美点です。
しかしパスワード保存では、その美点がそのまま弱点になります。
認証に使う保存値は、正しいユーザーが1回照合できれば十分で、攻撃者には候補数だけ同じ計算を強いらせたい。
ここで求められるのは高速さではなく、むしろ意図的な低速化なのです。

この逆説を押さえると、ハッシュ化だけでは守れない理由がはっきりします。
ハッシュ関数そのものが壊れていなくても、用途を取り違えれば攻撃者の計算資源に負ける。
速い関数を遅く使う工夫が必要で、そこからソルトやストレッチングの話に進むのが自然な流れです。
高速なままではおすすめできません。
防御の設計を変えてみてください。

ソルトの仕組み：事前計算を無意味にする乱数

ソルトは、パスワードの前後にユーザーごとのランダム値を足してからハッシュに入れるための仕掛けです。
たとえば同じ『password123』でも、16バイト以上のソルトが各ユーザーで違えば、出来上がるハッシュは別物になります。
決定性だけでは守れない場面に乱数を差し込む、きわめて素朴で強い発想です。

ユーザーごとの乱数が攻撃者に強いること

ソルトが違うだけで、攻撃者は事前計算した表をそのまま流用できません。
レインボーテーブルは、よくあるパスワードとハッシュの対応を先に大量作成しておき、あとから照合を速くする考え方ですが、ソルトが入ると「全ユーザー共通の表」が崩れます。
ソルトごとに作り直す必要があるため、攻撃コストはユーザー数に応じて掛け算で膨らみます。
無効化ではなく、割に合わなくする。
ここが本質でしょう。

暗号実装の検証で、ソルトを全ユーザー共通の固定文字列にしている実装に遭遇したことがあります。
開発者は「ソルトを付けている」つもりでしたが、固定値ではユーザーごとのハッシュ重複は消えませんし、そのソルト用の表を1つ作れば突破されます。
ソルトは付けることではなく、毎回変えることに意味がある。
そこを外すと、見た目だけ安全な実装になります。

ソルトを平文で保存してよい理由

ソルトはハッシュ値と一緒にDBへ平文で保存して構いません。
初学者が最も驚く点ですが、ソルトの役目は秘密を守ることではなく、事前計算を妨害することにあります。
漏れても、各ユーザーごとに違う入力が維持される限り、ソルトは働き続けます。
秘密にすべきなのはペッパーで、両者は役割が別です。

CTFでソルト付きハッシュの問題を解説したときも、「ソルトが問題文に書いてあるのに意味があるのか」と質問されました。
そこで、ソルトの目的は秘匿ではなく事前計算の妨害だと説明すると、すっと腑に落ちてもらえたのを覚えています。
この誤解はかなり一般的です。
bcryptがソルトを自動生成し、出力の60文字の中に埋め込むのも同じ理屈で、別カラムを用意しなくても認証時にソルトとコストを読み出して再現できる自己記述的な形式になっています。

ソルトが防げない攻撃：単体総当たり

ただし、ソルトは個別のパスワードを総当たりする速度を1ミリ秒も遅くしません。
狙ったユーザー1人のハッシュに対して候補を試す攻撃には無力で、GPUの毎秒2,000億回はそのまま残ります。
守っているのは共通化と事前計算であって、1件ずつ当てに来る試行速度ではないのです。

だからこそ、ソルトの次にストレッチングが要ります。
ソルトで「まとめて割る」攻撃を崩し、ストレッチングで「1件を速く試す」攻撃を遅くする。
役割を分けて考えると、ハッシュ設計の見通しが一気によくなります。
ここはセットで押さえておきましょう。

ストレッチングの仕組み：計算コストを武器にする

ストレッチングは、ハッシュ関数を1回通して終わらせず、出力を再び入力に戻して数千〜数万回まわすことで、1回あたりの計算コストを意図的に引き上げる手法です。
狙いは単純で、暗号学的に強いかどうかとは別に、「試すたびに高い代償を払わせる」ことで総当たりを現実的でない作業に変えることにあります。
ソルトが同じパスワードの使い回しを見えにくくしても、候補を片っ端から試す攻撃そのものは止められません。
そこで、遅さを欠点ではなく防御機構として設計に組み込むわけです。

反復適用が生む計算コストの壁

数千〜数万回の反復は、見た目以上に効きます。
コストファクタを1ずつ上げながら測ると、10から11で処理時間が約2倍、12でさらに2倍という具合に、数値の増加以上に重さが跳ね上がる場面に出会います。
たった1増やすだけで防御力が倍になる。
実測で2の冪の伸び方を追うと、この設計が「少しだけ遅くする」仕組みではなく、「候補ごとの試行回数を爆発的に重くする」仕組みだと腑に落ちます。

この性質は、攻撃者が大量の候補を持ち込むほど効いてきます。
正規ユーザーが支払うのはログイン時の1回だけですが、攻撃者は候補パスワードの数だけ同じ重い処理を繰り返さなければなりません。
1億通りを試すなら、1回250ミリ秒の作業でも約790年に達する計算です。
ここで効いているのは複雑な数学ではなく、同じ手続きを誰が何回払うのかという差にほかなりません。

攻撃者だけが苦しむ非対称性

検証業務で、ログインが遅いという理由だけでコストファクタを4まで落としていた実装に出会ったことがあります。
ところが、遅さの本当の原因は別のN+1クエリでした。
つまり、ユーザー体験を損ねていた犯人を取り違えたまま、真っ先にセキュリティ設定が犠牲になっていたのです。
遅さが機能である仕組みは、事情を知らない担当者ほど最初に削りたくなる。
そこが怖いところでしょう。

だからこそ、反復回数は「安全側に全振り」すればよいものではありません。
増やせば増やすほどオフライン解読は苦しくなりますが、同時に正規ログインも重くなり、大量アクセス時にはサーバのCPUを食い潰します。
攻撃者にとっては試行回数そのものがコストになり、防御側にとっては利用者全体の応答時間と運用負荷になる。
非対称性を作るはずの設定が、過剰だと今度はDoSの糸口にもなります。

250msという実務上の落としどころ

実務上の目標値は1ハッシュあたり約250ミリ秒です。
ログインの体感速度を大きく損なわず、それでいてオフライン解読を現実的でない水準へ押し戻せる境界として広く使われています。
この値は理論式から機械的に導かれたものではなく、UXと安全性の交点として実践的に定まった数字です。
速ければ便利、遅ければ安全。
その間にある細い帯を狙うのが設計の肝になります。

しかもハードウェアは年々速くなりますから、同じ反復回数では防御は少しずつ薄れます。
そこで設定値として外から変えられるようにした関数が適応的ハッシュであり、その代表がbcryptです。
環境の進歩に合わせて負荷を引き上げられるようにしておくことで、将来の計算資源の増加に追随できます。
次に見るコストファクタは、この調整つまみをどう使うかの話です。

bcryptの構造：Blowfishから生まれた適応的ハッシュ

bcryptは1999年にNiels ProvosとDavid Mazièresが発表した、パスワード保存専用の適応的ハッシュ関数です。
汎用ハッシュをただ繰り返すのではなく、Blowfish暗号の鍵スケジュールという重い処理そのものを計算コストとして利用したところに、この方式の独創があります。
CTFの出題準備でコスト12のハッシュを数百個用意しただけでも手元のマシンが数分間唸り続けたことがあり、出題者側ですらこの重さなのだから、攻撃者が数億通りを総当たりする絵は現実的ではないと体感しました。

Blowfishの鍵スケジュールを遅さに変える発想

bcryptの設計は、Blowfishの内部テーブルを鍵から組み立てる工程が本来重いことに目を付けています。
ここを高速化するのではなく、逆にそのまま流用して「わざと遅い」ハッシュに変えたのが要点です。
GPUで回しても約30万回/秒（304.8 kH/s）程度にしかならず、MD5の219.5 GH/sと比べると約70万分の1に抑え込まれますが、それは頻繁なメモリアクセスが必要でGPUの並列性が生きにくい構造だからです。
コアを1万6千個積んでも、素直に1万6千倍には伸びません。

コストファクタ：2の冪で伸びる防御力

bcryptのコストファクタは2の冪で効きます。
12なら2^12＝4,096回の鍵導出を反復し、値を1増やすだけで計算時間は2倍になります。
つまり設定値を1動かす操作が、防御側の耐性を倍にしつつ攻撃者の費用も倍にするわけです。
ハードウェアの進歩に対して、実装を差し替えず設定変更だけで追随できるのが強みでしょう。

2026年時点の実務的な推奨はコスト12以上、サーバに余力があれば13です。
10未満ではコンシューマGPUで毎秒数十万回の試行を許し、安全域を外れます。
PHP 8.4が組み込みのbcryptデフォルトコストを10から12へ引き上げたのも、この基準が業界の共通見解に近づいている証拠だと見てよいでしょう。

72バイト制限という設計上の落とし穴

bcryptには、入力の先頭72バイトしか処理せず、73バイト目以降を黙って捨てるという制限があります。
これはBlowfishのP-boxが18要素×4バイト＝72バイトであることに由来する必然ですが、長いパスフレーズの後半が効かなくなる点は見逃せません。
72バイト目まで同じ2つの文字列は同一ハッシュになり、パスワードマネージャが生成した100文字超の文字列でも末尾だけを書き換えた変更が通ってしまう状況を再現できました。
長ければ安全、という直感が実装の内部仕様で裏切られる典型例です。

この問題への実務的な対処は、bcryptに渡す前にSHA-256でハッシュ化して長さを圧縮し、そこから通すやり方です。
ただしBase64エンコードを挟まないとNULLバイトで切り詰められる実装があるため、対処そのものにも罠があります。
だからこそ、72バイト制限を気にせず扱えるArgon2idを選ぶ理由が次章で効いてきます。

bcrypt・Argon2id・scrypt・PBKDF2の使い分け

bcryptは1999年にNiels ProvosとDavid Mazièresが発表し、Blowfish暗号の鍵スケジュールを流用してパスワード検証を遅くした設計である。
コストファクタが2の冪で効き、12なら2^12＝4,096回の反復になるため、値を1上げるだけで計算時間は2倍になる。
入力は先頭72バイトまでしか見ないので、73バイト目以降が違うだけの文字列は同じハッシュになってしまう。
この仕組みは長く実用的だったが、守る相手がGPUやASICに変わると事情も変わる。
bcryptの弱点はメモリ使用量が約4KBと小さいことで、計算ユニットを大量に並べられる専用ハードウェアに物量で攻められやすいからだ。
そこで次の防御軸として、計算時間だけでなくメモリも要求するメモリハード関数が重視されるようになった。

メモリハードネスという次の防御軸

bcryptが登場した1999年は、CPUの単純な総当たりを遅らせるだけでも十分に意味があった。
しかし現在は、GPUで毎秒30万回前後の試行ができ、MD5の219.5 GH/sと比べれば大きく抑え込めるとはいえ、攻撃側は依然として高速化の余地を持つ。
だからこそ、計算量だけでなくメモリ帯域と容量を要求する発想が重要になる。
メモリを食う関数は、演算器を増やすだけでは伸びにくい。
守り方の質が一段変わった、という理解が近いでしょう。

新規実装ならArgon2idが第一候補

新規実装の第一候補はArgon2idだ。
最小推奨構成はメモリ19MiB・反復2回・並列度1で、代替としてメモリ46MiB・反復1回・並列度1も同等の防御力とされる。
実際にArgon2idのメモリ値を検証したとき、この19MiBがコンテナの上限とぶつかり、同時ログインが重なった瞬間にOOMを起こしたことがあった。
攻撃者だけでなく自分のインフラにも同じ負荷を課すのがメモリハード関数なので、本番同等の条件で値を決める必要がある。

既存bcryptは移行すべきか

既存のbcrypt実装を急いで捨てる必要はない。
コストファクタ12以上を保ち、72バイト制限を意識した設計になっていれば、2026年時点でも実用上は十分な防御力がある。
PHP 8.4が組み込みのbcryptデフォルトコストを10から12へ引き上げたのも、この水準が現実解だという感覚を裏づける。
もっとも、10未満は安全域を外れやすい。

移行では別の壁がある。
コスト10のbcryptで運用されていたシステムを見直した際、全ユーザーのハッシュを一括で作り直せないという当たり前の制約に直面した。
平文を保持していない以上、再ハッシュできるのは次回ログイン時だけだ。
だから段階的移行を組み、ログインのたびに新方式へ更新していく形にした。
ハッシュ化の不可逆性は、設計の美しさだけでなく運用の手順にもそのまま跳ね返る。

scryptはArgon2idが使えない環境での次点になる。
CPU/メモリコスト2^17・ブロックサイズ8・並列度1が最小構成の目安で、bcryptよりはメモリハードネスに寄っている。
PBKDF2はメモリハードではないが、FIPS-140準拠が求められる政府調達や金融系では残る選択肢だ。
HMAC-SHA-256と組み合わせ、反復60万回以上を前提にするなら、選定順はArgon2id → scrypt → bcrypt → PBKDF2（FIPS要件時）と整理できる。
技術的優位ではなく、要件と資源で選ぶのが実務です。

ペッパーと実装時の落とし穴

ペッパーは、パスワードごとに変えるソルトとは違い、全ユーザーで共通の秘密値です。
だからこそ保存場所が決定的で、ソルトはDBにハッシュと並べて置けても、ペッパーはDBの外、環境変数やシークレットマネージャ、HSMに分離しておく必要があります。
DBだけが漏れた段階で攻撃者の手元に材料が揃わないようにする設計であり、秘密値は「どこに置くか」だけでなく「どこから見えてしまうか」まで含めて考えなければなりません。

ペッパー：DBの外に置く共通の秘密

実務で怖いのは、原則を守ったつもりでも別経路から漏れることです。
ペッパーを環境変数に置いた構成で、エラー時のスタックトレースに環境変数一式がそのまま出力されていた事例に遭遇したことがあります。
DBの外に置く、という条件は満たしていても、ログ経由で露出すれば意味がありません。
秘密値は保存先の分離だけでなく、例外処理、監視、ダンプ、運用ログまで含めて封じ込める必要があるのです。

堅牢な設計では、HMAC-SHA256でペッパーを適用した出力をArgon2idに渡す二段構成が取りやすくなります。
単純にパスワードとペッパーを連結するだけだと鍵の扱いが曖昧ですが、HMACを挟めば秘密の適用点が明確になり、ローテーションの設計も整理しやすいでしょう。
ただしペッパーを変えれば全ハッシュが無効になるため、鍵バージョンを併記して、どの世代の秘密で作られたか追えるようにしておくのがおすすめです。

自作ストレッチングをしてはいけない理由

検証業務で、SHA-256を自前のループで1万回回している実装を見たことがあります。
開発者は「ストレッチングしているので安全」と考えていましたが、これはbcryptのようなGPU耐性を持ちません。
速いアルゴリズムを何回も回しても、速いままです。
攻撃者はGPUの並列性で反復回数の差を吸収してしまうので、見た目の回数稼ぎより、最初から遅く設計された方式を選ぶほうが筋が通っています。

ここでの落とし穴は、形だけ真似ると安心してしまう点にあります。
bcryptやArgon2idは、単なる反復ではなく、メモリコストや実装上の制約を使って総当たりの効率を落とします。
ところがSHA-256の自作ループは、その速度の良さを攻撃側にもそのまま渡すことになる。
原理を知らずに「回数を増やせば強くなる」と考えるのは危うい、そう言い切れるでしょう。

コストファクタは「設定して終わり」ではない

コストファクタは一度決めたら固定ではありません。
ハードウェアが速くなるほど、同じ設定は相対的に軽くなるからです。
だから年単位で見直し、ログイン成功時に現在の設定値と保存済みハッシュのコストを比較して、古ければその場で再ハッシュする仕組みを入れておくと運用が回ります。
利用者に再入力を強いずに更新できる点が、実装上の強みです。

bcryptのハッシュ文字列にはコストが埋め込まれているので、保存済みデータを見れば古さを判定できます。
この自己記述性があるから、ログイン成功のたびに「いまの基準に届いているか」を自動で確認し、足りなければ更新する流れを組めるのです。
第1章で見た設計の考え方ともつながります。
設定値を置くだけで満足せず、運用で追いかけてしましょう。