NISTはなぜパスワードを15文字以上にしたのか？SP 800-63B-4の新基準を解説

SP 800-63B-4 で何が変わったのか

SP 800-63B-4 は、SP 800-63-4 を親文書とする 4 巻構成の第 2 巻（著者は Temoshok et al. 2025）です。同文書はパスワードを「記憶するか記録することを意図した秘密の値」と定義し、次の一文を明示します。

Passwords are not phishing-resistant.（§3.1.1.1）

つまり NIST はパスワードを「フィッシング耐性を持たない認証器」と位置づけています。したがってパスワードの要件は「可能な限り強くする」方向ではなく、「パスワードに依存する構成のリスクを正しく価格付けし、より強い方式へ移行させる」方向に設計されていると読むべきです。

表 1 は前版（Rev 3, 2017）との主要な差分です。特筆すべきは、最低長の引き上げ（8 → 15）が単独の変更ではないことです。合成規則や定期変更の禁止規定が SHOULD NOT から SHALL NOT へ格上げされ、実装側の義務（ブロックリスト、マネージャー・自動入力の許可、強度案内）が SHOULD から SHALL へ格上げされています。

表 1：パスワード関連要件の差分（SP 800-63B Rev 3 → SP 800-63B-4）

出典：SP 800-63B-4 §3.1.1.1・§3.1.1.2・§3.2.2・§3.2.9・§3.2.10、付録 A・B・E、および SP 800-63B (Rev 3) §5.1.1.2。

SP 800-63B-4 の付録 E（変更履歴）は、この変更を「単一認証要素として用いられるパスワードの最低長を引き上げた」の 1 行で記録するのみで、数値の根拠も「なぜ 15 なのか」も述べていません。この沈黙が、後述する再構成が必要になる理由です。

「15文字」はどこにだけ適用されるのか

まず押さえておきたいのが、適用範囲の限定です。§3.1.1.2 は 15 文字を単一要素認証として用いる場合に限定し、MFA の一部として用いるパスワードには 8 文字を許容しています（8 文字未満は不可）。

MFA が導入されていれば、パスワードが漏えい・推測されても攻撃者は第 2 要素を突破する必要があるため、パスワードに求められる強度は下がります。逆に単一要素認証ではパスワードが唯一の障壁です。この非対称な取り扱いは、統制の経済学として理解できます。

「8 文字で足りる」という判断が計算と整合する点は後述しますが、この時点で重要なのは、「NIST は全パスワードに 15 文字を義務付けた」という理解が誤りであることです。MFA を導入するほど長さ要件の負担は小さくなります。つまりこの要件は、MFA の採用に対して逆方向のインセンティブを与える設計になっています。

15文字はオンライン攻撃からは説明できない

パスワードへの攻撃は、認証エンドポイントへの繰り返し試行を行うオンライン攻撃と、ハッシュ化されたパスワードを入手して手元で総当たりするオフライン攻撃に大別され、防御手段がまったく異なります。

SP 800-63B-4 §3.2.2 はオンライン攻撃への統制を数値化しています。1 つのアカウント・1 つの認証器に対する連続失敗は100 回までです。目標突破確率を p = 10⁻⁶ とすると、必要探索空間は N ≥ A/p = 100 ÷ 10⁻⁶ = 10⁸ となり、約 26.6 ビット（印字可能 ASCII 95 種の一様ランダム文字列で約 4.05 文字）で足ります。8 文字の一様ランダム文字列（52.6 ビット）はこの要求を大きく上回ります。

さらにこの計算は攻撃者の推測が一様であるとした上界です。実際にはブロックリストによって攻撃者が最初に試す候補が登録時に除去されているため（§3.1.1.2）、実効的な突破確率はさらに低くなります。したがって15 文字をオンライン攻撃モデルから導くことはできません。

SP 800-63B-4 自身も付録 A で、オフライン環境では「毎秒数十億回のハッシュ計算」が可能になり、オンライン攻撃のみに抵抗することを想定したパスワードより桁違いに複雑なパスワードが要求されると述べています。実際のアカウント侵害でも、不正入手された認証情報の活用が主要な経路であり続けています（Thomas et al., 2017）。

オフライン攻撃が律速：ハッシュ方式別の必要探索空間

