bcrypt ハッシュ解析 — `$2a$10$...` の algorithm / cost / salt / hash を分解表示

bcrypt ハッシュ文字列に何が含まれているか

bcrypt ハッシュは $2b$12$EXRkfkdmXn2gzds2SSitu.MW9.gAVqa9eLS1//RYtYCmB1eLHg6Gm のような 60 文字の文字列です。これをパースすると、算法バージョン (2b)・cost ファクター (12)・salt (22 文字)・ハッシュ (31 文字) の 4 セクションに分解されます。ハッシュ自体はパスワードを「元に戻せない」一方向の変換ですが、この文字列全体には攻撃者にとって有用な情報が含まれています。salt と cost が判明すれば、オフラインのブルートフォース攻撃 (辞書攻撃やレインボーテーブル) の準備が整います。

データベースのダンプや設定ファイルから漏えいした bcrypt ハッシュを「どんな形式か確認したい」と思うのは自然なことですが、そのハッシュ文字列をオンラインサービスに送信することは、salt と cost を外部に公開することと同義です。本ツールはテキストのパースのみを行い、bcrypt の計算 (ハッシュの検証や生成) は一切しません。

bcrypt ハッシュをオンラインツールに貼る場面のリスク

「この bcrypt ハッシュの cost を調べたい」「バージョンが 2a か 2b か確認したい」という目的で検索すると、bcrypt パーサーやデコーダーを名乗るサービスが出てきます。そこにハッシュ文字列を貼った場合、送信された文字列はサーバーのアクセスログに記録されます。bcrypt ハッシュはパスワードそのものではありませんが、salt と cost の組み合わせがあれば総当たり攻撃の効率が大幅に向上します。

より深刻なのは、本来の目的が「特定のパスワードがこのハッシュと一致するか照合する」つまり検証 (verify) である場合に、平文パスワードとハッシュを両方オンラインサービスに送ってしまうパターンです。テスト用のハッシュ文字列でも、それが本番 DB 由来であればユーザーのパスワードを第三者に渡すことになります。

文字列パースのみ: ブラウザ内で完結する仕組み

本ツールは bcrypt ハッシュ文字列の構造をテキストパースするだけです。Blowfish 鍵スケジュールの計算は行いません。パースロジックは正規表現と文字列のスライシングのみで、外部ライブラリへの依存もなく、ネットワーク通信は発生しません。cost の実行時間目安は、2026 年標準サーバー (最近の M シリーズ Mac の単一コア性能を基準) でのおおよその値を静的に計算して表示しています。

入力されたハッシュ文字列はブラウザのページメモリにのみ存在し、DevTools の Network タブを開いた状態でハッシュを貼り付けても送信リクエストは一切発生しません。ページを離れれば入力内容は消去されます。

cost ファクターの確認を定期メンテナンスに

bcrypt のセキュリティ強度はハードウェアの進化に伴って低下します。cost = 10 は 2011 年頃の推奨値でしたが、2026 年時点では攻撃者側 GPU の計算速度が大幅に向上しており、OWASP は新規実装では cost ≥ 12 を推奨しています。自社システムの bcrypt ハッシュがどの cost で保存されているかを本ツールで確認し、cost の引き上げが必要かどうかを定期的にチェックする使い方が効果的です。既存ユーザーのハッシュは次回ログイン時に再ハッシュするパターンが一般的です。

Modified Blowfish と EksBlowfishSetup — bcrypt の内部構造

bcrypt は 1999 年に Niels Provos と David Mazières が USENIX で発表したアルゴリズムで、Blowfish 暗号の鍵スケジューリングを意図的に重くした「Eks (Expensive key schedule) Blowfish」を中核に据えています。標準の Blowfish が鍵から P-array と 4 つの S-box を 1 回だけ初期化するのに対し、EksBlowfishSetup は salt とパスワードを交互に使って 2^cost + 1 回もこの初期化を繰り返します。cost を 1 増やすと初期化回数が倍になり、計算時間も倍になる — これが「コストパラメータが指数的に効く」と説明される根拠です。

最終ステップでは初期化済みの Blowfish で固定の文字列 OrpheanBeholderScryDoubler (24 バイト) を 64 回 ECB モードで暗号化し、その結果が 23 バイトの hash として base64 エンコードされます。base64 のアルファベットも通常の RFC 4648 ではなく ./A-Za-z0-9 という bcrypt 専用のもので、+ / を . / に置換した独自仕様です。本ツールはこの hash 部分を 31 文字として表示しますが、その base64 を逆変換すると 24 バイトの末尾 1 バイト (パディング) を含まない 23 バイトの raw output が得られます。

2a 2b 2x 2y のバージョン分岐と相互運用上の罠

bcrypt のバージョン文字列 2, 2a, 2b, 2x, 2y は単なる識別子ではなく、特定の実装バグや仕様修正の歴史を反映しています。2 (1999) はオリジナル、2a (2011) は文字列終端の扱いを明確化したもの、2x は PHP 5.3.7 の crypt_blowfish バグ互換 (8 ビット目を符号付きで扱ってしまう問題)、2y はその bug fix 版、2b (2014) は 255 文字を超えるパスワードを正しく扱う OpenBSD 実装の修正版です。2x のハッシュは「同じパスワードでも文字コードが 0x80 以上の文字を含むと別ハッシュになる」ため、レガシーシステムからの移行で意図しない認証失敗を起こします。

bcrypt の入力長は内部的に 72 バイトで切り詰められる、というあまり知られていない制約があります。これは Blowfish の鍵長上限が 448 ビット (= 56 バイト) ですが、bcrypt は周回シフトで 72 バイトまで受け入れる設計のためです。72 バイト超のパスワードは 73 バイト目以降が完全に無視され、password123...(73 バイト目以降の任意文字列) が同じハッシュになります。パスフレーズ系のアプリケーションで「同じ最初の 72 文字が一致すれば認証通過」というセキュリティホールを作るので、長い入力を扱う場合は SHA-256 などで前処理して 32-64 バイトに正規化してから bcrypt に渡すのが定石です。前処理用の SHA-256 / SHA-512 は hash-generate でブラウザ内のまま算出でき、移行候補としてユーザーに新しいパスワードを促す場合は password-strength-check で bcrypt 投入前に強度を確認してから登録するワークフローに繋げられます。