パスワードは何文字あれば安全？8・12・15・16・20・32文字を比較

数字ごとに「根拠の種類」が違う

6つの数字のうち、公開標準において明示的な根拠を持つのは8・12・15の3つです。まずここを分けておくと、以降の議論が整理されます。

• 8文字：NIST SP 800-63B-4 と OWASP が、多要素認証（MFA）の一部として用いるパスワードに許容する下限です。単一要素認証では認められません。
• 12文字：PCI DSS v4.0 の要件8.3.6 が、単一要素認証で用いるパスワードに要求する水準です。技術的に対応できない場合の8文字への引き下げは経過措置で、2025年3月31日以降は12文字が必須とされています。
• 15文字：NIST と OWASP が単一要素認証に要求する下限です。Chrome のパスワード生成器が既定で採用する長さでもあります。生成器が提案した値をそのまま受け入れれば、単一要素認証の水準を満たします。

16・20・32には、これに相当する明示的な根拠を確認できませんでした。慣行、経験則、あるいは特定の実装の既定値として流通している数字です。後述するとおり、これらの数字が「誤っている」わけではありません。ただし条件を伴わずに提示されると、8文字との差がなぜ必要なのかを説明できません。

なお、同じ「単一要素認証」という状況に対して NIST は15文字、PCI DSS は12文字を求めており、主要な標準の間に3文字の差があります。この差は、想定する保存方式と攻撃予算の範囲内で説明できます（第5節）。

理論強度：長さは線形に効き、文字種の追加は効率が悪い

文字数と文字種から決まる理論エントロピーは表1のとおりです。文字数はエントロピーに対して線形に効き、1文字増えるごとに英数62種で約5.95ビット、記号込み94種で約6.55ビット増えます。

表1：文字数と文字種から決まる理論エントロピー（ビット）

文字集合の拡大は、同じ1文字分の追加より効果が小さくなります。英数62種から記号込み94種への拡張は、8文字の場合で4.8ビット、0.8文字分に相当するにすぎません。長さを1文字伸ばすほうが、記号を加えるより効率がよいのです。記号の要否についてはパスワードに記号は本当に必要かで詳しく扱っています。

8文字と15文字の差は41.7ビット、倍率にして約3.5兆倍です。両者を同じ「安全」という語で扱えないことは、この一点からも明らかです。Diceware方式の単語リスト（7,776語、1語あたり12.93ビット）と比べると、ランダムな英数8文字（47.6ビット）は3.7語、15文字（89.3ビット）は6.9語に相当します。ランダムな英数8文字は、ランダムな単語4語と同程度の強度しかありません。

保存方式で解読費用は1.1億倍変わる

パスワードの強度は、利用者が選ぶ文字列だけで決まるわけではありません。保存方式ごとに「攻撃者が1ドルで何回試行できるか」を求めたのが表2です。この指標は、同じ予算で何回試せるかを表すため、保存方式の実効的な強度差を直接示します。

表2：保存方式ごとの攻撃コスト（1ドルあたり試行回数）

実測値の出所：RTX 4090・hashcat v6.2.6 のベンチマークログ。bcrypt（cost=10 / 12）と scrypt はコスト係数の換算を含む派生値、Argon2id はGPUメモリ帯域からの解析的推定値です。基準GPUは $0.30/GPU時間として単価を置いています。

MD5と bcrypt（work factor 12）の間には、1ドルあたり試行回数で約1.1億倍の差があります。これは26.8ビット、英数62種のパスワードでは約4.5文字分に相当します。文字数を1文字増やす効果が約6.0ビットであることを踏まえると、保存方式をMD5から bcrypt（work factor 12）へ変えることは、パスワードを4〜5文字伸ばすのと同等の効果を持つことになります。利用者に負担を増やさずに達成できる点で、費用対効果の高い変更です。

ただしこの等価性は、漏えい後のオフライン攻撃に限って成立します。長さの追加はオンライン攻撃にも効きますが、鍵導出関数の変更はオンライン攻撃には効きません。NIST SP 800-63B-4 の15文字要件が、長さと「承認されたハッシュ方式」を並べて要求しているのは、この非対称性を踏まえたものです。

「低速KDF」と呼ばれる構成の中にも差があります。PBKDF2-HMAC-SHA256（60万回）の1ドルあたり試行回数は bcrypt（work factor 10）より約2.6倍大きく、同じ低速KDFでも攻撃者にとっては安い構成です。パスワード保存に高速ハッシュを用いることは、長さの設計そのものを無意味にします。