オフライン攻撃では、必要探索空間は攻撃者のハッシュ計算速度と時間予算の積で決まります。表 2 は、目標突破確率 p = 10⁻⁶、攻撃者の時間予算 1 年の条件で、ハッシュ方式ごとに必要な探索空間を計算したものです。実測速度は RTX 4090 単体の hashcat v6.2.6 ベンチマークを 10 枚相当に換算しています。

表 2：攻撃モデル別の必要探索空間（目標突破確率 p = 10⁻⁶、時間予算 1 年）

出典：NVIDIA RTX 4090・hashcat v6.2.6 の公開ベンチマーク（Chick3nman, 2022）。SHA-1 (mode 100) = 50,638.7 MH/s、SHA2-256 (mode 1400) = 21,975.5 MH/s、bcrypt (mode 3200) = 184.0 kH/s、scrypt (mode 8900) = 7,126 H/s。bcrypt のベンチマークはコスト係数 5 で実行されるため、cost=12 では 2⁷ = 128 分の 1 として換算。Argon2 は同ベンチマークに含まれないため、記憶困難型の代理指標として scrypt の実測値を使用。

表 2 が示す中心的な知見は、オンライン攻撃の要求（26.6 ビット）とオフライン攻撃の要求（58.7〜83.7 ビット）の間に 32〜57 ビットの隔たりがあることです。15 文字要件は、この隔たりのうちオフライン側に対応する統制です。

また、記憶困難型（scrypt を代理指標とする）を前提とすると、必要水準 61.0 ビットは Diceware 5 語（64.6 ビット）にほぼ対応し、4 語（51.7 ビット）では約 9 ビット不足します。「記憶困難なハッシュ方式＋無作為に選んだ 5 語のパスフレーズ」という組み合わせが本モデルの要求水準に到達するのは、実装者にとって有用な校正点です。

15文字はハッシュ方式とセットで読む

15 文字の一様ランダム文字列は 15 × log₂95 = 98.6 ビットの理論上限を持ちます。表 2 の必要水準がこの上限の何割にあたるかを計算すると、scrypt で 62%、bcrypt (cost=12) で 60%、SHA-256 系で 84%、SHA-1 系で 85% になります。

利用者選択パスワードの実効エントロピーが理論上限の 60〜62% に達することはありえます（とくにブロックリストで上位候補が除去され、無作為性の高いパスフレーズを選んだ場合）。しかし84〜85% に達することは現実的ではありません。つまり 15 文字という下限は、記憶困難型ハッシュを前提とすれば「達成可能な水準」を意味し、高速ハッシュを前提とすれば「利用者選択では到達できない水準」を意味します。

§3.1.1.2 が長さの要件と並んで「承認されたパスワードハッシュ方式（SP 800-132 の最新版等）を用いるべきである」と定めているのは、この計算と整合します。記憶困難型ハッシュの代表例である Argon2 は、メモリ消費を計算コストとして強制することで GPU・ASIC による並列総当たりを構造的に不利にする設計です（Biryukov et al., 2016）。

実装上の優先順位として重要なのは、長さを 1〜2 文字増やすことよりも、ハッシュ方式を高速ハッシュから記憶困難型へ切り替えることのほうが、要求ビット数を約 23 ビット削減するという点です。攻撃者の時間予算を 10 倍にしても必要ビット数は約 3.3 ビットしか増えません（log₂10）。防御側のレバレッジは、長さの微増ではなくハッシュ方式の選択にあるのです。

ブロックリスト：長さを「強度」に変換する装置

ここまでの議論は一様ランダム性を仮定していました。現実の利用者は一様ランダムな 15 文字を選びません。NIST はこの問題を付録 A で認めています。合成規則を課されると「password」を選ぶ人が「Password1」「Password1!」を選ぶ傾向がある、というのがその要約です。

利用者の選択が予測可能であるということは、攻撃者の推測順序の上位に来るということです。ブロックリストは、この予測可能な上位候補を登録時に除去する装置です。§3.1.1.2 は、ブロックリストを「既知の常用・予期される・漏えいしたパスワード」を含むものとし、比較はパスワード全体に対して行い（部分一致ではない）、拒否時には理由を提示することを求めます。

ただし NIST はブロックリストを無制限に大きくすることも求めていません。

過度に大きなブロックリストの追加的なセキュリティ便益は小さい。ブロックリストはオンライン攻撃への防御に使われ、それは §3.2.2 のスロットリング要件によってすでに制限されているからである。（付録 A の主旨）

