パスワード強度とエントロピー — Shannon と NIST SP 800-63B の数学

Claude Shannon が 1948 年の論文 "A Mathematical Theory of Communication" で定式化した情報量を、各位置が候補集合から一様かつ独立に選ばれるランダム生成値へ適用すると:

エントロピー (bits) = log₂(候補数^長さ)
                   = 長さ × log₂(候補数)

候補数は使用文字の種類数です。人が選ぶパスワードは選択確率が一様ではないため、同じ式をそのまま実効強度として使えません。以下は一様生成時の候補総数です。

この表から読み取れること:

• 62種類から94種類への候補追加は、既存の各位置につき log₂(94) − log₂(62) ≈ 0.60 bit増える
• 26種類から52種類への候補追加は、既存の各位置につき 1 bit増える
• 長さを1文字増やす効果は、その時点の候補数を N として log₂(N) bit。候補追加の効果は既存の長さ全体へ掛かるため、どちらが増えるかは、現在の長さと候補数で変わります

94種類は空白を除く印字可能ASCII全体を仮定した数です。NanToo生成器の実際の記号集合と同一とは限らず、画面の候補数・除外設定に応じて計算します。

探索空間のビット数だけから「何年で破られる」とは決められません。オンライン攻撃は、サービス側のレート制限、追加認証、ロックや監視の設計に左右されます。NIST SP 800-63B-4も失敗回数を実効的に制限するよう求めていますが、すべてのサービスへ共通する「毎秒何回」という速度は定めていません。

オフライン攻撃は、漏えいした保存データの形式、salt、パスワードハッシュ方式、cost・メモリ・並列度、攻撃側の機器と予算で速度が変わります。高速なSHA-256の測定値や暗号資産向けASICの速度を、そのまま一般のパスワード検証へ移すことはできません。

したがって本記事とパスワード生成ツールでは、ビット表示を同じ一様生成モデル内で候補総数を比較する値として扱います。特定サービスでの突破時間、安全・危険の境界、アカウント全体の安全性を保証する値ではありません。

サービスの検証側は、パスワードを平文や単純な高速ハッシュとして保存せず、値ごとのsaltとcost factorを受け取る適切なパスワードハッシュ方式を使います。NIST SP 800-63B-4は、この保存方式によって漏えい後の各推測を高コストにするよう求めています。

RFC 9106は、パスワードハッシュ用途のmemory-hard関数Argon2を規定し、相互運用実装がArgon2idをサポートするよう定めています。メモリ量、反復回数、並列度は独立した入力であり、配備環境と脅威モデルに合わせて選ぶ必要があります。

方式名だけで安全になるわけではありません。パラメーター、実装、saltの一意性、移行手段、秘密鍵を追加利用する場合の分離保管まで含めて検討します。逆に、保存側が強いことを理由に、短い値や使い回しを安全とみなすこともできません。

NIST（米国国立標準技術研究所）の現行版はSP 800-63B-4です。以下は中央で検証するパスワードについて、検証側へ示した主な要件です。

課してはならないもの

• 漏えい等の証拠がない状態での定期変更の強制
• 大文字・小文字・数字・記号などの文字種混在規則
• 秘密の質問などの知識ベース認証をパスワード選択時に要求すること

必須事項（SHALL）

• 単一要素認証では最低15文字。多要素認証の一部だけに使う場合でも最低8文字
• 既知の頻出・予想可能・漏えい済み値を含むblocklistとの照合
• パスワードマネージャーと自動入力の許可
• 認証試行のレート制限と、適切なsalt付きパスワードハッシュによる保存

これらはサービスの検証側への要件です。ランダム文字列生成器の長さ選択と、サービスが受理・保存・試行制限する契約は分けて評価する必要があります。

推奨事項（SHOULD）

最大長を少なくとも64文字まで許容し、印字可能ASCIIと空白、Unicodeを受理すること、貼り付けを許可することは推奨事項です。Unicodeを受理する場合、長さはコードポイント単位で数えることが必須で、ハッシュ前のNFC正規化は推奨です。必須事項と推奨事項は区別して評価します。

