デジタル時代において、パスワードは依然として最も広く使用される認証手段の一つです。しかし、従来のパスワードポリシーの多くが、実は逆効果だったことをご存知でしょうか？
NIST（米国国立標準技術研究所）が発行するSP 800-63B-4は、パスワードセキュリティに関する最新の指針を提供しており、これまでの「常識」を覆す内容が含まれています。（専門家の間では長らく常識だったものなんですが…。）本記事では、企業内でパスワードを使ったユーザー認証システムを担当される方、およびこうしたポリシーを決める担当者や経営者に向けて、この重要な文書の核心をわかりやすく解説します。
パスワードの2つの分類
NIST SP 800-63B-4では、パスワードを以下の2種類に分類しています。
1. パスワード（Passwords） サーバー側で検証される秘密情報。ログイン時にサーバーに送信され、集中的に検証されます。
2. アクティベーション秘密（Activation Secrets） デバイス内でローカルに検証される秘密情報。例えばスマートフォンのロック解除PINなど、サーバーには送信されません。
従来の「常識」を覆す新要件
❌ やってはいけないこと
定期的なパスワード変更の強制禁止
- 90日ごとのパスワード変更を強制することは、もはや推奨されません
- 侵害の証拠がある場合のみ変更を要求すべきです
- 理由：頻繁な変更は、ユーザーが予測可能で弱いパスワードを選択する原因になります
NOTE: これはよくISMSとかで要求されているというコンサルの人なんかもいますが、それは「まちがい」です。ISO/IEC 27002 にもそんなことは書いてないない、どころか「Requiring frequent change of passwords can be problematic （頻繁なパスワードの変更を要求することは問題が多い）」と書いています。（そもそも、この辺のテキスト私が書いたし…。それこそ2013年頃だと思う。なお、逆に、変えなければいけないこともあることに注意。）
複雑性要件の押し付け禁止
- 「大文字、小文字、数字、記号を必ず含めること」といった要件は課してはならない(SHALL NOT)
- むしろ有害であると明記されています
- 理由：このような要件は、ユーザーが「Password1!」のような予測可能なパターンを使用する原因になります
パスワードヒントの禁止
- 「母親の旧姓は?」などのヒントやセキュリティ質問は使用禁止
- これらは攻撃者にとって貴重な情報源となります。というか、これっと複数の場所が知っている情報である確率が高く、したがって、こんなもので認証手段をリセットできたら目も当てられません。
✅ 推奨される要件
1. パスワードの長さ
- 単一要素認証：最低15文字
- 多要素認証の一部：最低8文字
- 最大長：64文字以上を許可すべき
長さこそが強度の鍵です。ありきたりなパスワードに使われる単語の一部をありきたりな記号置き換えルール(a→@, o→0, s→5など）で置き換えたような「P@ssw0rd」よりも「correct horse battery staple」の方が遥かに強力です。なお、このあたり細かい話になるので詳細にご興味のある方は文末の附属書Aをご参照ください。
NOTE: 現行のISO/IEC 27002 には辞書語の組み合わせを排除するようにと言うような記述が入っています(5.17 User responsibilities の C) 2))。これは私の見落としですね。次の版で排除しないと…。
2. 文字種の柔軟性
- すべての印字可能なASCII文字とスペースを受け入れる
- Unicode文字（日本語、絵文字など）もサポートすべき
NOTE: 正直これはちょっといただけないと思っている。Unicode正規化問題が持ち込まれてしまうので。（ちなみにNFC正規化を行うのが良い(SHOULD)となっている）。 - これにより、ユーザーは覚えやすく強力なパスワードを作成できます
3. ブロックリストの実装
検証者は以下を含むブロックリストと照合する必要があります：
- 過去の侵害で漏洩したパスワード
- 辞書に載っている単語
- サービス名やユーザー名などの文脈固有の情報
- 「123456」や「password」などの一般的なパスワード
ブロックリストに該当する場合、拒否理由を説明して別のパスワードを選択させます。
4. パスワードマネージャーの積極的サポート
- パスワードマネージャーの使用を許可する（必須）
- オートフィル機能をサポートする
NOTE: パスワードマネージャーの利用に必要ですね。最近、これができないサイトが日本で増殖しているのはどうしたものか…。 - ペースト機能を有効にする
NOTE: 同上 - 理由：パスワードマネージャーを使えば、ユーザーは強力で一意なパスワードを各サービスで使用できます
NOTE: それだけでなく、多くのパスワードマネージャーは、投入先のURLを検証しています。これはフィッシング耐性という意味で重要です。
5. ユーザー体験の向上
- パスワード表示オプションの提供（入力中に見えるようにする）
- これにより入力ミスが減り、ユーザーのフラストレーションが軽減されます
NOTE: 主にスマホなどで重要ですね。
サーバー側の要件：安全な保管
パスワードの保管に関しても厳格な要件があります：
必須事項
- 適切なパスワードハッシュスキームの使用
- 最低32ビットのソルトを使用
- ソルト値とハッシュの両方を保管
- オフライン攻撃に耐性のある形式で保管
推奨事項
- 検証者のみが知る秘密鍵を使用した追加の暗号化操作
- この秘密鍵はハッシュ化されたパスワードとは別に保管
アクティベーション秘密（PIN）の要件
スマートフォンのロック解除PINなど、デバイス内で使用される秘密についても要件があります：
- 最低4文字（推奨は6文字以上）
- 完全に数字でも可
- 連続した失敗試行を10回以下に制限
- 一般的なPIN（123456など）のブロックリスト実装を推奨
- AAL3レベルでは、ハードウェア保護環境（セキュアエレメント、TPM、TEEなど）での検証が必須
実装への影響
これらの要件は、サービス提供者とユーザーの両方に影響を与えます：
サービス提供者にとって
- 既存のパスワードポリシーの見直しが必要
- ブロックリスト機能の実装
- パスワードマネージャーサポートの確保
- ユーザー教育の再構築
ユーザーにとって
- より記憶しやすいパスワードの選択が可能に
- パスワードマネージャーの使用が推奨される
- 不要な定期変更から解放される
- より良いユーザー体験
まとめ
NIST SP 800-63B-4は、セキュリティとユーザビリティのバランスを重視した、科学的根拠に基づくパスワードポリシーを提示しています。重要なポイントは以下の通りです：
- 長さが強度を決める – 複雑さよりも長さを優先
- 定期変更は不要 – 侵害の証拠がない限り変更を強制しない
- ブロックリストを活用 – 既知の弱いパスワードを積極的にブロック
- パスワードマネージャーを推奨 – 技術でユーザーを支援
- ユーザー体験を重視 – セキュリティとユーザビリティは両立できる
デジタルアイデンティティの管理において、パスワードは今後も重要な役割を果たし続けるでしょう。NIST SP 800-63B-4の指針に従うことで、より安全で使いやすいシステムを構築できます。
あなたの組織やサービスのパスワードポリシーは、これらの最新基準に沿っていますか？今こそ見直しの時期かもしれません。
（なお、もうちょい専門的に書いたものは別途Short でない YouTube動画で作ろうと思っています。乞うご期待）
結局あんまり詳しくできなかったけど、YouTube動画つくりました。ご笑覧ください。（生配信とかで質問受けながらやったほうが時間もかからなくて良いなーとも思いながら、ちょっと時差のあるところにおりまして＠西海岸）
附属書A パスワードの強度について
@yunishioさんにツイート(Xのポスト)で指摘されまして、確かに誤解を招くなと思ったので、本文に下線を引いて追記したと同時に、以下に詳細を記述します。
まず前提知識として、本文で挙げた「correct horse battery staple」は、アメリカのウェブコミック「xkcd」のパスワード強度の啓発を目的とした936話”Password Strength”（2011年8月）で、「長くて人間に覚えやすいパスフレーズ」の具体例として使われました。このフレーズはパスワード強度の議論で半ば象徴となっており、実際にパスフレーズ方式を啓蒙した歴史的な存在となっています。逆に言うと、このパスフレーズは当然パスワード登録の際のブロックリストに入っていなければいけないことになります。
さて、本文にも追記しましたが、SP800-63-4で言っているのは、記号や数字の組み合わせを要求すると、ありきたりの単語にありきたりの置き換えルールを適用したものになることが実証されているのでやめろ、ということです。このことを踏まえてエントロピーを計算します。
まずパスフレーズから行きましょう。
単語フレーズのエントロピーの計算
まず前提の公式をおさえておきましょう。
エントロピー（ビット）＝ log2(試行空間の大きさ)。
試行空間が X 個なら情報量は log2(X) ビットです。
辞書サイズ N から k 語をランダムに選ぶとき：
H = k log2(N)
となります。
- N=3,000：1語あたり log2(3000)≈11.55ビット
→ 4語： 4×11.55≈46.20ビット - N=25,000 (Cambridge Concise English Dictiionaryの大まかな単語数)：1語あたり log2(25000)≈14.61ビット
→ 4語： 4×14.61≈58.44 ビット
となり、46.20〜58.44ビット程度となります。
一方、英数62種（a–z, A–Z, 0–9）から8文字をランダムに選ぶ場合は、
- log2(62)≈5.9542 ビット/文字
- → 8×5.9542≈47.63≈47.63 ビット
となり、同程度であり、英数2文字の情報量は 2×log2(62)≈11.912ビットで、1語（3,000語均等）は ≈11.55 ビット となり、確かに@yunishioさんのおっしゃるように「ほぼ2文字」となります。
が、ここのポイントは、ランダムに選ばれた62文字とパスフレーズの比較ではないということです。
上記の通り、NISTが指摘しているのは、大文字小文字記号混じりを強制すると、ありがちなパスワードをありがちな置き換えルールで処理したものになりがちなことであり、比較対象はそちらです。
では次に、ありがちなパスワードの置き換え処理版の強度を考えてみましょう。
「P@ssw0rd」系のモデル（攻撃者が辞書＋置換ルールで試す場合）
攻撃者が用いる試行数をモデル化：
試行数=B×S×C
- B：考慮する基底語（base words）の数（例：top 1, top 100, top 1,000, top 10,000）
- S：置換パターン（leet変換など）の数（例：5, 10, 30, 100）
- C：大文字/小文字の変化パターン数（例：1, 2, 4）
代表的な組み合わせで計算（log2は下に展開）：
- 極めて限定的（狙い撃ち：その単語だけ、置換少なめ）
- B=1,S=10,C=2 → 試行数 = 1×10×2=20
log2(20)≈4.32ビット
- B=1,S=10,C=2 → 試行数 = 1×10×2=20
- 小さな常用語リストを使う攻撃者
- B=100,S=10,C=2 → 試行数 = 2,000
log2(2000)=log2(2×1000)=1+log2(1000)≈1+9.96578=10.97 ビット
- B=100,S=10,C=2 → 試行数 = 2,000
- より広いだが現実的な辞書＋多めの置換
- B=1000,S=30,C=2 → 試行数 = 60,000
log2(60,000)=log2(1000+log2(30)+log2(2)≈9.96578+4.90689+1=15.87 ビット
- B=1000,S=30,C=2 → 試行数 = 60,000
- 攻撃者がかなり大きなリスト＋置換を試す場合
- B=10,000,S=30,C=4 → 試行数 = 1,200,000
log2(1,200,000)≈20.19 ビット
- B=10,000,S=30,C=4 → 試行数 = 1,200,000
- 極端に広い置換パターン（最悪ケース）
- B=10,000,S=100,C=4 → 試行数 = 4,000,000
log2(4,000,000)≈21.93 ビット
- B=10,000,S=100,C=4 → 試行数 = 4,000,000
となり、どの現実的なモデルでも「P@ssw0rd 系の変形」は 20–22ビット程度までしか伸びない（普通はもっと少ない）ケースが多い。
つまり、４語パスフレーズのエントロピー46.20〜58.44ビット ＞ 「P@ssw0rd」 のような文字置換パターンのエントロピー 4.32〜21.93ビットで、４語パスフレーズのエントロピーは文字置換パターンのエントロピー より桁違いに大きい、ということがここのポイントです。
なお、パスフレーズは覚える必要がある場合であり、この場合でも、ランダムに十分大きな語彙群から選ぶ必要があります。辞書を使うのであれば、辞書をランダムに開いて、目をつぶってページを指さして、その見出し語を抜き出す、これを必要回数繰り返す、ような形になります。ま、面倒なので、パスフレーズ生成機能のあるパスワードマネージャーに選んでもらったほうが楽ですね。
覚える必要のないもの（＝ほとんど）はパスワードマネージャーを使ってランダムな文字列15文字以上を推奨いたします。ま、一言で言えば、パスワードマネージャーを使え、そうすればパスキー移行も簡単になる、ということであったりします。