フロントエンドでのパスワードハッシュ生成：bcrypt vs crypto-js vs pbkdf2 vs scrypt-js

フロントエンドアプリケーションでユーザー認証を実装する際、パスワードの安全なハッシュ化は不可欠です。しかし、ブラウザ環境では適切なアルゴリズムとライブラリの選択が重要になります。ここでは bcrypt、crypto-js、pbkdf2、scrypt-js の4つのnpmパッケージを、実際の開発者の視点から比較します。

🔐 アルゴリズムの特性と目的

まず、各パッケージが提供する暗号アルゴリズムの基本的な性質を確認しましょう。

• bcrypt：パスワード専用に設計されたアダプティブハッシュ関数。内部でsaltを自動生成し、計算コスト（ラウンド数）を調整可能。
• crypto-js：汎用暗号ライブラリ。AES、SHA-256、HMACなど多数のアルゴリズムを含むが、パスワードハッシュにはPBKDF2やその他のKDF（鍵導出関数）を明示的に使う必要がある。
• pbkdf2：NIST標準の鍵導出関数。任意のハッシュ関数（例：SHA-256）と反復回数を指定して使用。
• scrypt-js：メモリ強度が高いアルゴリズム。ASICやGPUによるブルートフォース攻撃に対して特に強い。

⚠️ 重要な注意点：フロントエンドでパスワードをハッシュ化するのは、通常推奨されません。サーバーサイドでハッシュ化すべきです。ただし、特定のユースケース（例：完全クライアントサイドのアプリ、オフライン認証）ではフロントエンドハッシュが必要になる場合があります。

🧪 同期 vs 非同期：UIブロッキングのリスク

ブラウザ環境では、長時間実行される処理がUIをフリーズさせるため、非同期処理が必須です。

bcrypt（Node.js向けのネイティブバインディング版）は、ブラウザでは動作しません。代わりに、純粋なJavaScript実装である bcryptjs を使う必要がありますが、これは同期的であり、高コスト設定ではUIをブロックします。

// bcryptjs（同期的 — UIをブロックする可能性あり）
import bcrypt from 'bcryptjs';

const salt = bcrypt.genSaltSync(10);
const hash = bcrypt.hashSync('password123', salt);

crypto-js も同期的です。PBKDF2を使用する場合も同様です。

// crypto-js（同期的）
import CryptoJS from 'crypto-js';

const salt = CryptoJS.lib.WordArray.random(128/8);
const hash = CryptoJS.PBKDF2('password123', salt, {
  keySize: 256/32,
  iterations: 10000
});

pbkdf2 パッケージ（node-forge 由来のもの）は、Web Crypto API を利用した非同期実装を提供します。

// pbkdf2（非同期）
import { pbkdf2 } from 'pbkdf2';

pbkdf2('password123', 'somesalt', 10000, 32, 'sha256', (err, derivedKey) => {
  if (err) throw err;
  console.log(derivedKey.toString('hex'));
});

// Promiseベースの使用も可能（ドキュメント参照）

scrypt-js も非同期で動作し、プログレスコールバックをサポートします。

// scrypt-js（非同期）
import scrypt from 'scrypt-js';

const password = new TextEncoder().encode('password123');
const salt = new TextEncoder().encode('somesalt');

scrypt.scrypt(password, salt, 16384, 8, 1, 32).then((key) => {
  console.log(new TextDecoder().decode(key));
});

💡 結論：UIをブロックしたくないなら、pbkdf2 または scrypt-js を選ぶべきです。bcrypt（および crypto-js）は同期的で、高コスト設定ではUXを損ないます。

🛠️ 実装の容易さとAPI設計

Saltの扱い

• bcrypt / bcryptjs：saltを自動生成・埋め込み。検証時にsaltを別途保存不要。
• crypto-js：saltを自分で生成・保存する必要あり。
• pbkdf2：saltを明示的に渡す必要あり。
• scrypt-js：saltを明示的に渡す必要あり。

// bcryptjs：saltがハッシュ内に含まれる
const hash = bcrypt.hashSync('pass', 10);
// 後で検証
bcrypt.compareSync('pass', hash); // true