ブロックリストの目的は、スロットリングの試行上限に達するまでに攻撃者が試すであろう候補を塞ぐことに限定されています。ブロックリストとスロットリングは一対の統制であり、長さ要件はその上に載る第 3 の層です。この三層構造を理解しないと、「15 文字あれば安全」という誤った結論に至ります。

なお、ブロックリストの提示が実際に利用者の選択行動を変えることは実験で確認されています（Habib et al., 2017）。漏えいパスワードを照合可能な形で提供する Have I Been Pwned の Pwned Passwords は、ブロックリストの実装を容易にします。

なぜ「15」なのか：4つの根拠と再構成（推論）

SP 800-63B-4 のどの条項にも「なぜ 15 なのか」の算出根拠は記載されていません。以下は、条項と研究を総合した本記事の解釈です。

根拠 1：合成規則の失敗（除去の側）

改訂の第一の根拠は、合成規則を除去する決断です（§3.1.1.2、SHALL NOT）。根拠は付録 A にあり、漏えいパスワードデータベースの分析が「合成規則の便益が当初考えられていたより小さい」ことと、使用可能性・記憶可能性への影響の深刻さを示しています（Weir et al., 2010；Komanduri et al., 2011）。合成規則を除去すると防御は長さとブロックリストに移るため、最低長の引き上げは合成規則の除去と論理的に一組です。片方だけの実施は設計意図を損ないます。

根拠 2：長さ志向ポリシーの使用可能性

長さを要求しても使用可能性が犠牲にならないという実証的知見です。Shay et al. (2016) は 20,000 人超を対象に 15 種のポリシーを比較し、「強度と使用可能性は必ずしも逆相関しない。長さより複雑さを強調する一般的なポリシーより、より使いやすく安全なポリシーが存在する」と結論しています。「15 文字にすると覚えられない」という直感が成立しないことは、15 文字という下限を設定する前提条件です。

根拠 3：単一要素認証のリスク価格付け

適用範囲の限定そのものが根拠です。オンライン攻撃の要求水準は 26.6 ビットで、8 文字の一様ランダム文字列（52.6 ビット）でも十分に上回ります。「MFA を前提とするなら 8 文字で足りる」という判断は、計算モデルと整合します。逆に単一要素認証では、15 文字という高めの水準と付随する負担が、MFA・パスキーへの移行を相対的に魅力的にします。

根拠 4：パスフレーズとパスワードマネージャーへの経路設計

§3.1.1.2 は最大長 64 文字以上の許容、印字可能 ASCII・空白・Unicode の受容、マネージャーと自動入力の許可（SHALL）、貼り付けの許可、表示オプションの提供を定めます。これらはすべて長いパスワードを入力するコストを下げる方向に働きます。つまり NIST の設計は、利用者にとって長さの限界費用をほぼゼロにし、攻撃者にとっては指数的な費用増加を課す非対称性で成立しています。

再構成：「15」はオフライン攻撃の要求水準に校正された値（推論）

表 2 のオフライン攻撃の要求水準から逆算すると、高速ハッシュ（SHA-1/SHA-256）・1 年予算・RTX 4090 を 10 枚使う想定で、一様ランダム換算の必要長は約 12.6〜12.7 文字（1 枚の想定で 12.0〜12.2 文字）になります。利用者選択パスワードは一様ランダムではないため実効的な探索空間は小さくなります。そこで政策担当者は、理論上の必要水準（約 12〜13 文字相当）に利用者選択による目減りを見込んだ余裕を加えた値として 15 を選んだ、と読むことができます。

傍証は 3 つあります。① 15 は 12.0〜12.7 の切り上げで、Shay et al. (2016) の実験範囲（16 文字以上）の直下にある。② 15 文字は「単語 4〜5 語のパスフレーズ」として自然に到達できる長さで、Diceware 5 語（64.6 ビット）は記憶困難型の要求水準（61.0 ビット）を上回る。③ 8 → 15 の引き上げ幅はオンライン攻撃の要求（4.05 文字相当）からは説明できず、オフライン攻撃の要求（12.0〜12.7 文字相当）から自然に説明できる。

注意：この再構成は本記事の推論であり、NIST が公表した導出ではありません。反証可能であり、将来 NIST が導出過程を公開して異なる内容であれば、この解釈は棄却されるべきものです。

