最終更新:
パスワードの文字数と安全性｜最適な長さの選び方
パスワードの安全性を左右する最大の要因は「文字数」です。短いパスワードは総当たり攻撃 (ブルートフォース) で瞬時に突破されます。暗号化の強度はパスワード長に直結しますが、1 文字増やすだけで組み合わせ数は約 95 倍に膨れ上がります。この記事では、2025 年に第 4 版が公開された NIST SP 800-63B を軸に、エントロピーの概念、ハッシュ関数の計算コスト、総当たりに要する時間の桁、パスフレーズと多要素認証の組み合わせまで、パスワードの長さと安全性の関係を多角的に掘り下げます。
エントロピーとパスワード強度の関係
パスワードの強度を定量的に評価する指標が「エントロピー」(情報量) です。エントロピーはビット単位で表され、値が大きいほど攻撃者にとって推測が困難になります。計算式は以下のとおりです。
エントロピー (ビット) = log2(文字集合の数文字数) = 文字数 × log2(文字種の数)
たとえば、英大小文字 + 数字 + 記号の 95 種を使う場合、1 文字あたり約 6.57 ビットのエントロピーが加算されます。8 文字なら約 52.6 ビット、12 文字なら約 78.8 ビット、16 文字なら約 105.1 ビットです。
注意したいのは、エントロピーの値そのものに「ここから安全」という絶対的な境界はない点です。エントロピーが表すのは「攻撃者が全パターンを試し終えるまでに必要な試行回数の対数」でしかなく、同じ 52.6 ビットのパスワードでも、保存側が毎秒 1,000 億回試せるハッシュを使っているか、毎秒数百回しか試せないハッシュを使っているかで、破られるまでの時間は何桁も変わります。エントロピーは後述する試行速度と掛け合わせて初めて意味を持つ相対的な指標だと捉えてください。
ここで重要なのは、文字種を増やすよりも文字数を増やすほうがエントロピーへの寄与が大きい点です。英小文字のみ (26 種) の 16 文字はエントロピー約 75.2 ビットですが、全 95 種を使った 12 文字は約 78.8 ビットとほぼ同等です。一方、英小文字のみでも 20 文字にすればエントロピーは約 94 ビットに達し、95 種 × 14 文字 (約 92 ビット) を上回ります。「複雑さ」より「長さ」が重要と言われる数学的根拠がここにあります。
NIST SP 800-63B 第 4 版の要点
米国国立標準技術研究所 (NIST) のデジタルアイデンティティガイドライン SP 800-63B は、2025 年 8 月に第 4 版が公開され、旧版に置き換わりました。パスワードの文字数に関する要求は次のとおりです。
- 最低文字数: パスワード単独で認証する場合は 15 文字以上を必須とする。多要素認証の一要素として使う場合は 8 文字以上を必須とする
- 最大文字数: 少なくとも 64 文字までは受け付けるべき
- 文字種の強制 (大文字・記号の必須化) は禁止: ユーザーが予測可能なパターン (末尾に "!" を付ける等) で要件を満たすため、実質的なエントロピー向上に寄与しない
- 有効期限による変更の強制は禁止: ただし、漏洩など侵害の証拠がある場合は変更を強制する
- 漏洩パスワードリストとの照合は必須: 入力されたパスワードを既知の漏洩リストと照合して拒否する。照合の対象はパスワード全体で、部分文字列の一致で弾く運用は求められていない
- エントロピーの下限値は要求されていない: 「何ビット以上」という規定は第 4 版に存在せず、要件は文字数・ブロックリスト照合・保存方式として表現されている
構成規則を禁止まで踏み込んだのは、規則がユーザーに課す負担に対して得られる強度が小さいという判断によるものです。「大文字と記号を含めること」と要求されたユーザーの多くは、先頭の 1 文字を大文字にして末尾に記号を足すという最小限の変形で応じます。増えるのは攻撃者にとって予測可能な範囲だけで、探索空間はほとんど広がりません。
総当たり攻撃に要する時間の桁
パスワードの文字数が増えるほど、総当たり攻撃に要する時間は指数関数的に伸びます。以下は、英大小文字・数字・記号 (約 95 種) からランダムに選んだパスワードに対し、攻撃側が毎秒 1,000 億回 (1011 回) の試行を続けられると仮定した場合の推定時間です。全パターンを探索し終えるまでの時間であり、実際に何回試せるかはハッシュの種類・機材・実装によって数桁変わります。桁の感覚をつかむための計算例として読んでください。
| 文字数 | 組み合わせ数 | エントロピー | 推定所要時間 (毎秒 1011 回を仮定) |
|---|---|---|---|
| 6 文字 | 約 7,350 億 | 約 39.4 bit | 約 7 秒 |
| 8 文字 | 約 6,600 兆 | 約 52.6 bit | 約 18 時間 |
| 10 文字 | 約 6 × 1019 | 約 65.7 bit | 約 19 年 |
| 12 文字 | 約 5.4 × 1023 | 約 78.8 bit | 約 1.7 × 105 年 |
| 16 文字 | 約 4.4 × 1031 | 約 105.1 bit | 約 1.4 × 1013 年 |
この表は、ハッシュ 1 回の計算がごく軽い場合の話です。保存側が bcrypt や Argon2id のように意図的に計算コストを高めたハッシュを使っていれば、同じ機材でも 1 秒間に試せる回数は数桁下がり、表の時間はそのぶん右へ伸びます。逆に MD5 のような高速ハッシュで保存されていれば、短いパスワードは現実的な時間で総当たりされます。つまり同じ 8 文字でも、実際の安全性は保存側の実装次第で大きく変わります。サーバー側のハッシュ方式はユーザーが選べないため、利用者側でできる最善策は「十分に長いパスワードを設定すること」に尽きます。
ハッシュ関数の計算コストと文字数の関係
パスワードの安全性は、文字数だけでなく、サーバー側で使用されるハッシュ関数の計算コストにも大きく依存します。主要なハッシュアルゴリズムの特性を比較します。
| アルゴリズム | パスワード保存における位置づけ |
|---|---|
| MD5 | 1 回の計算が非常に軽く、GPU で大量に並列試行できる。パスワード保存には不適切だが、レガシーシステムに残存している |
| SHA-256 | MD5 より重いものの、高速に計算することを目的に設計されている。パスワード保存には依然として不十分 |
| bcrypt | 意図的に低速化した設計。コストファクターで計算量を調整でき、機材の高速化に追従できる。入力を 72 バイトに切り詰める仕様がある |
| Argon2id | 2015 年の Password Hashing Competition で選定されたアルゴリズム。計算時間だけでなくメモリ使用量も要求するメモリハード設計で、GPU による並列攻撃に強い。RFC 9106 が第一候補として推奨している |
| scrypt | メモリハード設計。Argon2 登場前の推奨アルゴリズム |
bcrypt は入力を 72 バイトに切り詰める仕様があるため、ASCII 文字のみなら 72 文字、UTF-8 の日本語なら約 24 文字が実質的な上限です。これが一部サービスの最大文字数制限に影響しています。Argon2id にはこの制限がなく、任意の長さのパスワードを処理できます。新規サービスの設計では Argon2id の採用が推奨されます。
重要なのは、bcrypt や Argon2id のような低速ハッシュを使用していても、短いパスワードでは辞書攻撃やルールベース攻撃で突破される可能性がある点です。ハッシュの計算コストは「時間稼ぎ」であり、根本的な防御は十分な文字数 (エントロピー) の確保にあります。
なぜ「複雑さ」より「長さ」が重要なのか
多くのサービスが「大文字・小文字・数字・記号をすべて含めること」というルールを課していますが、NIST はこのアプローチを明確に否定しています。その理由を具体的な数値で示します。
「P@ssw0rd!」は 9 文字で 4 種の文字種をすべて含みますが、辞書攻撃の上位リストに載る典型的な弱いパスワードです。攻撃者は "password" に対する a→@、o→0 といった置換を最初から試すため、文字種の要件を満たしていても探索空間はほとんど広がっていません。一方、「mountain river cloud forest」は英小文字の 4 語をスペースでつないだ 27 文字です。攻撃者が「7,776 語のリストから 4 語を並べた形」という構造まで見抜いた場合でも探索範囲は約 51.7 ビットに相当し、語数を 6 語に増やせば約 77.5 ビットに達します。文字種の充足数ではなく選択肢の広さが強度を決める、という点で両者は性質が異なります。
複雑さのルールが逆効果になる理由は 3 つあります。第一に、ユーザーは予測可能なパターンで要件を満たそうとします (先頭を大文字、末尾に "1!" を追加など)。第二に、複雑なパスワードは記憶が困難なため、短くなりがちです。第三に、記憶できないパスワードは付箋やテキストファイルに平文で保存されるリスクが高まります。
パスフレーズ vs ランダム文字列
長いパスワードを実現する手法として「パスフレーズ」と「ランダム文字列」の 2 つがあります。それぞれの特性を比較します。
| 観点 | パスフレーズ | ランダム文字列 |
|---|---|---|
| 例 | correct horse battery staple | kX9#mP2$vL7@nQ4 |
| 文字数 | 28 文字 | 15 文字 |
| エントロピー | 約 51.7 bit (7,776 語のリストから 4 語) | 約 98.5 bit (95 種 × 15 文字) |
| 記憶しやすさ | 高い (ストーリーで記憶可能) | 低い (パスワードマネージャー必須) |
| 入力しやすさ | 高い (通常のタイピング) | 低い (記号の入力が煩雑) |
| 辞書攻撃耐性 | 単語の組み合わせ数に依存 | 極めて高い |
ここで見落としてはいけないのが、パスフレーズを文字数で評価すると強度を大幅に過大評価してしまう点です。上の例は 28 文字ありますが、攻撃者が「単語リストから 4 語を選んで並べた形」という構造を前提に探索すれば、試すべき組み合わせは 4 語分しかありません。パスフレーズの強度は「単語数」と「単語リストのサイズ」で決まります。Diceware 方式 (7,776 語のリスト) なら 4 語で約 51.7 ビット、6 語で約 77.5 ビットです。日常的に使う単語だけで構成すると辞書攻撃に弱くなるため、無関係な単語をランダムに組み合わせることが重要です。「私の猫は可愛い」のような意味のある文章はパスフレーズとしては不適切で、「椅子 紫 潜水艦 七味 銀河」のような無関係な単語の羅列が理想的です。
マスターパスワード (パスワードマネージャーの解錠用) にはパスフレーズが適しており、個別サービスのパスワードにはパスワードマネージャーが生成するランダム文字列が最適です。
サービス側の文字数制限とどう向き合うか
パスワードの最小・最大文字数はサービスごとに異なりますが、上限値まで公式に案内しているサービスは多くありません。たとえば Google はヘルプページで「12 文字以上」を推奨として明記していますが、上限については触れていません。この種の値は予告なく変わるため、第三者がまとめた一覧を鵜呑みにするより、自分のアカウントで実際に設定できた長さを確かめるほうが確実です。パスワードマネージャーで 32 文字を生成して弾かれたら、24 文字、16 文字と下げていけば実効的な上限が分かります。
上限が設けられる技術的な理由の 1 つは、前述した bcrypt の 72 バイト制限です。ハッシュ側で黙って切り詰めるより、入力段階で上限を示すほうが挙動が明確になります。もう 1 つは、パスワードを短い固定長のカラムに保存していた時代の設計がそのまま残っているケースで、この場合は上限が数十文字と極端に短くなることがあります。いずれにしても利用者側の対処は同じで、許された範囲で最も長いパスワードを設定し、上限が短いサービスでは多要素認証を必ず併用してください。
逆に、最小文字数が 6 文字程度と緩いサービスにも出会います。サービスが許す下限は「安全な長さ」を意味しません。事業者側の要件がどうであれ、自分が設定する長さは自分で決められます。
多要素認証との組み合わせ
どれほど長いパスワードでも、フィッシングやキーロガーで窃取されれば無力です。パスワードの「長さ」による防御と、多要素認証 (MFA) による防御は、異なる攻撃ベクトルに対応するため、組み合わせることで防御力が飛躍的に向上します。
- TOTP (時間ベースのワンタイムパスワード): Google Authenticator や Authy などのアプリが生成する 6 桁のコード。30 秒ごとに更新されるため、窃取されても再利用が困難。ただし、フィッシングサイトにリアルタイムで中継される攻撃 (リアルタイムフィッシング) には脆弱
- FIDO2 / WebAuthn (パスキー): 物理的なセキュリティキーやデバイスの生体認証を使用。認証時に接続先の情報を鍵と結び付けて検証するため、偽サイトに認証情報を渡してしまう事故が構造的に起きない。SP 800-63B 第 4 版もこの仕組みをフィッシング耐性のある方式として扱っている。Apple、Google、Microsoft が「パスキー」として普及を推進中
- SMS 認証: 手軽だが、SIM スワップ攻撃や SS7 プロトコルの脆弱性により傍受されるリスクがある。NIST は SMS 認証を「制限付き」の認証手段と位置づけており、可能であれば TOTP や FIDO2 への移行を推奨
理想的な構成は「長いパスワード (またはパスフレーズ) + FIDO2 セキュリティキー」です。これにより、ブルートフォース、辞書攻撃、フィッシング、クレデンシャルスタッフィングのすべてに対して高い耐性を確保できます。
パスワードマネージャーの最適設定
- マスターパスワードの設定: パスワードマネージャーの解錠に使うマスターパスワードは、Diceware 方式で 6 語以上のパスフレーズを設定する。エントロピー 77 ビット以上が目安。マスターパスワードはどこにも保存せず、記憶のみで管理する
- 自動生成パスワードの長さ: 個別サービス用のパスワードは 20 文字以上のランダム文字列を自動生成する。bcrypt の 72 バイト制限を考慮し、ASCII 文字のみで 20〜64 文字が実用的な範囲
- クリップボードの自動クリア: コピーしたパスワードが一定時間後に自動削除される設定を有効にする。10〜30 秒が推奨
- ブラウザ内蔵のパスワード保存機能との使い分け: Chrome や Safari の内蔵パスワードマネージャーも十分な暗号化を備えているが、クロスプラットフォームでの利用や高度な機能 (セキュリティ監査、共有ボールト等) が必要な場合は専用ツールが適している
漏洩チェックとパスワードポリシーの設計指針
個人ユーザーとサービス開発者の双方に向けた実践的な指針をまとめます。
個人ユーザー向け:
- haveibeenpwned.com で自分のメールアドレスが過去の漏洩に含まれていないか定期的に確認する。同サイトの API はパスワードのハッシュ値の先頭 5 文字のみを送信する k-匿名性モデルを採用しており、パスワード自体が外部に送信されることはない
- パスワードマネージャーの「セキュリティ監査」機能を活用し、弱いパスワード、使い回し、漏洩済みパスワードを一括で検出する
- 重要度の高いアカウント (メール、金融、SNS) から優先的にパスワードを強化する。メールアカウントは他サービスのパスワードリセットに使われるため、最優先で保護すべき
サービス開発者向け:
- 最小文字数は、パスワード単独で認証する場合は 15 文字、多要素認証の一要素として使う場合は 8 文字を下限とする (いずれも SP 800-63B 第 4 版の要求)
- 最大文字数は 64 文字以上を許容する。不必要に短い上限はユーザーのセキュリティを制限する
- 文字種の強制ルールは設けない。代わりに、漏洩パスワードリスト (Have I Been Pwned の API 等) との照合を実装する
- ハッシュアルゴリズムは Argon2id を第一選択とし、bcrypt (コストファクター 12 以上) を次善とする。MD5 や SHA-256 の単純適用は絶対に避ける
- パスワード強度メーターを実装し、ユーザーにリアルタイムでフィードバックを提供する。文字種が何種類含まれているかを点数化するだけのメーターは、"P@ssw0rd!" のような弱いパスワードを高評価してしまい実態を反映しない。zxcvbn ライブラリのように、辞書・既知のパターン・キーボード配列を踏まえて「推測に必要な試行回数」を見積もる方式が望ましい
よくある失敗パターンと対策
- 辞書に載っている単語をそのまま使う: "sunshine"、"football"、"dragon" などの一般的な英単語は、辞書攻撃で瞬時に突破される。攻撃者は数百万語の辞書に加え、l33t speak 変換 (a→@、e→3 等) やキーボードパターン (qwerty、1qaz2wsx 等) も網羅的に試行する
- 個人情報をパスワードに含める: 誕生日、ペットの名前、住所の一部は、SNS の公開情報やデータ漏洩から容易に推測される。攻撃者はターゲットの公開情報を収集してカスタム辞書を作成する手法 (ソーシャルエンジニアリング) を日常的に使用している
- 複数サービスで同じパスワードを使い回す: 1 つのサービスで漏洩すると、同じパスワードを使っている全サービスが危険にさらされる。「クレデンシャルスタッフィング」と呼ばれるこの攻撃は、漏洩した ID とパスワードの組を他のサービスへ自動で試行するもので、パスワードをどれだけ長くしても防げない。1 組でも当たれば侵入されるため、対策はサービスごとに異なるパスワードを使うこと以外にない。だからこそパスワードマネージャーが必要になる
- パスワードの微小な変更で使い回す: "MyPassword1"、"MyPassword2"、"MyPassword3" のようなパターンは、攻撃者のルールベース攻撃で容易に推測される。漏洩した 1 つのバリエーションから他のバリエーションを生成するツールが広く出回っている
まとめ
パスワードの安全性はエントロピー (情報量) に依存し、エントロピーを最も効率的に高める手段は文字数の増加です。2025 年に公開された NIST SP 800-63B 第 4 版は、パスワード単独で認証する場合の下限を 15 文字、多要素認証の一要素として使う場合の下限を 8 文字と定めており、bcrypt や Argon2id のような低速ハッシュと組み合わせることで実効的な安全性が確保されます。個人ユーザーはパスワードマネージャーで 20 文字以上のランダムパスワードを生成し、マスターパスワードには Diceware パスフレーズを使用するのが最善策です。さらに FIDO2 / パスキーによる多要素認証を併用すれば、現時点で最高水準の防御が実現できます。パスワードの文字数を確認したいときは、文字数カウントス をご活用ください。