// crypto-js：saltを別管理
const salt = CryptoJS.lib.WordArray.random(16);
const hash = CryptoJS.PBKDF2('pass', salt, { iterations: 10000 });
// 検証時は同じsaltが必要

ハッシュの検証

• bcrypt は compare メソッドで簡単に検証可能。
• 他のライブラリでは、元のsaltを使って再度ハッシュを計算し、一致を確認する必要があります。

⚖️ セキュリティとパラメータ調整

推奨コスト設定

• bcrypt：ラウンド数10〜12（2024年現在）。
• PBKDF2：反復回数10,000以上（NIST推奨は最低10,000）。
• scrypt：N=16384, r=8, p=1 が一般的な起点。

ただし、フロントエンドでは計算リソースが限られているため、過剰なコスト設定は避けるべきです。ユーザー体験を損なうだけでなく、DoS攻撃のベクトルにもなり得ます。

🌐 ブラウザ互換性と依存関係

• bcrypt（公式パッケージ）：Node.js専用。ブラウザでは動作しない。代わりに bcryptjs を使う必要あり（重い）。
• crypto-js：純粋なJavaScript。古いブラウザでも動作。
• pbkdf2：現代のブラウザ（Web Crypto API対応）で最適化。古い環境ではポリフィルが必要。
• scrypt-js：純粋なJavaScript実装。Web Workerとの併用が推奨。

📌 ユースケース別の推奨

ケース1：完全クライアントサイドのパスワードマネージャ

• 要件：オフラインで動作、高いセキュリティ、UIフリーズ不可
• ✅ 推奨：scrypt-js
• 理由：メモリ強度が高く、非同期でプログレス表示可能。Web Workerで実行すればUIブロッキングゼロ。

ケース2：簡易認証付きの静的サイト（例：社内ツール）

• 要件：簡単な実装、軽量、中程度のセキュリティ
• ✅ 推奨：crypto-js + PBKDF2
• 理由：バンドルサイズが小さく、同期処理でも許容できるレベル。

ケース3：サーバーとの連携が可能なSPA

• 要件：本当はサーバーでハッシュしたいが、何らかの理由でフロントエンドで事前ハッシュ
• ✅ 推奨：pbkdf2
• 理由：Web Crypto APIを利用し、高速かつ非同期。標準ベースで将来性あり。

ケース4：Node.jsサーバーでの使用（参考）

• ✅ 推奨：bcrypt（ネイティブ版）
• 理由：高速で安定。ただし、これはフロントエンドの話ではありません。

🚫 避けるべきパターン

• bcrypt 公式パッケージをブラウザで使おうとしないこと。動作しません。
• crypto-js のMD5やSHA-1をパスワードハッシュに使わないこと。これらはKDFではなく、脆弱です。
• 低コスト設定（例：PBKDF2で100回）を使わないこと。すぐにクラックされます。

💡 最終的なアドバイス

1. 可能なら、パスワードハッシュは常にサーバーサイドで行いましょう。
2. フロントエンドでどうしても必要なら、非同期で動作し、UIをブロックしない pbkdf2 または scrypt-js を選びましょう。
3. saltは必ずランダム生成し、ハッシュと一緒に保存してください（bcrypt 以外の場合）。
4. Web Worker内でハッシュ処理を実行することで、メインスレッドのブロッキングを完全に回避できます。

// Web Worker内でscrypt-jsを使う例（main.js）
const worker = new Worker('hash-worker.js');
worker.postMessage({ password: '...', salt: '...' });
worker.onmessage = (e) => console.log(e.data.hash);

// hash-worker.js
importScripts('scrypt-js/umd/scrypt.js');
onmessage = (e) => {
  const { password, salt } = e.data;
  scrypt.scrypt(
    new TextEncoder().encode(password),
    new TextEncoder().encode(salt),
    16384, 8, 1, 32
  ).then(key => postMessage({ hash: key }));
};

セキュリティとユーザーエクスペリエンスのバランスを取ることが、フロントエンド開発者の責任です。適切なツールを選び、正しく実装しましょう。