予算は線形な長さで吸収され、保存方式の弱さは吸収されない

攻撃者の予算を6水準に変え、各保存方式で「予算内では解読できない」最小文字数を求めたのが表3です。

表3：攻撃予算別に「耐える」最小文字数（英数62種・ランダム生成前提）

予算を1万倍（100ドルから100万ドル）にしても、必要な長さの増加は2〜3文字です。長さに対するコストが指数的に増大するため、予算の指数的な増加が長さの線形な増加で吸収される、という関係になっています。防御側にとって有利な性質です。

保存方式による差は、これより大きくなります。100万ドルの予算で、MD5は13文字を要するのに対し、bcrypt（cost=12）も scrypt も8文字で足ります。差は5文字です。

同じ構造は脅威モデル別の必要文字数にも現れます。予算を1,000倍（1万ドルから1,000万ドル）にしても、必要文字数は英数62種で7文字から9文字へ2文字しか増えません。一方、同じ1,000万ドルでも保存が最弱（MD5相当）であれば13文字を要します。

表4：脅威モデル別に必要な最小文字数（抜粋）

8・12・15・16・20・32文字を同じ土俵で比べる

表5は、6つの長さそれぞれについて、設定した攻撃想定への耐性を整理したものです。レート制限つきオンライン攻撃（T1）は3文字で足り、6つの長さはいずれもこれを満たすため省略しています。「人間選択の実効bit」は、1文字あたり2.0ビットという中央値を仮定した値です。

表5：6つの長さの総合比較（英数62種・ランダム生成前提）

主要な所見は4点です。

1. 8文字は、6つの想定のうち4つで予算内に解読されます。耐えたのはオンライン（レート制限なし）と、bcrypt（work factor 12）かつ予算1万ドルという条件です。8文字が有効なのは、MFAとレート制限が機能し、かつ保存側が低速な鍵導出関数を用いている場合に限られます。
2. 12文字が破られたのは、最弱保存（MD5相当）と組織的予算（1,000万ドル）が重なった条件のみです。同じ1,000万ドルでも保存が bcrypt（work factor 12）であれば12文字は耐えます。予算の効果と保存方式の効果が重なった条件での結果であり、「組織的攻撃一般の性質」と読むことはできません。
3. 12文字の余裕は小さめです。MD5保存かつ予算10万ドルの条件で、12文字の解読費用は約81.9万ドル、予算の約8.2倍にとどまります。桁としては近く、予算が1桁増えれば破られる境界にあります。
4. 15文字以上は、英数字62種を用いる前提で、設定したすべての想定に耐えます。この前提は重要です。英小文字26種のみでは、同じ想定に対して16文字を要します。文字集合を広く取らない場合は15文字では足りません。16文字以上との差は、耐えるか否かではなく余裕の大きさです。

32文字を「16文字より2倍安全」と説明することは誤りです。理論強度では 2⁹⁵·² 倍ですが、表5の判定は16文字と同じになります。強度の増加が判定を変えない領域に入っているためです。

耐用年数：8文字の安全性は「時間的な借り」

GPU性能の年次成長率を1.2倍・1.5倍・2.0倍の3水準に置き、予算100万ドルで解読可能になるまでの年数を求めたものが表6です。成長率の想定は実測でも検証できます。RTX 5090（2025年1月発売）と RTX 4090 の実測ログを比べると、MD5で1.32倍、SHA-256で1.22倍、bcryptで1.39倍でした。約2年で1.2〜1.4倍、年1.1〜1.2倍に相当するため、年1.2倍の列が現実的な下限、年2.0倍の列が上限に近い想定です。

表6：100万ドル予算で解読可能になるまでの年数（英数62種・抜粋）

注目すべきは bcrypt（cost=12）と8文字の組み合わせです。2026年時点では予算1万ドルで解読できませんが、予算100万ドルかつ年2.0倍の成長を仮定すると2.7年で到達します。8文字の安全性は、鍵導出関数の強度に依存した時間的な借りです。一方、12文字以上は年2.0倍の成長を仮定しても26年以上の余裕を持ちます。ただしMD5保存の場合、12文字は既に予算内であり、耐用年数を論じる段階にありません。

有効長：全角日本語では24文字で頭打ちになる

