bcryptジェネレーター

bcryptは、今でもパスワード保存の安全な選択肢の1つです。意図的に低速で、saltを自分で導出し、調整可能なcost parameterによってハードウェアの進歩に合わせて強度を上げられます。このジェネレーターは、平文パスワードから規格準拠のbcrypt hashを生成します。テストユーザーをseedしたり、アカウントを別システムへ移行したり、users.passwordカラムに保存された既存hashと値を比較したりするときに使えます。

bcryptでパスワードをhash化する方法

  1. 1

    平文パスワードを入力

    最大72 bytesです。bcryptはそれ以降を黙って切り捨てます。

  2. 2

    cost factorを選ぶ

    10が現在のdefault、12は新規システムで一般的、14はかなり慎重な設定です。+1ごとにhash時間はおおよそ2倍になります。

  3. 3

    random saltを生成

    16 bytesのsaltを暗号学的RNGから取得し、結果のhash文字列へ埋め込みます。

  4. 4

    hashをコピー

    出力は `$2b$12$...` のような自己記述的な文字列で、version、cost、salt、digestを含みます。

bcrypt hashの構造

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  salt (22 Base64 chars)  digest (31 Base64 chars)
  |   cost (2 digits, 4-31)
  version (2a, 2b, 2y — all bcrypt)

文字列全体は60文字です。VARCHAR(60) または CHAR(60) 型のカラムが標準的なschemaです。

cost factorの推奨

Cost hash 1回の目安時間(2024 CPU) 用途
10 ~80 ms legacy default、まだ許容範囲
12 ~300 ms 現在の推奨baseline
13 ~600 ms より高securityなapps
14 ~1.2 s 非常に慎重。login delayが目立つ

1増えるごとにwork factorは2倍になります。ログイン待ち時間を500 ms未満に抑えることが重要なら、10-12にとどめます。

version byte: 2a vs 2b vs 2y

  • $2a$ — 1999年の元の仕様。多くのlibraryが2a hashを出力します。
  • $2b$ — crypt_blowfishのtruncation bugを修正した2014年改訂。新しいhashでは推奨されます。
  • $2y$ — PHP固有のtagで、機能的には $2b$ と同等です。

3つはいずれも相互にverifyできます。違うのはhash文字列内のtagだけです。

bcryptが防ぐもの

  • rainbow tables — hashごとに固有のsaltがあるため、事前計算lookupを無効化します。
  • GPU/ASIC cracking — Blowfish key scheduleはmemory-boundでGPUに不向きです。Argon2ほどGPUに厳しくはありませんが、brute forceはまだ遅くできます。
  • database leaks — brute forceなしに、hashから平文を復元することはできません。

bcryptが防げないもの: 弱いパスワード(最小長を設定し、breach listsと照合する)、credential stuffing(second factorを使う)、phishing。

72-byte制限

bcryptはパスワードの最初の72 bytesだけを使います。長い入力は黙って切り捨てられます。このため、多くのlibraryでは、bcryptへ渡す前にSHA-256でパスワードをpre-hashすることを勧めるようになっています。現代的な代替(Argon2、scrypt)にはこの制限がありません。

よくある質問

パスワード保存用途では、cost ≥ 12なら安全です。OWASPも今なお受け入れ可能なalgorithmとして挙げています。新規システムではArgon2idが推奨されますが、既存のbcrypt hash移行は優先度の低い懸念です。

hashごとにsaltがrandom生成されるためです。verify時は保存済みhashからsaltを取り出し、送信されたパスワードを同じsaltで再hashして比較します。

ほとんどのlibraryはそれを公開していません。理由も明確です。予測可能なsaltは目的を台無しにします。libraryが生成するsaltを使うのが安全な道です。

はい。work factorは対称です。cost-14のhashをverifyするには、cost-10のhashの16倍の時間がかかります。ログイン処理能力を考えて調整してください。

関連ツール