よくある誤読と正確な要件

「15 文字以上にしなければならない」という形で広まった情報の多くは、条件や一体の統制を欠いた部分的な理解です。表 3 に、条項に基づく正確な内容を整理します。

表 3：15 文字要件に関する誤読と正確な要件

実装者向けチェックリスト

表 4 は SP 800-63B-4 のパスワード関連要件を整理したものです。「最低長を 15 文字に変更して記号必須の規則は維持する」という対応は、合成規則の SHALL NOT に違反します。同様に「最低長を 15 文字にして貼り付けは引き続き禁止する」対応も、マネージャー・自動入力の許可（SHALL）に反します。

表 4：SP 800-63B-4 準拠のための実装チェックリスト

特に項目 5・6・11 は既存システムの改修を要します。また表 2 が示すとおり、ハッシュ方式を高速ハッシュから記憶困難型へ変更することは必要ビット数を約 23 ビット削減するため、長さの要件とハッシュ方式の要件は同時に検討すべきです。

2026年の実務で何が変わるか

NIST が SP 800-63 Revision 4 の最終版を公表したのは2025 年 7 月です（約 4 年の過程、2 回の公開ドラフト、約 6,000 件のコメントを経て）。したがって 2026 年は「新基準が発行された年」ではなく、「新基準が実装・調達・監査に反映される年」です。本記事の基準日（2026 年 9 月 15 日）時点でも、NIST 公式ページは適合基準（conformance criteria）等の実装リソースが「近い将来提供される」と記載したままです。

実務では次の 3 点が変わります。第一に、認証方式の選択が調達要件に影響します。単一要素パスワード認証を続けるなら 15 文字と付随する負担を受け入れるか、MFA を導入して 8 文字を適用するかの選択になります。第二に、既存のパスワードポリシーの見直しが必要です。記号必須・定期変更・秘密の質問という「古典的な 3 点セット」は、いずれも SHALL NOT で禁止されるか禁止が強化されました。第三に、パスワードハッシュ方式の監査が現実の課題になります。最低長を引き上げるだけでは不十分で、ハッシュ方式自体の移行が必要です。

変わらないことも明確です。パスワードは廃止されません。SP 800-63B-4 は AAL1 でパスワードを引き続き許容します。方向性は廃止ではなく、パスワードに依存する構成の相対的な地位の低下です。米国連邦政府では OMB M-22-09 がフィッシング耐性 MFA への移行を求めており、FIDO Alliance がパスキーの業界標準化を主導しています。日本の文脈でも、IPA の「情報セキュリティ10大脅威 2026」は「インターネット上のサービスへの不正ログイン」を個人向け脅威として 11 年連続で選出しており、不正ログインが継続的な主要脅威であることは変わりません。パスキー移行は技術仕様の問題ではなく、アカウント回復・共有・委任の設計問題として現れるという研究もあります（Matzen et al., 2025）。

この移行期において、15 文字要件はつなぎの統制として読めます。パスワード単独運用を続ける組織には 15 文字・ブロックリスト・スロットリング・記憶困難型ハッシュの組み合わせを要求し、その負担を明示することで、MFA とパスキーへの移行を相対的に魅力的にするのです。

個人ユーザーが今日できること

1. 重要なサービスには MFA を有効にする。可能なら FIDO/WebAuthn などフィッシング耐性のある方法を優先します。MFA があればパスワードは 8 文字以上で足りるというのが NIST の設計です。
2. パスワードマネージャーで長くランダムな値を生成・自動入力する。15 文字以上のランダム文字列は、パスワード生成ツールで文字数と文字種を指定して作れます。マネージャーや自動入力の利用は NIST が許可（SHALL）を求めており、禁止するべきではありません。
3. 合成規則より長さを優先する。記号や大文字の混在を強制する規則は NIST が禁止しています。むしろ長さを確保し、漏えい済み・よく使われるパスワードを避けます。文字制限のあるサービス向けの考え方は記号なしパスワードの安全性ガイドで解説しています。
4. 漏えいの証拠があればすぐ変更する。定期変更の強制は不要ですが、侵害が疑われる場合の変更は NIST が求める必須事項です。使い回しているパスワードがある場合も、このタイミングで変更します。
5. ブロックリストと照合する。自分のパスワードが漏えい済みかどうかは、Have I Been Pwned の Pwned Passwords で確認できます。

