NIST SP 800-63B-4
2025年7月，米国National Institute of Standards and Technology（NIST）がNIST SP 800-63 Digital Identity Guidelines Revision 4を公開した．以下は Tue, 26 Aug 2025 08:51:12 -0500 公開版を参照している．
このうち，認証及び認証管理について扱うSP 800-63B-4では，各種の認証方式及び認証方式に用いる要素の定義・要件等が含まれる．本記事ではとくに認証用パスワードについて扱う．
Note: ここでパスワードとは，専ら知識認証の為に用いるシークレットを指すもので，暗号鍵及び署名鍵その他秘密鍵並びに鍵生成のシードとして用いられるシークレット等を含まないことに注意しなければならない．（実際には流用されることがあるとしても．）
Section 3.1.1.2 Password Verifiersは以下の通りである．
The following requirements apply to passwords.
- Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.
- Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
- Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
- Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
- Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
- Verifiers and CSPs SHALL NOT permit the subscriber to store a hint (e.g., a reminder of how the password was created) that is accessible to an unauthenticated claimant.
- Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
- Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).
パスワードエントロピー
まず $N$ 通りの文字から長さ $L$ の文字列を一様に乱択した場合のエントロピー（ITエンジニア向けに言えばデータ表現に必要な最低ビット数）は
$$L \log_{2} N$$
であったことを思い出そう．これがピュアな文字列総当たり（ブルートフォース）攻撃に対する強度の指標となる．
これは一様に乱択された場合である．人間が自分で考えるパスワードは一様分布からは程遠い分布をしている．よってそのエントロピーは $L \log_{2}(N)$ よりも著しく小さい．一般にアルファベット（文字列集合） $S$ 上の長さ $L$ の文字列を（一様である必要はない）乱択する状況は確率質量関数 $p\colon S^{L} \to [0, 1]$ により表され，そのエントロピーは
$$ H\left(p\right) := - \sum_{w \in S^{L}} p\left(w\right) \log_{2}\left(p\left(w\right)\right) $$
である．この値は $p$ が一様分布のとき最大値
$$ H(p_{\mathrm{unif}}) = L \log_{2}\left|S\right| $$
をとる．
パスワード長
上記の式から直ちに分かるように，パスワード強度を高めたいなら，何よりもまず長くするのがよい．項目(1)にて最低長を指定しているのもそれが理由である．
(2)についても同様．単語数の多いパスフレーズを使おうとして長さ制限に引っかかるという問題もある．Password Validationが「12文字以下しか受け付けない」というふざけたWebサービスが金融機関の中にすら現実に存在する．(2)に対応できていないサービスは速やかにサ終対応すべきである．
(9)について．パスワード設定ページでは任意長文字列を入力できたのに，ログインページでは一定文字以下しか受け付けない，あるいは勝手にtruncateしてから送信して認証する（それゆえログイン不能となる）という，冒涜的なWebサイトが存在するようである．
文字種
(3)について．文字種よりも文字数の方がエントロピーには支配的とはいえ，あまりに文字種が少ないと必要パスワード長が長くなりすぎる．（パスワードマネージャを使うなら長くても構わないが．）認証システムがパスワードとして十分多くの文字種を許容しているならば，実際のパスワードにはそのうち一部の文字種しか使われていなかったとしても，総当たりにおいて文字種の限定の手がかりが失われるので，より望ましい．というより文字種を制限する合理的理由がないなら制限しなくてもよい．ASCII印字可能文字ならば文字コード絡みのバグも起きないだろう．
重要なのは(5)である．文字種混合などの追加要件を課してはならない（SHALL NOT）という内容である．第一に，既に述べたようにパスワード強度を増やしたいなら，文字種を増やすより長さを増やす方がよい．文字種は対数でしか寄与しない一方で長さは線形で寄与するからである．第二に，このような文字種制限を用いると，パスフレーズが使えなくなったり，一部のパスワードジェネレータとの互換性が損なわれたり，碌なことにならない．第三に，前述の通り文字種は混合「可能」であることによって強度に寄与するのであって，混合「する」ことで強度に寄与するのではない．
文字種別毎のエントロピーへの寄与を幾つか計算しておく．
| character set | $N$ | $\log_2{N}$ | ratio (vs. latin alphabet) |
|---|---|---|---|
| [a-z] or [A-Z] | $26$ | $4.70$ | $1$ |
| [a-zA-Z] | $52$ | $5.70$ | $1.21$ |
| [a-zA-Z0-9] | $62$ | $5.95$ | $1.27$ |
| Base64 | $64$ | $6$ | $1.28$ |
| ASCII printable | $95$ | $6.57$ | $1.40$ |
半角英小文字のみからASCII印字可能文字まで広げたところでパスワード長を1.40倍にしたのと同程度しかエントロピーが増えないのである．
ここから128bit, 192bit, 256bitエントロピーを実現するために必要なパスワード長も計算しておこう．（ただし認証用のパスワードにおいて128–256bitエントロピーが要求されているわけではない．）
| character set | 128bit | 192bit | 256bit |
|---|---|---|---|
| [a-z] or [A-Z] | $27.23$ | $40.85$ | $54.46$ |
| [a-zA-Z] | $22.45$ | $33.68$ | $44.91$ |
| [a-zA-Z0-9] | $21.50$ | $32.25$ | $42.99$ |
| Base64 | $21.33$ | $32$ | $42.67$ |
| ASCII printable | $19.48$ | $29.22$ | $38.97$ |
ちなみに某金融機関の「半角英数12文字」のエントロピーは $71.45$ である．これでログインできるので最悪なのだが，振替・出金等の重要（write accessが必要？）な手続きにはTOTPトークンなど多要素認証（MFA）を設けているので，最悪の中ではマシかもしれない．それでも口座出入金記録などはMFAなしで閲覧できるのだが．
ところで，(1)における最低15文字というのを上の表と比較してみると，やや短すぎるように思われるかもしれないが，Webサイトのログイン認証においては，ログイン試行回数のレートリミットを設けることによりブルートフォース攻撃を緩和できる．（ゆえに15文字でも最低限問題ない．）したがってログイン試行回数のレートリミットはmandatoryである．
レートリミットは Section 3.2.2 Rate Limiting (Throttling) にて言及されている．
When required by the authenticator type descriptions in Sec. 3.1, the verifier SHALL implement controls to protect against online guessing attacks. Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator. If more than one authenticator is involved with an excessive number of authentication attempts (e.g., single-factor cryptographic authenticator and centrally verified password), both authenticators SHALL be disabled. Authenticators that have been disabled SHALL be required to rebind to the subscriber account, as described in Sec. 4.1, to be usable in the future.
こうしたレートリミットを設けられないシークレット（暗号通信路における暗号鍵のシードなど）については，認証に用いられるパスワードと同等の強度では不足ということでもある．パスワードポリシーを誤って鍵生成のシード値に適用してはならない．
パスフレーズ
パスフレーズは（理想的には）ランダムに選んだ幾つかの単語を連結したものである．区切り文字としてhyphenを用いる場合もある．通常の一様ランダムパスワードが文字集合からの乱択の繰り返しにより得られる（シード値を自動生成してハッシュ関数を嚙ませている場合もあるが）のに対して，パスフレーズは辞書からの乱択によって得られる．
パスフレーズは以下の利点がある：
- 非常に長いパスワードを容易に作成できる
- （どうしても覚えておく必要がある用途において）比較的覚えやすい
一方，辞書から作っているのだから，攻撃者がパスフレーズであると仮定できる場合，辞書攻撃には脆弱である．これも前述の通りログイン試行回数のレートリミットによって緩和される．（例えば，zipパスワードにオンライン認証用と同強度のパスフレーズを使用した場合，辞書攻撃によって現実的な時間で突破されうる．オフライン攻撃が可能な用途ではより高いエントロピーが必要である．）
もし無制限にログインを試行できるようなサービスを見つけた場合，直ちに解約すべきである独立行政法人情報処理推進機構（IPA）の脆弱性関連情報の届出受付より届出を行ってほしい．
秘密の質問
(8)は「秘密の質問」のような認証方式を排除している．パスワードリセットにおける「秘密の質問」も認証には違いなく，そこで使う「秘密の質問の答え」も認証用パスワードには違いない．
これの何が最悪かと言ったら
- ソーシャルエンジニアリングに弱い
- 複数サービスで同じ「シークレット」を使い回すことを強制することになる（初恋の相手がサービスごとに変わるような面白ユーザはいないだろう）
もし「秘密の質問」の設定を強制するサービスに遭遇したら，直ちに解約パスワードジェネレータでランダムパスワードなりパスフレーズなりを生成して登録すべきである．
- 「あなたの初恋の相手の名前は？」
- 「81c0rn-r4pp1n6-m1n3r5」
ところで府省共通研究開発システム（e-Rad）は「秘密の質問」（3問分）の設定を必須としている．（2026年2月7日現在）以下はe-Radにおける秘密の質問設定画面である：
申請者は研究開発よりもまずセキュリティポリシーの改訂が急務ではないかと考える．