bcrypt コスト係数計算機 | 実機ベンチマークで安全と速度の境目を決める

OWASP の推奨や別サイトの早見表は便利ですが、コンテナ化された本番サーバー、ARM の Raspberry Pi、x86 の開発用ノート、それぞれで bcrypt の挙動は変わります。このページではあなたが今開いている端末そのもので cost 4 から指定値までを順に走らせ、ログイン処理に許容できる時間に収まる最大の係数を選び出します。

💡 このツールについて

bcrypt のコスト係数は 1 つ上げるごとに必要な計算量が 2 倍になります。cost 10 で 50 ms かかる端末なら cost 12 で約 200 ms、cost 14 で約 800 ms。理論上はキレイな指数関数ですが、現実には ARM の SoC、Docker のスロットリング、AWS Lambda のコールドスタートなど、係数表が想定していない要因が必ず効いてきます。

このツールは bcryptjs を端末側で 1 cost ずつ実行し、その所要時間を一覧表示します。目標として入力した時間（一般的な Web ログインなら 200〜350 ms 程度）に収まる中で最大の cost を「推奨」として強調し、コピーすればすぐデプロイ設定に貼れる $2b$NN$ プレフィックスを生成します。8 秒を超えた cost より上は暴走防止のため自動で打ち切ります。

入力したサンプル文字列は計測のためにブラウザ内で bcrypt.hash() に渡されるだけで、外部へ送信されません。実運用の本物パスワードを貼り付ける必要はなく、デフォルトのダミー文字列でかまいません。

🧐 よくある質問

Q. コスト係数は実際いくつにすべき？ A. 最終的にはハードウェアとアクセス量で決まります。2024〜2025 年時点での OWASP Password Storage Cheat Sheet の目安は cost 10 が下限、12 が推奨ライン。ログインピーク時に CPU を食い潰さないことを優先するなら、目標 250 ms 程度で実測して収まる最大値を採用するのが安全です。

Q. 開発用 Mac で測ると速い／本番 Linux サーバーは遅い、どっちを信じる？ A. 本番の係数を本番で決めるのが原則です。Mac は M シリーズの並列演算が強く、Linux x86 のシングルコア計算より bcrypt が速く出ることがあります。可能なら ssh 越しに同じインスタンスタイプの一時 EC2 / Cloud Run / Fly.io でブラウザを開いて、このツールを通せば近い数字が得られます。

Q. なぜ最初の数 cost だけ妙に時間がかかる、または逆に短く出る？ A. ブラウザの JIT (V8) ウォームアップ、メモリ確保、esm.sh からのモジュールロード時間が初回ハッシュに乗ります。表で順位の判断を変えたいときは、もう一度ベンチマークを実行して 2 回目以降の値を見ると安定します。

Q. cost を上げてからログインが急に遅くなった、戻したい A. 既存ハッシュは cost を埋め込んで保存されているので、新しい cost でハッシュし直すまで古い cost のままです。ユーザーが次回ログインしたタイミングで再ハッシュする「乗り換えロジック」を入れておくと、サービス全体を一気に重くせずに段階的に上げられます。

Q. Argon2id ではなく bcrypt のままで良い？ A. 新規システムなら Argon2id が第一推奨です。ただし bcrypt は 1999 年から枯れているライブラリで、Active Directory / レガシー Rails / PHP の password_hash() 既定など互換性が要求される場面では今でも実務的な選択です。本ツールはその「すでに bcrypt で運用している」前提でコストを決めるためにあります。

📚 豆知識

bcrypt の cost 係数は対数表現で、$2b$12$ のように 2 桁数字で保存されます。この NN 部分はハッシュ文字列自体に焼き込まれており、検証時にライブラリは保存されている cost を読み取って同じラウンド数で再計算します。つまり cost を引き上げる移行期は、$2b$10$... の旧ハッシュと $2b$13$... の新ハッシュが DB に混在しても問題なく検証できます。

国内 Web 開発文脈では「bcrypt の cost 10 で十分」という古い記事が長く検索結果上位に残っていましたが、これは 2013〜2015 年頃の Intel Haswell 世代を基準にした目安でした。AWS Graviton や Apple Silicon の登場でハッシュスループットは数倍になっており、同じ cost のまま運用しているとブルートフォース耐性は実質的に薄まっています。プロダクションのハードウェアが変わるタイミングで一度コスト係数の妥当性を見直すのが、bcrypt と長く付き合うコツです。