現在のパスワードの文字構成を確認する場合は、実物ではなく特徴を再現した近似サンプルをパスワード強度チェックで診断してください。パスワードの定期変更の考え方についてはパスワードの定期変更は必要？もあわせてご覧ください。

まとめ

NIST が SP 800-63B-4 で 15 文字という下限を設けたのは、次の 5 点に要約できます。

1. 要件は条件付き。15 文字は単一要素認証の場合のみ。MFA の一部なら 8 文字。
2. オンライン攻撃からは説明できない。100 回上限の下では 26.6 ビット（4.05 文字相当）で足りる。
3. オフライン攻撃への統制。ハッシュ方式別に 58.7〜83.7 ビットの要求があり、高速ハッシュ環境では 15 文字でも理論上限の 84〜85% が必要になる。
4. ハッシュ方式と不可分。記憶困難型ハッシュなら達成可能、高速ハッシュなら利用者選択では到達しがたい。長さよりハッシュ方式の変更のほうが効果が大きい（約 23 ビット）。
5. 4 つの統制と一体の政策設計。合成規則の禁止・ブロックリスト照合・スロットリング・承認されたハッシュ方式での保存。長さだけの実装は設計を損なう。

「NIST はなぜパスワードを 15 文字以上に変更したのか」への短い答えは次のとおりです。NIST はパスワードを長くするよう求めたのではなく、パスワードに依存することの費用を正しく表示するよう求めた。15 文字という数値はその費用表示の一部であり、記憶困難型ハッシュ・ブロックリスト・スロットリングと組み合わされたときにのみ意味を持ちます。

本記事の調査範囲と限界

本記事は、SP 800-63B-4 の一次資料の条項解析と、公開ベンチマークに基づく攻撃モデルの計算的再構成をもとにした解説です。以下の点にご注意ください。

• 「15」の導出は NIST が公開していません。本記事の再構成は推論であり、反証可能です。
• ハッシュ計算速度は単一のカード・バージョンの実測値に基づきます（RTX 4090・hashcat v6.2.6）。特定の攻撃者の実際の予算を推定するものではなく、Argon2 はベンチマークに含まれないため scrypt を代理指標としています。結論が依存するのは速度の絶対値ではなくハッシュ構成間の相対関係です。
• 利用者選択パスワードの実効エントロピーは推定していません。「理論上限に対する割合」という形での議論です。
• SP 800-63 は米国連邦情報システム向けのガイドラインで、日本企業への直接の法的義務ではありません。日本の制度への適用可能性の評価は本記事の範囲外です。
• 15 文字要件の実運用上の効果は測定されていません。本記事は要件の設計意図の分析であり、侵害削減の因果的効果の推定ではありません。

参考資料

• Temoshok et al. (2025)・NIST SP 800-63B-4（Digital Identity Guidelines: Authentication and Authenticator Management）
• NIST SP 800-63-4（親文書・Digital Identity Guidelines）
• NIST SP 800-63-4 公式背景ページ（FAQ・適合基準の提供状況）
• Grassi et al. (2017)・NIST SP 800-63B（Rev 3）
• Shay et al. (2016)・Designing password policies for strength and usability（20,000人超の比較実験）
• Komanduri et al. (2011)・Of passwords and people（合成規則の利用者行動への影響）
• Weir et al. (2010)・Testing metrics for password creation policies（漏えい集合への攻撃実験）
• Habib et al. (2017)・Password creation in the presence of blacklists（ブロックリストの実験）
• Bonneau (2012)・The science of guessing（7,000万件規模の推測分析）
• Biryukov et al. (2016)・Argon2（記憶困難型ハッシュの設計）
• NIST SP 800-132（パスワードベース鍵導出の推奨）
• Chick3nman (2022)・hashcat v6.2.6 ベンチマーク（RTX 4090 実測値の出典）
• Thomas et al. (2017)・Data breaches, phishing, or malware?（不正入手認証情報の実態）
• OMB M-22-09・米国政府のゼロトラスト移行（フィッシング耐性 MFA の義務化）
• CISA・Implementing Phishing-Resistant MFA（ファクトシート）
• FIDO Alliance・Passkeys
• Have I Been Pwned・Pwned Passwords（漏えいパスワード照合）
• IPA・情報セキュリティ10大脅威 2026
• Verizon (2025)・Data Breach Investigations Report

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