Webサービスやシステムを作っていると、パスワードに何文字以上を求めるか、大文字や記号を混ぜさせるかを決める場面が出てきます。公的なガイドラインの原文を、当たれるだけ当たりました。文字種を混ぜろと書くかどうかは、その文書が誰に向けて書かれているかで分かれます。最低文字数は8から15まで開いていて、改訂で引き上げた資料と引き下げた資料がありました。定期的な変更を求めるなという点だけは、読んだ資料が一致していました。
NISTは文字種を混ぜさせること自体を禁じた
NIST SP 800-63B の rev.3 は、5.1.1.2 Memorized Secret Verifiers でこう書いています。以下、英語の資料からの引用はすべて筆者による訳です。
検証者は、記憶された秘密に対して他の構成規則（たとえば異なる文字種の混在を求める、同じ文字の連続を禁じるなど）を課すべきではない（SHOULD NOT）。検証者は、記憶された秘密を理由なく（たとえば定期的に）変更させることを求めるべきではない（SHOULD NOT）。ただし、認証子が危殆化した証拠がある場合には、検証者は変更を強制しなければならない（SHALL）。
検証者は、ログインを受け付けるシステムのことです。文字種の混在も定期変更も、どちらも SHOULD NOT です。推奨であって、禁止ではありません。
rev.4 の 3.1.1.2 には、同じ2つの文が、SHOULD と SHALL のところだけを変えて残っています。CSP は、利用者の身元を確認して、認証手段をアカウントに登録する事業者のことです。
検証者およびCSPは、パスワードに対して他の構成規則（たとえば異なる文字種の混在を求めるなど）を課してはならない（SHALL NOT）。
検証者およびCSPは、加入者にパスワードを定期的に変更させることを求めてはならない（SHALL NOT）。ただし、認証子が危殆化した証拠がある場合には、検証者は変更を強制しなければならない（SHALL）。
SHOULD NOT が SHALL NOT になりました。「課すべきではない」が「課してはならない」に変わっています。
変更履歴に載っているのは最低文字数だけ
rev.4 には Change Log が付いていて、最初の公開からの変更点が並んでいます。3.1.1.2 について挙がっているのは1行です。
3.1.1.2節 単一の認証要素として使うパスワードの最低文字数を引き上げた
書かれているのは長さだけです。文字種と定期変更が SHOULD NOT から SHALL NOT になったことは、この一覧に項目として出てきません。推奨が禁止に変わっても、変更履歴を読んだだけでは気づけません。
撤回された旧版は、混ぜることを求めていた
同じNISTのSP 800-63-2 Electronic Authentication Guidelineは、2013年8月に公開され、2017年6月22日に撤回されています。表紙に「添付の刊行物はアーカイブ（撤回）されており、記録として残す目的でのみ提供される」と付いた状態でいまも読めます。その Appendix A に、利用者が選ぶパスワードの強度を上げる方法が2つ並んでいます。1つは辞書テストで、もう1つが構成規則です。
構成規則。小文字、大文字、英字以外の記号を含むパスワードを選ぶよう利用者に求めるのが通例である。
そして、その効き目についてはこう書いてあります。
辞書テストにせよ構成規則にせよ、いくつかのパスワードを排除し、推測攻撃や総当たり攻撃で攻撃者がパスワードを見つけるために試さなければならない範囲を狭める。しかし、これらはありがちな候補を数多く排除できるので、真に網羅的な攻撃に必要な作業量は減らすものの、パスワードの「実質的なエントロピー」を全体として高めると我々は考えている。
エントロピーの見積もり表には、計算方法まで書いてあります。
大文字と英字以外の文字の両方を求める構成規則には、6ビットのエントロピーの「ボーナス」を与える。
文字種を混ぜさせると6ビット足す、という扱いです。
加点はエントロピーの見積もりの話ですが、構成規則は要件のほうにも入っています。同じ文書の本体には、保証レベルごとの要件を並べた Table 6 があります。記憶された秘密については、レベル1で6文字以上、レベル2で8文字以上を挙げ、どちらも90種類以上の文字から選ぶことを前提にしています。レベル2には、これに続けてもう1つ書いてあります。
CSPは、利用者が生成する秘密に制限をかけるために、辞書テストか構成規則を導入する。
shall は付いていませんが、要件を並べた表に書いてある1行です。同じ組織が、この文書では加点の対象にし、レベル2では導入まで求めていた規則を、rev.4 では課してはならないものに変えました。推奨が逆転しています。
理由は「Password1!」
rev.4 の Appendix A Strength of Passwords が、その理由を書いています。
しかし、構成規則による要求に対して利用者は非常に予測しやすい形で反応することが、研究によって示されている。たとえば、パスワードとして “password” を選んだであろう利用者は、大文字と数字を含めることを求められれば “Password1” を、記号も求められれば “Password1!” を選ぶ可能性が比較的高い。
規則を足しても利用者の選び方は広がらず、かえって狭い範囲に固まるという話です。同じ Appendix の締めくくりには、代わりに何をするかまで書いてあります。
ここで推奨するものを超える長さと複雑さの要求は、利用者の不満を大きくし、パスワードを使いにくくする。その結果、利用者はしばしば、かえって逆効果になるやり方でこれらの制限をすり抜ける。ほかの緩和策（たとえばブロックリスト、安全なハッシュによる保管、システムが生成するランダムなパスワード、レート制限）のほうが近年の総当たり攻撃を防ぐのに効果的であり、そのため追加のパスワード要件は課さない。
OWASPは、文書ごとに言うことが違う
Authentication Cheat Sheet は、NISTと同じことを書いています。
Unicode と空白を含むすべての文字の使用を許すこと。許可する文字の種類を制限するパスワードの構成規則はあるべきではない。大文字や小文字、数字、特殊文字の要求はあるべきではない。
長さの基準は、多要素認証があるかどうかで分かれています。多要素認証が有効なら8文字未満、有効でないなら15文字未満を弱いとみなす、という書き方です。参照しているのは rev.4 のパスワード検証者の節でした。
ASVS 4.0.3 の要件 2.1.9 と 2.1.10 も同じ向きです。
2.1.9 許可する文字の種類を制限するパスワードの構成規則が無いことを検証する。大文字や小文字、数字、特殊文字の要求はあるべきではない。
2.1.10 定期的な資格情報の変更や、パスワード履歴の要求が無いことを検証する。
5.0 でも、構成規則を課すなという要件は残り、レベル1に置かれています。
6.2.5 許可する文字の種類を制限する規則なしに、どのような構成のパスワードでも使えることを検証する。大文字や小文字、数字、特殊文字を何文字以上含めという要求があってはならない。
4.0.3 の原文は should で、5.0 は must です。NISTが SHOULD NOT を SHALL NOT に変えたのと同じ向きに、こちらも強まっています。
他と向きが違うのは、診断の手順書です。Web Security Testing Guide の WSTG-ATHN-07 は、診断で確認する項目の1番目にこれを置いています。
パスワードの中で使える文字と使えない文字は何か。小文字と大文字、数字、特殊文字のような異なる文字種から文字を使うことを、利用者に求めているか。
対策の節にも残っています。
このうち最も単純で安価なのは、パスワードの長さ、複雑さ、再利用、有効期限を定める強固なパスワードポリシーの導入である。
複雑さと有効期限が、強固なパスワードポリシーの構成要素として並んでいます。同じページの別の箇所では、有効期限による定期変更について NIST と NCSC の立場を紹介したうえで、こう続けています。
NIST も NCSC も、定期的なパスワードの有効期限を強制しないよう勧めている。ただし PCI DSS のような基準では求められることがある。
PCI DSS の原文は、ダウンロードに失敗して読めませんでした。ここで引けるのは、OWASPがそう書いているという事実だけです。
決める人に向けた日本の資料は「混ぜろ」と書く
IPAのチョコっとプラスパスワードは、安全なパスワードの条件を3つ挙げています。以下、日本語の資料からの引用は原文の表記のまま載せます。
数字・英大文字・英小文字を組み合わせてできるだけ長い文字数（15桁程度）で
構成されている。
より安全性を高めたい場合は記号を追加している。15桁程度で、数字と英大文字と英小文字を組み合わせる。記号は追加すればさらに良い、という順序です。
総務省の推測できる簡単なパスワードを利用しないようにしようにも、文字数と文字種の両方が書いてあります。
理想的には、最低でも10文字以上の文字数で構成されるある程度長いランダムな
英数字の並びとし、パスワード内に数字や記号、アルファベット（大文字、小文字）
が混ざっていることが好ましいですが、覚えなければならないパスワードの場合は、
無関係な（文章にならない）複数の英単語をつなげたり、その間に数字列を挟んだり
したものであれば、推測されにくく、覚えやすいパスワードを作ることができます。同じ総務省のサイトには、社員・職員に向けた安全なパスワードの設定・管理というページもあります。書き出しはほとんど同じ文で、文字数と文字種のところだけが消えています。
理想的には、ある程度長いランダムな英数字の並びが好ましいですが、覚えなければ
ならないパスワードの場合は、英語でも日本語（ローマ字）でもよいので無関係な
（文章にならない）複数の単語をつなげたり、その間に数字列を挟んだりしたもので
あれば、推測されにくく、覚えやすいパスワードを作ることができます。「最低でも10文字以上」と「数字や記号、アルファベット（大文字、小文字）が混ざっている」が、まるごと落ちています。同じサイトの、どちらもパスワードを決める人に向けたページです。
内閣官房のインターネットの安全・安心ハンドブック Ver 5.10は、パスワードと呼ばれるものを3つに分け、そのうちの1つを「ログインパスワード」と名付けています。定義に文字種が入っています。
パソコンやデジタル機器、ウェブサービスなどの利用時に ID とセットで入力し、
英大文字小文字、数字、記号を用い複雑さと一定以上の長さが推奨されるもの3つの分け方には理由が書いてあります。PINコードは数回間違えるとロックや初期化が働くので4桁から6桁以上の数字でよく、ログインパスワードは画面から1秒に数回から数十回しか試せないので、その速度を前提に複雑さを決める、という説明です。
暗号キーだけは条件が違います。攻撃者がデータを持ち帰って、手元で好きなだけ時間をかけて解読できるため、英大文字小文字と数字と記号で完全にランダムに、桁数はできるだけ増やす、と別扱いになっています。文字種を混ぜろという要求が最も強く出るのは、画面から打つ速さでは頭打ちにならないこの3つ目でした。
作る人に向けた日本の資料は混ぜろと書かない
IPAの安全なウェブサイトの作り方 改訂第7版にも「2.5 パスワードに関する対策」という節があります。文字種が出てくるのは1箇所だけで、利用者が決めるパスワードの話ではありません。
初期パスワードは、暗号論的擬似乱数生成器を利用して規則性をなくし、可能であれば
英数字や記号を含めた長い文字列で発行してください。システムが発行する初期パスワードについての記述です。利用者が自分で決めるパスワードに何文字以上を求めろとも、何種類を混ぜさせろとも書いてありません。
同じ節に並んでいるのは、初期パスワードに規則性を持たせない、変更時に現行パスワードを求める、エラーメッセージでユーザーIDとパスワードのどちらが誤りか分からないようにする、伏字の入力欄を使う、ソルト付きハッシュで保管する、といった項目です。パスワードそのものではなく、その扱い方を並べています。
別冊のウェブ健康診断仕様には、認証の診断項目が6つ並んでいます。文字数と文字種はその1番目と2番目ですが、見ている向きが逆です。
パスワードの最大文字数が8文字以上確保されているか 8文字未満の場合
パスワードの文字種が数字のみ、英字のみに限定されていないか 数字のみ、英字のみの場合左が診断で確認すること、右が脆弱性ありと判定する条件です。1番目は最大文字数で、8文字までしか入れられないサイトを指摘します。2番目は、数字だけ、英字だけしか受け付けないサイトを指摘します。どちらも、サイトが利用者を制限していないかを見ています。混ぜることを求めているかどうかは診断項目に入っていません。
内閣官房が出している政府機関等の対策基準策定のためのガイドライン（令和7年度版）の基本対策事項 7.1.1(1)-3 は、機能として何を設けるかを求めます。
情報システムセキュリティ責任者は、主体認証情報としてパスワードを使用し、主体
認証情報を付与された主体自らがパスワードを設定することを可能とする場合には、
辞書攻撃等によるパスワード解析への耐性を考慮し、強固なパスワードに必要な十分
な桁数を備えた第三者に容易に推測できないパスフレーズ等を使用することを利用者
に守らせる機能を設けること。「十分な桁数」で、具体的な文字数はありません。解説はその理由から説き起こしていて、文字種を足すことにも触れています。
強固なパスワードの要件を一律に定めることは困難であるが、少なくとも、一般的に
知られる単語1つを用いたものや、キーボードの並び順（「qwertyuiop」等）をなぞった
ものは、たとえそこに数字や記号を付加しようとも、脆弱であり、設定を許すべきでは
ない。辞書にある単語に数字や記号を付け足しても弱いまま、というのが NIST の「Password1!」と同じ指摘です。同じ解説は、パスワードチェッカーの選び方にまで踏み込みます。
既存のパスワードチェッカーの中には、単語1つやキーボードの並び順に数字や記号を
付加しただけで合格としてしまう不完全なものも散見されるので、注意を要する。代わりに推奨しているのは、ランダムに複数の単語をつなげたパスフレーズです。10万語の辞書から3語、2万語の辞書から4語、という例まで付いています。
Microsoftは、製品と推奨が食い違う
Microsoftのパスワードポリシーの推奨事項は、規則を足すこと自体を疑う書き方です。
人の行動を理解しておく必要があるのは、利用者に課すほとんどすべての規則がパスワードの質を下げる結果になると研究が示しているからである。長さの要求、特殊文字の要求、パスワード変更の要求は、どれもパスワードの画一化を招き、攻撃者が推測したり破ったりするのを容易にする。
管理者向けの推奨として並ぶ項目に、文字種は入っていません。入っているのは長さです。
最低14文字という要求を維持する。（Microsoft 365 は最低8文字を求めるが、より強固にするために最低14文字を推奨する。）
長さの要求も画一化を招くと書いたページが、長さの要求を推奨しています。
同じMicrosoftのEntra ID のパスワードポリシーは、文字種を必須にしています。
最低8文字、最大256文字。次の4種類の文字のうち3種類を含めることを求める。小文字、大文字、数字（0-9）、記号
表の前置きには「注記がない限り、これらの設定は変更できない」とあります。表の中で変更できると注記されているのは有効期限に関する2行だけで、文字種の条件を外す方法は書かれていません。クラウドで直接作ったアカウントは、4種のうち3種を混ぜないとパスワードを設定できません。
Windowsのパスワードは、複雑さの要件を満たす必要があるも同じ向きです。有効にしたときの条件は、5つの分類のうち3つから文字を使うことで、分類はヨーロッパ言語の大文字、小文字、数字（0〜9）、英数字以外の特殊文字、アジア言語などの大文字小文字の区別がない文字です。推奨は明快です。
「パスワードは、複雑さの要件を満たす必要がある」を有効に設定する。このポリシー設定を最小パスワード長8と組み合わせると、1つのパスワードに対して少なくとも159,238,157,238,528通りの組み合わせが生まれる。
根拠として置かれているのは組み合わせの数え上げで、撤回された SP 800-63-2 のエントロピー表と同じ考え方です。
このページは previous-versions の下にあり、Best practices の冒頭には「最新のベストプラクティスは Password Guidance を参照」という注記が付いています。
混ぜろと書くのは、決める人に向けた文書だけ
文字種について立場がはっきりしている資料を、誰に向けた文書かと、混ぜろと書いているかで並べ直すと、Microsoftだけが左右にまたがります。
「混ぜろ」と「課すな」は食い違っているようで、宛先が違うだけです。自分のパスワードに文字種を混ぜるのは自由ですが、全利用者に強制すると “Password1!” が量産される、という話だからです。
Entra ID と Windows のポリシーが相手にしているのは、パスワードを決める本人ではなく、決めさせる仕組みを運用する管理者です。宛先は Microsoft 365 の推奨と同じで、向きだけが逆になっています。
イギリスの NCSC も、宛先はMicrosoftの2つと同じですが、向きはNISTと揃っていました。
複雑さの要求を課すこと、つまり職員が適度に複雑なパスワードしか使えないようにすることは、推測攻撃に対する防御としては貧弱である。
文字数は書いていません。最低文字数を定めよとは言うものの、何文字かは示さず、代わりに上限を設けるなと書いています。
CWE-521 は、禁止とも要求とも書いていません。最低文字数と最大文字数、再利用の制限、よく使われるパスワードの制限、そのサービスに固有の語の制限までを推奨し、そのあとにこう続きます。
脅威モデルによっては、パスワードポリシーにいくつかの項目を追加してもよい。
追加できる項目の1つ目は、文字種を混ぜさせる複雑さの要求です。欠点も併記されていて、そこには「人が記号を予測しやすい形で使うために、パスワード全体の複雑さが大きく増える結果にはならないことが多い」とあります。禁止はせず、脅威モデル次第の選択肢として残しています。
最低文字数は8から15まで開いている
ここまでは文字種の話でした。最低文字数で見ると、動いた向きが資料ごとに違います。
NIST SP 800-63B の rev.3 は「検証者は、加入者が選ぶ記憶された秘密に、少なくとも8文字の長さを求めなければならない（SHALL）」でした。rev.4 は8文字を条件付きにしています。
検証者およびCSPは、単一要素の認証手段として使うパスワードに、最低15文字の長さを求めなければならない（SHALL）。検証者およびCSPは、多要素認証の一部としてのみ使うパスワードについてはより短いものを許してもよい（MAY）が、最低8文字を求めなければならない（SHALL）。
パスワード1つでログインさせるなら15文字です。8文字が許されるのは、多要素認証の一部として使う場合だけになりました。一方で OWASP ASVS は、レベル1の要件を12から8へ下げています。5.0 の 6.2.1 は、要件と推奨を1行に併記する書き方に変わりました。
6.2.1 利用者が設定するパスワードが8文字以上の長さであることを検証する。ただし最低15文字を強く推奨する。
4.0.3 の 2.1.1 は「利用者が設定するパスワードが、（連続する空白をまとめたあとで）12文字以上の長さであること」で、推奨は併記されていません。検証する基準としては12から8へ下がり、推奨としては15が加わりました。
文字数を書いていた資料を、同じ目盛りに並べ直します。
撤回された SP 800-63-2 の6文字を別にすると、文字数は8、10、12、14、15と並び、大きく空いたところはありません。かといって1つに集まってもいません。
定期変更だけは一致している
文字種は文書ごとに違い、最低文字数は8から15まで開いていました。定期変更については、読んだ資料が同じことを言っていました。
- 定期的な変更を求めてはならない（NIST rev.4、OWASP ASVS 5.0 の 6.2.10）
- 定期的な変更を求めるのは避ける（OWASP Authentication Cheat Sheet）
- 定期的なパスワード変更は、セキュリティを高めるどころか損なう（NCSC）
- 危殆化の証拠があるときは変更を強制する（NIST rev.3 と rev.4）
日本の資料も同じです。総務省のページは、向きが変わった経緯まで書いていました。
これまでは、パスワードの定期的な変更が推奨されていましたが、2017年に、米国
国立標準技術研究所（NIST）からガイドラインとして、サービスを提供する側が
パスワードの定期的な変更を要求すべきではない旨が示されたところです安全・安心ハンドブックは、企業がルールを定める場合まで含めて書いています。
企業などでパスワードに関するルールを定める場合にも、利用者に対して定期的な
変更を求めないようにすることが原則として必要となります。対策基準ガイドラインの解説は、効果があるかどうかから検討していて、技術的な誤解の例を3つ挙げています。パスワードは当てられる前に変更すれば避けられるという誤解、共通鍵暗号の鍵の定期変更と混同した誤解、使用によってパスワードが劣化する通信プロトコルを使っているという誤解の3つです。1つ目への答えは、長さの話に戻ります。
結局のところ、パスワードは当てられない程度に十分に長くするほかないのであり、
その尺度には、例えば、「100年以内に1回以上当てられる確率が0.0001%以下」と
いった基準が考えられ、これを満たす長さのパスワードを設定していれば、定期的に
変更してもしなくても、当てられる確率はこれ以下に抑えられる。食い違っているのは、資料の立場ではなく更新の速さです。Windowsの最大パスワード有効期間は、Best practices の1行目にこう書いてあります。
環境に応じて、最大パスワード有効期間を30日から90日のあいだの値に設定する。
その直後に、注記が並んでいます。
Microsoft が推奨するセキュリティベースラインには、パスワードの有効期限のポリシーは含まれていない。近年の緩和策より効果が薄いからである。ただし、Microsoft Entra Password Protection や多要素認証、そのほかパスワード推測攻撃に対する近年の緩和策を導入していない企業は、このポリシーを有効なままにしておくべきである。
同じページの少し下には「パスワード変更の義務づけは長く続いてきたセキュリティの慣行だが、現在の研究は、パスワードの有効期限が逆効果であることを強く示している」ともあります。1つのページの中に、30日から90日という推奨と、それを含めないベースラインの話が同居しています。既定値は42日のままです。
先ほどの CWE-521 は、この経緯を緩和策の効果として書き残しています。パスワードの有効期限を説明する項目の Effectiveness が「Discouraged Common Practice」になっていて、本文はこう締めくくられています。
その結果、これは現在では推奨されない一般的な慣行であり、とくにパスワードを守る唯一の要素としてはそうである。危殆化の証拠がある場合にパスワード変更を強制することは依然として強く推奨されるが、これは期間を決め打ちにした強制的な「有効期限」とは別のものである。
文字種は脅威モデル次第の選択肢として残しながら、有効期限のほうは推奨しないと言い切っています。
どの資料が何を書いていたか
ここまでに開いた資料を、最低文字数と文字種と定期変更で一覧にします。
| 資料 | 最低文字数 | 文字種 | 定期変更 |
|---|---|---|---|
| NIST SP 800-63B rev.3 | 8文字 | 課すべきではない（SHOULD NOT） | 求めるべきではない（SHOULD NOT） |
| NIST SP 800-63B rev.4 | 単要素15文字、多要素の一部なら8文字 | 課してはならない（SHALL NOT） | 求めてはならない（SHALL NOT） |
| NIST SP 800-63-2（撤回済み） | レベル1で6文字、レベル2で8文字 | 混ぜると6ビットのボーナス（レベル2は辞書テストか構成規則を要求） | 記載なし |
| OWASP Authentication Cheat Sheet | 多要素ありで8文字、なしで15文字 | 構成規則はあってはならない | 求めるのは避ける |
| OWASP ASVS 4.0.3 | 12文字 | 構成規則が無いことを検証 | 定期的な変更が無いことを検証 |
| OWASP ASVS 5.0 | 8文字、15文字を強く推奨 | どんな構成でも使えることを検証 | 要求してはならない |
| OWASP Web Security Testing Guide | 記載なし | 求めているかを問う診断項目 | 有効期限を含むポリシーを推奨 |
| CWE-521 | 記載なし | 脅威モデル次第の追加項目 | Discouraged Common Practice |
| Microsoft 365 の推奨 | 14文字 | 要求しない（特殊文字の要求は画一化を招くと明記） | 有効期限を設けないことを推奨 |
| Microsoft Entra ID | 8文字から256文字 | 4種のうち3種を必須。変更不可 | 既定は無期限（2021年より前に作られたテナントは90日） |
| Windows のパスワードポリシー | 最小8文字と組み合わせた場合で説明 | 5分類のうち3つ。有効を推奨 | 既定42日、推奨30〜90日、ベースラインには含まれない |
| IPA 安全なウェブサイトの作り方 改訂第7版 | 記載なし | 初期パスワードにのみ言及 | 記載なし |
| IPA ウェブ健康診断仕様 | 最大文字数が8文字以上か | 数字のみ・英字のみに限定していないか | 記載なし |
| IPA チョコっとプラスパスワード | 15桁程度 | 数字・英大文字・英小文字を組み合わせる | 記載なし |
| 総務省 一般利用者向けページ | 最低でも10文字以上 | 数字や記号、大文字小文字が混ざっているのが好ましい | 不要 |
| 総務省 社員・職員向けページ | 記載なし | 記載なし | 不要 |
| インターネットの安全・安心ハンドブック Ver 5.10 | 一定以上の長さ | 英大文字小文字、数字、記号 | 基本は必要なし |
| 対策基準ガイドライン 令和7年度版 | 十分な桁数 | 一律に定めることは困難 | 真に必要な場合に限る |
| NCSC | 文字数の記載なし。上限は設けるな | 複雑さの要求は勧めない | 害になる |
変わるのは、混ぜろと言われて足した数字と記号
NIST が挙げていたのは “Password1” と “Password1!” の2つでした。実際に何が選ばれるのかを、もっと細かく並べた資料もあります。
文字種を課すと、元の単語に数字と記号が付く
NCSC は、複雑さの要求について、こうも書いています。
これは利用者に余計な負担をかける。利用者の多くは、求められる「複雑さ」の条件を満たすために、予測しやすいパターン（たとえば文字の o をゼロに置き換える）を使うことになる。
Microsoftの Entra Password Protection は、その置き換えを照合の前に元に戻します。新しいパスワードをまず全部小文字にし、「よくある文字の置き換え」を元に戻してから、禁止語の一覧と照合する仕組みです。例として挙がっているのは4つです。
| 元の文字 | 戻したあと |
|---|---|
| 0 | o |
| 1 | l |
| $ | s |
| @ | a |
添えてある例は、禁止語が “blank” のときに “Bl@nK” を弾く、というものです。Entra ID が求める4種のうち3種を満たしたパスワードが、小文字に直して置き換えを戻すだけで禁止語そのものになります。
同じページには、Contoso という会社を想定した変形の一覧もあります。ロンドンに拠点があり、Widget という製品を作っている会社です。
“Contoso!1”、“Contoso@London”、“ContosoWidget”、”!Contoso”、“LondonHQ” といった語の変形を個別に禁止しようとするのは、無駄であり、かえって安全性が下がる。
Microsoftの答えは単純です。“Contoso”、“London”、“Widget” という基になる語だけを禁止しておけばいい、と書いてあります。変形のほうは照合の仕組みが自動で弾きます。会社名に記号と数字を1つずつ足す、製品名や地名をつなげる、頭に記号を置く。挙がっているのは、その程度の作り方です。
定期変更を課すと、その数字が1つ増える
Yinqian Zhang、Fabian Monrose、Michael K. Reiter の The Security of Modern Password Expiration（ACM CCS 2010）は、まさにその条件を課していた環境からパスワードを集めています。対象はノースカロライナ大学チャペルヒル校のシングルサインオンで、文字の条件はこうです。
8文字以上でなければならない。英字と数字をそれぞれ1文字以上含まなければならない。次の特殊文字を1文字以上含まなければならない。
!@#$%&*+={}?<>"'3か月ごとの変更も義務で、変えないままのアカウントは停止されます。1年以内に同じアカウントで使ったパスワードは選べません。著者らが手に入れたのは、1つのアカウントで順に使われた4個から15個のパスワードハッシュです。解読してから中身を調べています。
論文は、古いパスワードから新しいパスワードを作る書き換え方を8つに分けています。括弧の中は論文が挙げている例です。
- 大文字にする（“17candy#” → “17candY#”）
- 数字や記号を削る（“alex28!!!” → “alex28!!”）
- 同じ数字や記号を重ねる（“stinson1!” → “stinson11!”）
- 数字や記号を同じ種類の別の文字にする（“tar!heel1” → “tar!heel2”）
- 数字の後ろに次の数字を足す（“dance#7” → “dance#78”）
- leet に置き換える（“raven#1&” → “r@ven#1&”）
- かたまりごと入れ替える（“$steve27” → “27$steve”）
- 同じキーの別の文字にする（“l00py*!2” → “l00py*!@”）
削る・置き換える・重ねるの3つには、扱う文字を絞った断り書きが添えてあります。
ただし、ここでいう特殊文字の置換・重複・削除は、パスワードに1つ以上含めるよう求められている文字だけを対象とする。
利用者が次のパスワードで書き換えるのは、条件を満たすために入れた文字です。
Appendix A には、当たった割合の高い順に50通りの書き換えが並びます。上から8つはこれです。
s/1/2/
s/2/3/
s/3/4/
s/4/5/
s/!/@/
s/5/6/
s/6/7/
s/@/#/先頭は 1 を 2 にする書き換え、次は 2 を 3 にする書き換えです。数字を1つ増やすだけの書き換えが上位を占めて、その間に記号の置き換えが挟まります。!@# はUS配列で1から3のキーをシフトで打った文字なので、記号のほうも同じ向きに1つずれているように見えます。論文がそう書いているわけではありません。
画面からの入力に限っても、50通りの書き換えを1つずつ当てはめるだけで、5回に満たない試行で17%のアカウントが当たりました。ハッシュが手元にあるなら、534通りの書き換えを3つまで組み合わせることで、41%のパスワードが当たりました。1件当てるのにかかった時間は、平均で3秒未満です（2.67GHzのプロセッサー）。論文の結論はこうです。
パスワードの強制的な有効期限が役に立つのかどうか、この研究は疑問を投げかけていると我々は考えている。
文字種の代わりに書いてあるもの
文字種を課すなと書いた資料は、その代わりに何をするかも書いています。共通しているのは、選ばせないのではなく、選ばれたものを弾く方法です。
NIST rev.4 の 3.1.1.2 は、ブロックリストとの照合を SHALL で求めます。照合するのはパスワード全体で、その中に含まれる部分文字列や単語ではありません。リストに載せるものの例として、過去の漏えいから得たパスワード、辞書の単語、サービス名や利用者名とその変形が挙がっています。弾いたときに理由を返すことも SHALL です。
リストの大きさには、増やしすぎるなという助言が付いています。ブロックリストが効くのはオンライン攻撃で、それはすでにレート制限で抑えられているため、リストを大きくしても得られるものはほとんど無い、というのが理由です。
ASVS 5.0 は、そのブロックリストの規模を件数で示しています。6.2.4 がレベル1で「アプリケーションのパスワードポリシーに合致する上位3000件」との照合を求め、6.2.12 がレベル2で、漏えいしたパスワードの一覧との照合を求めます。3000件という数は、NISTの「リストを大きくしても得られるものはほとんど無い」という助言と噛み合っています。
加えて 6.1.2 は、組織名や製品名、システムの識別子、プロジェクトのコードネーム、部署名や役職名とその変形を、そのサービスに固有の語の一覧として文書に書き出すことを求めています。
対策基準ガイドラインは、パスワードチェッカーを使うなら過去に流出が報告された文字列を弾くものを選べ、と例示していました。設定させない機能として並ぶのは、識別コードと同じパスワード、端末名やサーバー名や組織名を含むもの、初期値のまま、よく使われるパスワードの一覧と一致するもの、日付から想定される数字列、そしてこれらの一部の文字を似た文字に置き換えただけのものです。S を $ に、O を 0 に置き換える例が挙がっています。
文字種の要求は、この置き換えを利用者に促す規則でもあります。
同じ資料を、ログイン失敗の回数という切り口で読んだ記事もあります。
ブログログイン失敗、何回でロックアウト？ログイン失敗が続いたらアカウントをロックする定番の対策について、何回でロックするのかを公的なガイドラインに探しました。回数を書いている資料と書いていない資料に分かれ、書いてある数字も3回から100回までばらついています。