✓この記事でわかること
- 1大文字・数字・記号の必須化は短く単純なパスワードを減らすために広まった
- 2NIST SP 800-63B-4では長さ・一意性・漏えい済みパスワード回避を重視し、文字種の強制だけには依存しない
- 3記号制限や文字数上限があるサービスでも、使える条件の中で長さと使い回し回避を保つ
多くのサービスが「大文字・数字・記号を含めてください」と求めるのは、短く単純なパスワードを減らすために広まった古い入力要件です。ただし、現在は文字種を混ぜることだけでは不十分で、十分な長さ、サービスごとの一意性、漏えい済みパスワードの回避が重要です。
強度を判断するときは、見た目の複雑さだけでなく、エントロピーと使い回しの有無を一緒に確認するのが安全です。詳しい数値の考え方はパスワードエントロピー、漏洩時の危険性は使い回しリスクで整理しています。
1. 世界標準 NIST SP 800-63B の新常識
米国国立標準技術研究所（NIST）の現行 SP 800-63B-4 では、単一要素として使うパスワードは15文字以上、別の認証要素と組み合わせる場合は8文字以上を最低基準としています。また、少なくとも64文字まで受け付け、文字種の組み合わせを強制せず、既知・一般的・漏えい済みのパスワードを拒否する考え方を示しています。
つまり、記号を1つ足すことよりも、短く推測しやすい文字列を避け、使い回さず、必要に応じて多要素認証を組み合わせる方が実用的です。複雑さを強制すると、利用者が「P@ssw0rd1」のような予測しやすい置き換えに逃げやすいことも問題になります。サービス側の「記号必須」は、そのサービスが採用している入力条件であり、NISTの推奨そのものとは分けて考えます。
古い常識 (廃止傾向)
- 「定期的な変更」を強制する
- 記号や数字を無理やり混ぜさせる
- 秘密の質問（ペットの名前など）
新常識 (推奨)
- 短い複雑さよりも十分な長さ
- 使い回しを避け、サービスごとに分ける
- 漏洩が確認された際にのみ変更する
- 漏えい済み・よくある文字列を避ける
| 基準 | 古い考え方 | 現在重視したい考え方 |
|---|---|---|
| 文字種 | 大文字・数字・記号を必ず混ぜる | 使える文字種の範囲で、十分な長さと推測されにくさを確保する |
| 変更頻度 | 定期的に変更させる | 漏えい、不審ログイン、共有ミスが疑われるときに変更する |
| 禁止リスト | 利用者任せにする | よくある文字列、サービス名、漏えい済み文字列を避ける |
| 追加認証 | パスワードだけで守る | 重要アカウントでは二段階認証・多要素認証を併用する |
2. なぜ「複雑さ」より「長さ」なのか
攻撃者が総当たりで試す候補は、1文字増えるだけで大きく増えます。8文字で複雑そうに見える文字列でも、よくある単語や置き換えを含むと推測されやすくなります。一方、長くて使い回していない文字列は、候補数が増え、漏洩時の被害も他サービスへ広がりにくくなります。
たとえば「P@ssw0rd1」は記号・大文字・数字を含んでいますが、元の単語が password で、置き換えもよくあるパターンです。見た目の複雑さだけで安心せず、長さ・ランダム性・使い回しの有無をまとめて確認する必要があります。
避けたい例
P@ssw0rd1
- 元の単語が推測されやすい
- 文字数が短い
- 別サービスで使い回すと被害が広がる
目指したい例
river-82-lamp-cloud-fox
- 15文字以上で長い
- 単語の組み合わせに規則性を持たせない
- サービスごとに別の文字列を使う
3. 強さは「文字種」だけで決めない
強さは、見た目の複雑さだけでなく、推測されにくさ、サービスごとの一意性、漏えい済み文字列に該当しないことを合わせて判断します。候補数を考えるエントロピーの詳しい説明はパスワードエントロピー、使い回しによる被害の広がりはパスワード使い回しのリスクに分けています。
この記事での判断順
- サービス側の文字数・文字種の条件を確認する
- 条件の範囲内で、長く固有の文字列を作る
- 漏えい済み・よくある文字列を避け、多要素認証を追加する
4. 生成するときは「用途」でモードを選ぶ
安全なパスワードを作るときは、最初に「自分で覚える必要があるか」「パスワードマネージャーに保存するか」「サービス側に記号制限があるか」を分けると迷いにくくなります。すべてを同じ形式で作るより、用途に合った生成方法を選ぶ方が実用的です。
通常のWebサービス
16文字前後のランダム文字列を基本にします。記号が使えるなら含め、使えない場合は長さを保ったまま英数字中心にします。
覚える必要がある場面
単語を複数つなぐパスフレーズが向いています。短い単語1つや誕生日を混ぜるより、長さと組み合わせの多さを確保できます。
開発・仮発行
APIキー風の16進文字列、UUID、決まった形式の仮パスワードなどは専用モードで作ると、手作業のミスを減らせます。
パスワード生成ツールでは、標準ランダム、パスフレーズ、PIN、16進、UUID、発音可能、カスタムパターンを切り替えられます。主要サービス向けの目安設定も用意しているため、まずプリセットを選び、必要に応じて文字数や記号の有無を調整する流れが安全です。
5. サービス側の要件にどう対応するか
実際の登録画面では、NISTの考え方どおりに自由な長いパスワードを使えるとは限りません。記号必須、記号禁止、文字数上限などに合わせる必要があります。その場合も、短く戻すのではなく、使える条件の中で長さと一意性を保ちます。
| 条件 | 対応 | 避けたい対応 |
|---|---|---|
| 記号必須 | ランダム文字列に記号を含め、16文字以上を目安にする | 末尾に「!」を付けるだけの短い文字列にする |
| 記号が使えない | 英数字だけで長さを増やし、サービスごとに別の文字列にする | 短い英単語や誕生日を混ぜる |
| 文字数上限が短い | 上限いっぱいまでランダム化し、多要素認証を必ず併用する | 覚えやすい既存パスワードを流用する |
| 空白や日本語が使えない | ハイフンや英単語の組み合わせ、またはランダム英数字に置き換える | 同じパスフレーズを複数サービスで使う |
6. 理想のパスワード管理方法
パスワードマネージャーを使う（最重要）
全サービスで15文字以上を目安にした異なるパスワードを設定し、アプリに管理させます。主要サービス：1Password・Bitwarden・iCloudキーチェーン・Google パスワード マネージャー。
多要素認証（MFA）を必ず有効にする
パスワードが漏洩しても、ワンタイムコードや認証アプリ、生体認証などを組み合わせると被害を抑えやすくなります。特に金融・メール・SNSアカウントでは優先して有効化しましょう。詳しくは二要素認証の解説も参考になります。
今使っているパスワードを確認する
覚えやすさだけで決めたパスワードは、短さや規則性が残っていることがあります。新しく作る前に、現在の文字列がどの程度の強さかを確認すると、どこを改善すべきか判断しやすくなります。
7. 作る前・登録時・登録後に確認すべきこと
パスワードは、作って終わりではありません。登録できる文字種か、見間違えやすい文字が多すぎないか、パスワードマネージャーに正しく保存できたかを確認してから使い始めましょう。特に記号制限のあるサービスでは、登録画面で弾かれたからといって短い文字列へ戻すのではなく、長さを保ったまま使える文字種に変えるのが大切です。
作る前
- そのサービスで使える文字種と最大文字数を確認する
- パスワードマネージャーに保存できる環境を用意する
- 重要アカウントなら多要素認証も設定する前提にする
登録時
- 同じパスワードを別サービスで使っていない
- コピー後に余計な空白や改行が混ざっていない
- 登録画面に弾かれても短い文字列へ戻さない
登録後
- パスワードマネージャーへ保存した
- 一度ログアウトして再ログインできることを確認した
- メール、金融、SNSでは二段階認証を有効化した
生成した文字列の強さを数字で確認したい場合は、生成結果からパスワード強度チェックへ送って確認できます。生成ツールは「作る」、強度チェックは「診断する」と役割を分けて使うと、設定作業がわかりやすくなります。
まとめ
大文字・数字・記号の必須化は、短く単純なパスワードを減らすために広まりました。ただし現在は、複雑さだけでなく、十分な長さ、サービスごとの一意性、漏えい済み文字列の回避、多要素認証の併用が重要です。登録画面の条件に合わせつつ、短く戻さず、パスワードマネージャーで管理できる長い固有パスワードを作りましょう。