blocklistはパスワード全体を照合し、一部の単語や部分文字列だけで拒否する要件ではありません。端末のローカル解除PIN等のactivation secretは別節の対象です。NISTは米国の技術指針であり、すべての地域・サービスの法的義務を示すものではありません。

Dicewareは、サイコロまたは同等の一様な乱数で番号を作り、対応するワードリストから単語を選ぶ方式です。

1. 6面サイコロを5回振り、7,776通りの番号を作る
2. 番号に対応する単語をリストから1つ選ぶ
3. 必要な単語数まで、各回を独立に繰り返す

この手順が守られる場合、1単語の探索空間は log₂(7776) ≈ 12.9 bit、6単語なら約77.5 bitです。ただし、人が好きな単語や自然な文を選んだ場合は一様・独立という前提が崩れ、同じ計算は使えません。利用先が空白や長い値を受理するかも別途確認が必要です。

NanTooのパスワード生成ツールは文字候補から生成するもので、Diceware用ワードリストや単語型パスフレーズは生成しません。

サービスごとに異なるランダム値を使うと、人がすべてを記憶するのは難しくなります。利用する場合は、信頼できるパスワードマネージャーの保管、同期、復旧、共有、端末紛失時の設計を確認してください。

• 各サービスでは同じ値を使い回さず、利用先が受理する十分な長さにする
• マネージャーを開くための認証情報は、その製品の要件と復旧手順に合わせる
• 多要素認証、復旧コード、信頼済み端末の管理を保管庫とは別の障害点として確認する

本ツールで「コピー」を使うと、結果は端末のクリップボードにも渡ります。保管先へ移した後も、画面を消すだけでクリップボードが消去されるとは限りません。

多要素認証は、知識・所持・生体など異なる種類の要素を2つ以上使う認証です。パスワードと所持要素を組み合わせる方式に加え、所持する暗号学的認証器を生体照合で解除する方式もあり、中央で検証するパスワードを必ず使うわけではありません。ただし、方式ごとに脅威への耐性が異なり、「二要素なら同じ強さ」とは限りません。

• 手入力するTOTPや他のOTPは、コードを偽サイトへ中継され得るため、NIST上はフィッシング耐性がありません
• WebAuthn等の暗号学的認証も、要件を満たす実装で初めてフィッシング耐性として扱えます
• 同期、端末拘束、鍵のexport可否、復旧手段によって到達できる保証レベルは変わります

多要素認証を有効にしても、使い回し、端末侵害、セッション窃取、復旧経路の乗っ取りまで自動的に解決するわけではありません。利用先が提供する方式と復旧条件を確認してください。

1. 利用先の長さ・文字要件を確認し、単一要素認証では15文字以上を基準にする
2. サービスごとに異なる値を使い、信頼できる管理手段へ保管する
3. 生成器では、乱数源、候補への割り当て、候補集合、長さを別々に確認する
4. 利用先が提供する場合は、多要素認証とフィッシング耐性のある選択肢を区別して検討する
5. パスワードを不明な確認サイトへそのまま送信しない。サービス側は漏えい・頻出値のblocklistを使う
6. 漏えいの証拠や不審利用がある場合は変更し、理由のない定期変更は前提にしない
7. 文字種の数だけでなく、長さ、保存方式、レート制限、復旧経路まで分けて評価する

• 長さ × log₂(候補数)は、一様・独立に生成した値の候補総数を表す
• 同じ式を人が選んだ値の実効強度や、固定の解読時間へ置き換えない
• NIST SP 800-63B-4は、単一要素で最低15文字、MFAの一部で最低8文字を必須とし、最大長を少なくとも64文字まで許容することを推奨する
• 検証側は文字種混在や理由のない定期変更を課さず、blocklist、レート制限、salt付き専用ハッシュを組み合わせる
• OTPとフィッシング耐性のある暗号学的認証は同じ性質ではない
• 生成・保管・認証・復旧を別々の契約として確認する