実務受容性の観点で見落とされやすいのが、指定した長さと実際にハッシュへ渡る長さの乖離です。bcrypt には72バイトという入力上限があります。UTF-8では全角日本語1文字が3バイトを占めるため、全角24文字で上限に達し、25文字目以降はハッシュ計算に影響しません。

表7：指定した長さと実際にハッシュへ渡る長さ（bcrypt 72バイト上限）

半角英数では72文字まで有効なのに対し、全角日本語では24文字で上限に達します。日本語環境で「32文字のパスワード」を設定しても、bcrypt を用いるサービスでは実効的に24文字としてしか扱われません。1文字あたりの強度を英数62種の仮定で固定して評価すれば、失われるのは8文字分、約47.6ビットに相当します。利用者から見れば32文字を入力しているのに、サービス側では24文字分の強度しか得られていないことになります。

全角1文字が3バイトであるのは、UTF-8で3バイトに収まる文字（基本多言語面のCJK文字など）についてです。絵文字のように4バイトを要する文字を含む場合は、上限に達する文字数がさらに少なくなります。また、サービス側が受理する最大文字数が短ければ、利用者が長いパスワードを設定しても同じ切り詰めが起こります。NIST が少なくとも64文字の最大長を受け入れることを求め、OWASP がパスワードを黙って切り詰めないことを明示的に要求しているのは、いずれもこの劣化を防ぐためです。

人間が選んだパスワードは、表5よりさらに弱い

ここまでの判定は「文字集合から一様ランダムに生成した」という前提に立っています。現実の利用者はそうしません。1文字あたり2.0ビットを中央値として仮定すると、8文字で16.0ビット、12文字で24.0ビット、15文字で30.0ビット、32文字で64.0ビットになります。

この水準は、想定した攻撃モデルに届きません。8文字の人間選択パスワードの実効エントロピー16ビットは、レート制限ありのオンライン攻撃（T1、必要17.4ビット）にも届きません。15文字の人間選択で30ビットはT2（35.9ビット）にもT3（38.3ビット）にも届かず、32文字の人間選択で64ビットもT5（68.4ビット）には届きません。人間選択を前提とする限り、長さの要求はさらに厳しくなります。表5の判定はランダム生成を前提としており、人間選択パスワードに対しては楽観的です。

文字数を増やしても、人間選択に伴う分布の偏りは解消されません。辞書語、年号、キーボード配列、反復といった構造を突く推測手法（PCFG、マルコフモデル、深層学習など）は、全探索よりはるかに少ない試行で到達します。利用者側の対策としては、自分で考えずに生成器やパスワード管理アプリに生成させるのが確実です。

想定が10倍ずれても結論は変わらない

攻撃速度の想定を1/10倍から10倍まで変化させても、必要最小文字数の変動は1〜2文字です。GPU時間単価を0.10ドルから1.00ドルまで変動させても、変動は0〜1文字です。実測に基づかない主要なパラメータについて、結論が安定していることを確認できます。

もう一点、方法論として重要な点があります。本記事の費用計算は、攻撃コストを「時間」ではなく「予算」で定義しています。オフライン攻撃では必要エントロピーが攻撃期間に依存しないためです。並列化は購入できます。1年で解読できる攻撃者は、同じ予算を1週間に圧縮しても同じ総試行回数に到達します。よく見かける「解読に100万年かかる」という表示は、100万年分の予算が必要という意味ではありません。100万台を並べれば1年で済みます。

実務での指針

サービス提供者に対して

1. パスワード保存には低速な鍵導出関数を用いる（Argon2id、bcrypt、scrypt、または反復回数を大きく取った PBKDF2）。
2. 少なくとも64文字の最大長を受け入れ、入力を切り詰めない。
3. 文字数を Unicode コードポイント単位で数える。
4. レート制限とロックアウトを実装する。
5. 漏えい済みパスワードの拒否リストを導入する。

これらは表5の判定が前提としている条件そのものです。実装されていなければ、判定は成立しません。

利用者に対して

1. MFAを有効にする。8文字という水準が成立するのは、この条件下に限られます（二要素認証の完全ガイド）。
2. パスワードは自分で考えず、生成器か管理アプリに生成させる。パスワード生成ツールで文字数を指定して生成できます。
3. 重要なアカウントでは15文字以上、可能であれば16文字以上を確保する。文字集合が限られるサービスでは、記号なしパスワードの考え方も参照してください。

