bcrypt - Time-Tested Password Hashing

About 2 min read

bcrypt は、 1999 年に Niels Provos と David Mazières が設計した、 Blowfish 暗号をベースとするパスワードハッシュ関数です。 コストファクター (ワークファクター) を調整することで計算コストを指数関数的に 増加させられる設計が特徴で、ハードウェアの性能向上に合わせて セキュリティ強度を引き上げられます。 25 年以上にわたり広く使われ続けており、Argon2 が登場した現在でも OWASP の推奨リストで 2 番目に位置する信頼性の高いアルゴリズムです。

歴史的背景

bcrypt が登場する以前、 Unix システムでは DES ベースの crypt 関数が パスワードハッシュに使われていました。しかし 1990 年代後半には CPU の高速化により crypt の計算コストが不十分になり、辞書攻撃やブルートフォース攻撃が 現実的な脅威となっていました。 Provos と Mazières は OpenBSD プロジェクトの 一環として bcrypt を設計し、「将来のハードウェアでも安全であり続ける」 適応型ハッシュ関数という概念を確立しました。この設計思想は後の scrypt や Argon2 にも受け継がれています。

コストファクターの仕組み

bcrypt のコストファクターは 4 から 31 の整数で指定し、内部的には 2 のコスト乗回の反復処理を行います。コストファクターを 1 増やすと 計算時間が約 2 倍になります。

実務では、ログイン処理のレイテンシが許容範囲 (通常 250 ms - 1 秒) に収まる 最大のコストファクターを選択します。サーバーの CPU 性能に応じて 定期的にコストファクターを見直し、引き上げることが推奨されます。

ソルトの自動生成と保存形式

bcrypt は 128 ビットのソルトを 自動生成し、ハッシュ値と一緒に 1 つの文字列として保存します。 開発者がソルトの生成や管理を個別に実装する必要がない点が、実務上の大きな利点です。

Argon2 との比較

bcrypt と Argon2 の最大の違いは、メモリハードかどうかです。 bcrypt は CPU バウンドの関数であり、計算に大量のメモリを要求しません。 そのため、数千コアを持つ GPU で並列にハッシュ計算を実行する攻撃に対しては、 Argon2 ほどの耐性がありません。新規システムでは Argon2id が第一選択ですが、 bcrypt が既に導入されているシステムでは、コストファクターを適切に設定していれば 即座に移行する必要はありません。移行する場合は、次回ログイン時に 再ハッシュする方式が一般的です。 パスワード保存の全体設計は安全なパスワード管理ガイドで 解説しています。

72 バイト制限の注意点

bcrypt には入力パスワードが 72 バイトで切り捨てられるという制限があります。 UTF-8 エンコーディングでは日本語 1 文字が 3 バイトを消費するため、 日本語のみのパスワードでは実質 24 文字が上限です。英数字混在であれば 72 文字まで有効ですが、それを超える部分は無視されます。 この制限を回避するために、パスワードを事前に SHA-256 でハッシュしてから bcrypt に渡す手法がありますが、ヌルバイト問題などの落とし穴があるため 慎重な実装が必要です。パスワードポリシーの 設計時にはこの制限を考慮してください。password security books on Amazonで実装の詳細を学べます。

よくある誤解

「bcrypt は古いから危険」という認識は正確ではありません。 bcrypt 自体に 致命的な脆弱性は発見されておらず、適切なコストファクター (12 以上) で 運用すれば 2025 年時点でも十分な安全性を提供します。問題になるのは コストファクターが低すぎる (10 未満) 場合や、ライブラリのバグを含む 古い実装を使い続けている場合です。 パスワードハッシュの歴史的な変遷はパスワードの歴史と文化の 記事でも紹介しています。暗号の基礎は暗号化の基礎を 参照してください。