パスワードの文字数と安全性｜最適な長さの選び方
パスワードの安全性を左右する最大の要因は「文字数」です。短いパスワードは総当たり攻撃 (ブルートフォース) で瞬時に突破されますが、1 文字増やすだけで組み合わせ数は約 95 倍に膨れ上がります。この記事では、NIST SP 800-63B の最新ガイドラインを軸に、エントロピーの概念、ハッシュ関数の計算コスト、GPU の実測解読時間、パスフレーズと多要素認証の組み合わせまで、パスワードの長さと安全性の関係を多角的に掘り下げます。
エントロピーとパスワード強度の関係
パスワードの強度を定量的に評価する指標が「エントロピー」(情報量) です。エントロピーはビット単位で表され、値が大きいほど攻撃者にとって推測が困難になります。計算式は以下のとおりです。
エントロピー (ビット) = log2(文字種の数文字数) = 文字数 × log2(文字種の数)
たとえば、英大小文字 + 数字 + 記号の 95 種を使う場合、1 文字あたり約 6.57 ビットのエントロピーが加算されます。8 文字なら約 52.6 ビット、12 文字なら約 78.8 ビット、16 文字なら約 105.1 ビットです。セキュリティの世界では 80 ビット以上が「当面安全」、128 ビット以上が「長期的に安全」とされています。つまり、95 種の文字セットを使う場合、13 文字以上で当面安全、20 文字以上で長期的に安全な水準に達します。
ここで重要なのは、文字種を増やすよりも文字数を増やすほうがエントロピーへの寄与が大きい点です。英小文字のみ (26 種) の 16 文字はエントロピー約 75.2 ビットですが、全 95 種を使った 12 文字は約 78.8 ビットとほぼ同等です。一方、英小文字のみでも 20 文字にすればエントロピーは約 94 ビットに達し、95 種 × 14 文字 (約 92 ビット) を上回ります。「複雑さ」より「長さ」が重要と言われる数学的根拠がここにあります。
NIST SP 800-63B ガイドラインの要点
NIST (米国国立標準技術研究所) が 2017 年に改訂し、2024 年に第 4 版ドラフトを公開した SP 800-63B は、パスワードに関する国際的な指針として広く参照されています。セキュリティの入門書も併せて読むと理解が深まります。従来の「定期変更」「複雑な文字種の強制」を明確に非推奨とし、長さを最重要要素に位置づけた点が画期的です。
- 最低文字数: 8 文字以上 (サービス提供者が設定すべき下限)
- 推奨文字数: 15 文字以上 (第 4 版ドラフトでは最低 15 文字への引き上げが検討されている)
- 最大文字数: 少なくとも 64 文字まで許容すべき
- 文字種の強制 (大文字・記号の必須化) は非推奨 — ユーザーが予測可能なパターン (末尾に "!" を付ける等) に陥りやすく、実質的なエントロピー向上に寄与しないため
- 定期的なパスワード変更の強制も非推奨 — 変更を強制すると、ユーザーは微小な変更 (末尾の数字をインクリメント等) で対応しがちで、セキュリティ向上につながらない
- 漏洩パスワードリストとの照合を義務化 — サービス提供者は、ユーザーが設定しようとするパスワードを既知の漏洩リストと照合し、一致する場合は拒否すべき
NIST が「複雑さ」より「長さ」を重視する背景には、前述のエントロピーの数学的性質に加え、ユーザビリティの研究結果があります。複雑なルールを課すと、ユーザーは付箋にパスワードを書いたり、パターン化した弱いパスワードを使い回したりする傾向が強まることが実証されています。
GPU によるブルートフォース解読時間の実測データ
パスワードの文字数が増えるほど、総当たり攻撃に要する時間は指数関数的に伸びます。以下の表は、英大小文字・数字・記号 (約 95 種) を使用し、最新の GPU (NVIDIA RTX 4090 クラス、MD5 ハッシュで毎秒約 1,640 億回の試行が可能) を前提とした推定解読時間です。
| 文字数 | 組み合わせ数 | エントロピー | 推定解読時間 (MD5) | 推定解読時間 (bcrypt) |
|---|---|---|---|---|
| 6 文字 | 約 7,350 億 | 約 39.5 bit | 約 4.5 秒 | 約 23 万年 |
| 8 文字 | 約 6.6 京 | 約 52.6 bit | 約 11 時間 | 約 20 億年 |
| 10 文字 | 約 6 × 1019 | 約 65.7 bit | 約 1.2 万年 | 事実上不可能 |
| 12 文字 | 約 5.4 × 1023 | 約 78.8 bit | 約 1 億年 | 事実上不可能 |
| 16 文字 | 約 4.4 × 1031 | 約 105.1 bit | 約 8.5 × 1012 年 | 事実上不可能 |
MD5 のような高速ハッシュでは 8 文字が約 11 時間で突破される一方、bcrypt (コストファクター 12) を使用するサービスでは同じ 8 文字でも解読に約 20 億年を要します。ハッシュアルゴリズムの選択がパスワードの実効的な安全性を大きく左右する点は見落とされがちです。ただし、サーバー側のハッシュアルゴリズムはユーザーが選べないため、ユーザー側でできる最善策は「十分に長いパスワードを設定すること」に尽きます。
ハッシュ関数の計算コストと文字数の関係
パスワードの安全性は、文字数だけでなく、サーバー側で使用されるハッシュ関数の計算コストにも大きく依存します。主要なハッシュアルゴリズムの特性を比較します。
| アルゴリズム | GPU 試行速度 (RTX 4090) | 特徴 |
|---|---|---|
| MD5 | 約 1,640 億回/秒 | 高速すぎてパスワード保存には不適切。レガシーシステムに残存 |
| SHA-256 | 約 220 億回/秒 | MD5 より低速だが、パスワード保存には依然として不十分 |
| bcrypt (cost=12) | 約 184 回/秒 | 意図的に低速化。コストファクターで計算量を調整可能。入力 72 バイト制限あり |
| Argon2id | 数十〜数百回/秒 | 2015 年の Password Hashing Competition 優勝。メモリハード設計で GPU 並列攻撃に強い |
| scrypt | 数百〜数千回/秒 | メモリハード設計。Argon2 登場前の推奨アルゴリズム |
bcrypt は入力を 72 バイトに切り詰める仕様があるため、ASCII 文字のみなら 72 文字、UTF-8 の日本語なら約 24 文字が実質的な上限です。これが一部サービスの最大文字数制限に影響しています。Argon2id にはこの制限がなく、任意の長さのパスワードを処理できます。新規サービスの設計では Argon2id の採用が推奨されます。
重要なのは、bcrypt や Argon2id のような低速ハッシュを使用していても、短いパスワードでは辞書攻撃やルールベース攻撃で突破される可能性がある点です。ハッシュの計算コストは「時間稼ぎ」であり、根本的な防御は十分な文字数 (エントロピー) の確保にあります。
なぜ「複雑さ」より「長さ」が重要なのか
多くのサービスが「大文字・小文字・数字・記号をすべて含めること」というルールを課していますが、NIST はこのアプローチを明確に否定しています。その理由を具体的な数値で示します。
「P@ssw0rd!」は 9 文字で 4 種の文字種をすべて含みますが、辞書攻撃の上位リストに含まれる典型的な弱いパスワードです。一方、「mountain river cloud forest」は英小文字とスペースのみ (27 種) の 30 文字ですが、エントロピーは約 142.5 ビットに達し、ブルートフォースでの解読は事実上不可能です。
複雑さのルールが逆効果になる理由は 3 つあります。第一に、ユーザーは予測可能なパターンで要件を満たそうとします (先頭を大文字、末尾に "1!" を追加など)。第二に、複雑なパスワードは記憶が困難なため、短くなりがちです。第三に、記憶できないパスワードは付箋やテキストファイルに平文で保存されるリスクが高まります。
パスフレーズ vs ランダム文字列
長いパスワードを実現する手法として「パスフレーズ」と「ランダム文字列」の 2 つがあります。それぞれの特性を比較します。
| 観点 | パスフレーズ | ランダム文字列 |
|---|---|---|
| 例 | correct horse battery staple | kX9#mP2$vL7@nQ4 |
| 文字数 | 28 文字 | 15 文字 |
| エントロピー | 約 77 bit (Diceware 6 語) | 約 98.5 bit (95 種 × 15 文字) |
| 記憶しやすさ | 高い (ストーリーで記憶可能) | 低い (パスワードマネージャー必須) |
| 入力しやすさ | 高い (通常のタイピング) | 低い (記号の入力が煩雑) |
| 辞書攻撃耐性 | 単語の組み合わせ数に依存 | 極めて高い |
パスフレーズの強度は「単語数」と「単語リストのサイズ」で決まります。Diceware 方式 (7,776 語のリスト) で 6 語を選ぶと、エントロピーは約 77.5 ビットです。日常的に使う単語だけで構成すると辞書攻撃に弱くなるため、無関係な単語をランダムに組み合わせることが重要です。「私の猫は可愛い」のような意味のある文章はパスフレーズとしては不適切で、「椅子 紫 潜水艦 七味 銀河」のような無関係な単語の羅列が理想的です。
マスターパスワード (パスワードマネージャーの解錠用) にはパスフレーズが適しており、個別サービスのパスワードにはパスワードマネージャーが生成するランダム文字列が最適です。
主要サービスのパスワード文字数制限
サービスによってパスワードの最小・最大文字数は大きく異なります。最大文字数の制限は、前述のハッシュアルゴリズムの仕様やレガシーシステムの制約に起因するケースが多いです。
| サービス | 最小文字数 | 最大文字数 | 備考 |
|---|---|---|---|
| 8 文字 | 100 文字 | 2 段階認証を強く推奨 | |
| Apple ID | 8 文字 | 制限なし | 英大小文字 + 数字を要求 |
| Microsoft | 8 文字 | 256 文字 | パスワードレス認証を推進中 |
| Amazon | 6 文字 | 128 文字 | 最小 6 文字は NIST 基準を下回る |
| X (旧 Twitter) | 8 文字 | 128 文字 | SMS 認証は有料プラン限定 |
| 6 文字 | 制限なし | 最小 6 文字は NIST 基準を下回る | |
| GitHub | 8 文字 | 制限なし | 漏洩パスワードリストとの照合あり |
| 銀行系 (一般的) | 8 文字 | 16〜32 文字 | 最大文字数が短い傾向。レガシーシステムの制約が多い |
注目すべきは、Amazon や Instagram の最小 6 文字が NIST の推奨 (最低 8 文字) を下回っている点です。また、銀行系サービスの最大 16〜32 文字という制限は、bcrypt の 72 バイト制限やメインフレーム時代のレガシーシステムに起因するケースが多く、セキュリティ上の懸念があります。制限の範囲内で可能な限り長いパスワードを設定しましょう。
多要素認証との組み合わせ
どれほど長いパスワードでも、フィッシングやキーロガーで窃取されれば無力です。パスワードの「長さ」による防御と、多要素認証 (MFA) による防御は、異なる攻撃ベクトルに対応するため、組み合わせることで防御力が飛躍的に向上します。
- TOTP (時間ベースのワンタイムパスワード): Google Authenticator や Authy などのアプリが生成する 6 桁のコード。30 秒ごとに更新されるため、窃取されても再利用が困難。ただし、フィッシングサイトにリアルタイムで中継される攻撃 (リアルタイムフィッシング) には脆弱
- FIDO2 / WebAuthn (パスキー): 物理的なセキュリティキーやデバイスの生体認証を使用。フィッシング耐性が最も高く、NIST も推奨。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) から優先的にパスワードを強化する。メールアカウントは他サービスのパスワードリセットに使われるため、最優先で保護すべき
サービス開発者向け:
- パスワードの最小文字数は 8 文字以上 (NIST 準拠)、推奨は 12 文字以上に設定する
- 最大文字数は 64 文字以上を許容する。不必要に短い上限はユーザーのセキュリティを制限する
- 文字種の強制ルールは設けない。代わりに、漏洩パスワードリスト (Have I Been Pwned の API 等) との照合を実装する
- ハッシュアルゴリズムは Argon2id を第一選択とし、bcrypt (コストファクター 12 以上) を次善とする。MD5 や SHA-256 の単純適用は絶対に避ける
- パスワード強度メーターを実装し、ユーザーにリアルタイムでフィードバックを提供する。zxcvbn ライブラリのようなエントロピーベースの評価が望ましい
よくある失敗パターンと対策
- 辞書に載っている単語をそのまま使う: "sunshine"、"football"、"dragon" などの一般的な英単語は、辞書攻撃で瞬時に突破される。攻撃者は数百万語の辞書に加え、l33t speak 変換 (a→@、e→3 等) やキーボードパターン (qwerty、1qaz2wsx 等) も網羅的に試行する
- 個人情報をパスワードに含める: 誕生日、ペットの名前、住所の一部は、SNS の公開情報やデータ漏洩から容易に推測される。攻撃者はターゲットの公開情報を収集してカスタム辞書を作成する手法 (ソーシャルエンジニアリング) を日常的に使用している
- 複数サービスで同じパスワードを使い回す: 1 つのサービスで漏洩すると、同じパスワードを使っている全サービスが危険にさらされる。「クレデンシャルスタッフィング」と呼ばれるこの攻撃は、漏洩したパスワードリストを他のサービスに自動で試行するもので、成功率は 0.1〜2% とされる。100 万件の漏洩リストがあれば、1,000〜20,000 件のアカウントが突破される計算になる
- パスワードの微小な変更で使い回す: "MyPassword1"、"MyPassword2"、"MyPassword3" のようなパターンは、攻撃者のルールベース攻撃で容易に推測される。漏洩した 1 つのバリエーションから他のバリエーションを生成するツールが広く出回っている
まとめ
パスワードの安全性はエントロピー (情報量) に依存し、エントロピーを最も効率的に高める手段は文字数の増加です。NIST SP 800-63B は最低 8 文字、推奨 15 文字以上としており、bcrypt や Argon2id のような低速ハッシュと組み合わせることで実効的な安全性が確保されます。個人ユーザーはパスワードマネージャーで 20 文字以上のランダムパスワードを生成し、マスターパスワードには Diceware パスフレーズを使用するのが最善策です。さらに FIDO2 / パスキーによる多要素認証を併用すれば、現時点で最高水準の防御が実現できます。パスワードの文字数を確認したいときは、文字数カウントス をご活用ください。