日本のWeb開発では今もRuby on Rails(devise)やレガシーなJavaの認証基盤でbcryptがデフォルトのまま使われているケースが多く、Argon2への移行は他の地域に比べて緩やかに進んでいる。2015年のPassword Hashing Competitionで優勝し、OWASPがbcryptより優先すべきと推奨しているにもかかわらず、既存システムの認証周りを触ることへの慎重さ——本番のログイン基盤を壊すリスクを避ける文化——が、新規サービスでの採用を後押ししつつも既存システムの置き換えを遅らせている。
なぜ時間だけでなくメモリが重要なのか
BcryptやPBKDF2は計算時間を遅くするだけです。Argon2はさらに、1回の試行ごとに設定可能な量のRAMを確保することを強制します——これがmemory-hard関数と呼ばれる性質です。クラウドで借りたGPUファームは単純な計算を安価に並列化できますが、大量のメモリへの同時アクセスを並列化するのははるかにコストがかかります。メモリは計算コアと違い、1枚のカードあたり物理的に限られているためです。
3つのバリアント:d、i、id
- Argon2d — メモリアクセスがパスワード自体に依存し、GPUへの耐性は最大だが、理論的にはサイドチャネル攻撃の余地がある。
- Argon2i — メモリアクセスがパスワードに依存しないため、その弱点は塞がれるが、GPU耐性はやや落ちる。
- Argon2id — 計算の異なる段階で両方の戦略を組み合わせる。RFC 9106が推奨し、PHPの
PASSWORD_ARGON2IDを含め、多くの実装のデフォルトになっている。
3つの独立したパラメータ
bcryptの単一のcost factorと違い、Argon2はメモリ、反復回数、並列度を個別に調整できます。これは実務上意味があります:メモリが限られたサーバーレス関数では反復回数を増やして補い、RAMに余裕がある専用認証サーバーでは逆の調整ができるからです。
なぜこれが必要か
- MD5や単純なSHA-256の代わりに、新しい認証システム向けに現代的なアルゴリズムを選ぶ。
- Argon2がレンタルGPUや暗号通貨マイニング用ハードウェアでの攻撃を特にコスト高にする理由を理解する。
- セキュリティ監査の一環として、bcryptやPBKDF2からの移行を計画する。
並列度の落とし穴
並列度は一見「タダの得」に見える——スレッドを増やせばマルチコアサーバーでのハッシュ処理が速くなる。しかし同じマルチコアハードウェアを持つ攻撃者も、試行ごとに全く同じ速度向上を得てしまう。並列度をサーバーの実際のコア数に合わせるのは安全だが、「念のため」に上げることは攻撃者に比例した割引を与えるだけだ。