余裕を見て16文字以上を確保すれば、設定した全想定に耐えます。ただし有効長の観点では、複数の文字種を混ぜるより、長さを確保できる文字集合（半角英数）を選ぶほうが有利です。現在のパスワードの文字構成を確認する場合は、実物ではなく特徴を再現した近似サンプルをパスワード強度チェックで診断してください。

まとめ

1. 8文字は6つの想定のうち4つで予算内に解読される。有効なのはMFAとレート制限が機能し、保存側が低速KDFを用いている場合に限られる。
2. 12文字が破られたのは、最弱保存と組織的予算が重なった条件のみ。ただしMD5保存かつ予算10万ドルでは余裕が約8.2倍しかない。
3. 英数62種の前提で15文字以上は全想定に耐える。英小文字26種のみでは16文字を要する。
4. 制度上明確な根拠を持つ数字は8・12・15の3つ。8は MFA を前提とする下限、12は PCI DSS の要求、15は NIST と OWASP が単一要素認証に要求する下限。8と15の間には約3.5兆倍の差がある。
5. 長さの要求水準は保存方式に従属する。同じ予算でMD5は13文字、bcrypt（cost=12）は8文字。差は5文字。「何文字必要か」は「どこに保存されているか」と切り離せない。
6. 主要パラメータの不確実性は結論を左右しない。攻撃速度を10倍見誤っても変動は2文字以内、GPU単価を10倍変動させても1文字以内。

本記事の調査範囲と限界

• 表5の判定はランダム生成を前提とします。人間選択パスワードの実効エントロピーは仮定値であり、辞書語・年号・キーボード配列・反復といった構造は単一の係数では表現できません。
• 費用計算は鍵空間の全探索に基づきます。PCFG・モンテカルロ推定・マルコフモデル・深層学習などの手法は、人間選択パスワードに対して全探索よりはるかに少ない試行で到達します。したがって本記事の数値は攻撃者に必要な試行回数の上限を与えるもので、人間選択パスワードに対しては楽観的です。
• 攻撃速度は単一のベンチマークログに由来します。ハッシュモードによっては実測が特定のパラメータで記録されているため換算を行っており、Argon2id は実測が取得できていないため解析的推定値です。第7節の感度分析が示すとおり、10倍の見誤りは結論を変えません。
• 実サイトの受理条件は実測していません。個々のサービスが設定する最大文字数の調査は行っておらず、有効長の分析は標準が定める要件と bcrypt の実装上限に限定しています。
• 単一アカウントの解読を対象としています。大規模漏えいで多数のアカウントを一括処理する場合、1件あたりの平均費用は下がります。標的型攻撃や、鍵導出関数の内部構造への解析的攻撃、ソルト欠如に起因するレインボーテーブル攻撃も範囲外です。
• 人間被験者による検証は行っていません。「実務受容性」は技術的な受理条件に限定しており、記憶しやすさや入力負担は扱っていません。
• PCI DSS の要件は二次情報による確認です。要件8.3.6 が単一要素認証に12文字を要求することは、相互に独立な複数のコンプライアンス解説が同一の要件番号と文字数を記載していることをもって確認しました。規格文書そのものの逐字確認は行えていません。

参考資料

• NIST SP 800-63B-4（Digital Identity Guidelines: Authentication and Lifecycle Management）
• OWASP・Authentication Cheat Sheet
• OWASP・Password Storage Cheat Sheet（KDFの選択と切り詰めの禁止）
• Chromium・password_generator.cc（生成器の既定長）
• hashcat ベンチマーク実測ログ（RTX 4090）
• hashcat ベンチマーク実測ログ（RTX 5090）
• RFC 9106・Argon2（メモリ硬関数）
• RFC 8018・PKCS #5 v2.1（PBKDF2）
• RFC 7914・scrypt
• Bonneau (2012)・The Science of Guessing（7,000万件の推測分析）
• Mazurek et al. (2013)・Measuring password guessability for an entire university
• Komanduri et al. (2011)・Of passwords and people
• Shay et al. (2014)・Can long passwords be secure and usable?
• Houshmand et al. (2015)・Next Gen PCFG Password Cracking
• Dell'Amico & Filippone (2015)・Monte Carlo Strength Evaluation
• Hitaj et al. (2019)・PassGAN（深層学習による推測）
• PCI Security Standards Council・PCI DSS v4.0.1 要件8.3.6（単一要素認証に12文字）

著者・編集：passwordgenjp.com 情報セキュリティ研究チーム。公開資料の確認日：2026年9月15日。