サポートが訪問先の同僚へゲスト Wi-Fi を口頭で伝える。運用担当が共有キーボードでルーター管理画面に入る。開発がテスト用アカウントへ新しいパスワードを配る。この三つは、「どんな文字列が要るか」が同じではない。最初の二つは手入力が前提だ。三つ目は、ほぼ必ずパスワードマネージャに入る。そこで多くの人が xkcd 936 を見る。Tr0ub4dor&3 は覚えにくいのに約28ビットしかなく、correct horse battery staple のよくある4単語は約44ビットある。ここから「4単語なら十分強い」が一般則のように広がった。
漫画の計算には前提がある。各単語は、よく使われる約2000語から一様ランダムに引いている(漫画は1語あたり11ビットで見積もる)。リストを100語に替えると、同じ4単語でも約27ビットしか残らない。漫画より一段弱く、16文字のランダム列より明らかに弱い。この記事は生成ボタンの押し方ではない。いつランダム文字を使い、いつパスフレーズを使い、4単語で足りるかだけを答える。MyPassGen の二つのモードは、登録なしで開いて使える。ランダム文字の初期値は16文字、パスフレーズは内蔵の100語から3–10語を取る。以下の数字は、電卓で自分でも検算できる。
先に一度、振り分ける
このパスワードは、あとからマネージャが自動入力するか。するならランダム文字を使い、長さは初期値の16か、それ以上にする。画面を見ながら手で打つ——来客の Wi-Fi、共有プリンタ、年に数回しか開かないルーター——ならパスフレーズに切り替え、単語数は8語以上へ上げる。読みやすいからといって、4語で止めない。
先に、マネージャへ預けられるか
NIST SP 800-63B-4(2025年7月31日に確定)は、パスワードの長さと「人がどう入力するか」を分けて書いている。単要素として使うとき、検証側は少なくとも15文字を要求しなければならない。多要素の一つとして使うときでも、最短は8文字を下回ってはならない。検証側はパスワードマネージャと自動入力を認め、自動入力の接口が無いときは貼り付けも認めるべきだ。文書は、マネージャ——とくに生成機能付き——があると、利用者が強い秘密を選ぶ確率が上がると明記している。
同じ改訂は、今もサイト方針に残っている二つの規則を捨てている。検証側は、大文字・小文字・数字・記号を混ぜよといった綴り規則を課してはならない。漏えいの証拠が無い限り、定期的な変更を求めてはならない。生成方式を選ぶ側への含意は単純だ。貼り付けと自動入力ができるなら、読みやすさのためにエントロピーを捨てる理由は無い。手入力が要るときだけ単語で打ち間違いを減らし、単語を足してエントロピーを戻す。
MyPassGen のランダム文字は6–128文字、初期値は16で、単要素15文字と同じ桁に揃えている。8文字未満は安全性が低いと警告する。これは生成器自身の範囲であり、「6文字で NIST を満たす」という意味ではない。サイトが8文字までしか受けないなら、その上限いっぱいに取り、多要素を付け、8文字のランダム列を16文字と同一視しない。
二つの生成モデル
ランダム文字とパスフレーズは、同じパスワードの見た目違いではない。数え方が違う。ランダム文字は文字プールから1文字ずつ取る。大文字・小文字・数字・記号を全部オンにすれば、プールの大きさはその合計だ。パスフレーズは固定の単語リストから語を取り、区切りでつなぐ。攻撃者が「どの表を使い、何語取ったか」を知っていれば、探索空間は「リストの大きさの単語数乗」であり、「文がどれだけ長く見えるか」ではない。
ランダム文字:桁ごとに足す
一様ランダムなら、エントロピーはおよそ 長さ × log2(プールの大きさ) だ。MyPassGen が初期状態で四種類をオンにすると、大文字26、小文字26、数字10、記号 !@#$%^&*()-_=+[]{} が18、合計80。16 × log2(80) は約101ビット。英数字だけ(62)なら、16文字で約95ビット。長さを8に落とし、プールは80のままだと、約51ビットしか残らない。「短くて複雑」に見えても、桁が上がらない理由がここにある。
パスフレーズ:語ごとに足す
一様ランダムなら、エントロピーはおよそ 単語数 × log2(リストの大きさ) だ。Arnold Reinhold の Diceware(日本語ではダイスウェアとして知られる)と、電子フロンティア財団(EFF)が2016年に出した長い単語リストは、どちらも7,776語。六面体サイコロ5個の組み合わせ 65 に等しい。1語あたり約12.9ビット。EFF は6語を勧めており、約77.5ビットになる。漫画のよくある4語は1語11ビットで約44ビット——こちらは「日常英語」のより大きい表であり、100語の短い表ではない。
取り出しには、暗号用途に耐える乱数が要る。Crypto.getRandomValues は、MDN が暗号学的に安全な乱数を取る API と定義している。同じ文書は Math.random() を、暗号用途には使えないと書き、セキュリティ関連は Web Crypto へ回せと明記している。Math.random() で組んだ「ランダムパスワード」や「ランダムな単語」は、上の式の満額を自称できない。
エントロピーは単語リストから数える
同じ「4単語」でも、分母が変われば結果は倍近くずれる。log2(100) は約6.64なので、100語の表で4語は約27ビット。log2(7776) は約12.92なので、7776語の表で4語は約52ビット。漫画は1語11ビットで、4語は約44ビット。単語数だけ書いてリストの大きさを隠すのが、パスフレーズを強く見せるいちばん多いやり方だ。
数字や記号を一つ足しても、足せる選択は限られる。数字10個で約3.3ビット、短い記号集合で約3ビット。MyPassGen のパスフレーズで数字や記号の挿入をオンにすると、画面上の見積もりはそれぞれ約6ビット足す。これはやや甘い内部の物差しであり、「! を一つ足せばダイスウェア6語に近づく」という意味ではない。各語の先頭を大文字にする計算は、1語あたり約0.5ビットで、微調整に過ぎない。100語のパスフレーズを「強い」帯(内部のしきい値はおよそ60ビット)へ上げるには、単語数を8–10へ増やす。4語の後ろに 1! を付けるだけでは足りない。
自分で単語を選ぶのは、さらに弱い。歌詞、映画の台詞、職場のプロジェクト名は、攻撃者のフレーズ表にすでに載っている。「リストの大きさの4乗」では数えられない。パスフレーズが式どおりになる条件は、既知のリストから一様ランダムに取ることだ。覚えやすい一文を自分で作ることではない。
対照表:100語、7776語、ランダム列
下の表は、同じ式で揃えている。100語は MyPassGen パスフレーズの内蔵表。7,776語は Diceware / EFF の長い表。ランダム列は80文字のプール。右側の帯は生成器と同じ物差しだ。およそ40ビット未満を弱、60未満を中、80未満を強、それ以上を非常に強いとする。自分で読むための定規であり、特定の GPU への約束ではない。
| やり方 | おおよそのエントロピー | 内部の帯 |
|---|---|---|
| 100語 × 4単語 | 約 27 ビット | 弱 |
| 100語 × 6単語 | 約 40 ビット | 中(線を越えた直後) |
| 100語 × 8単語 | 約 53 ビット | 中 |
| 100語 × 10単語 | 約 66 ビット | 強 |
| Diceware 7,776語 × 4単語 | 約 52 ビット | 中 |
| Diceware 7,776語 × 6単語 | 約 77.5 ビット | 強(EFF が勧める桁) |
| ランダム 8文字(80文字プール) | 約 51 ビット | 中 |
| ランダム 16文字(80文字プール) | 約 101 ビット | 非常に強い |
表から取る事実は二つだ。第一に、初期値16文字のランダム列は、この表でいちばん手間の少ない「非常に強い」行である。覚えなくてよい。マネージャが埋める。第二に、パスフレーズを4語で止めると、桁は短いランダム列か、漫画で書き換えた単語と同じあたりに落ちる。読みやすいから帯が上がるわけではない。手入力が要るなら、100語の表を8–10語まで使うか、ダイスウェア6語の長さを受け入れる。4語を16文字のランダム列と並べて比べない。
NIST の単要素15文字は、長さの下限であり、エントロピーの下限ではない。15文字・80文字プールは約95ビットで、初期値16文字と同じ帯だ。よくある英語4単語は、漫画の44ビットで数えても、その長さが意味するランダム列より下にいる。手入力の場面は「人が打てる」と「桁が落ちない」を同時に満たす必要がある。足すのは単語であり、@ ではない。
よくある勘違い
「4単語なら xkcd のあの一本だ」は、リストと乱数源が漫画か Diceware に揃っているときにしか成り立たない。ハイフンで区切られた英語が見えるだけでは、1語11ビットや12.9ビットは推定できない。
「パスフレーズは必ずランダム文字より弱い」も成り立たない。ダイスウェア6語は約77.5ビットで、すでに「強」に入る。100語の表で10語は約66ビットで、同じく「強」に届く。弱いのは短いリストに、少なすぎる語数を載せた組み合わせであり、「単語を使った」ことそのものではない。
「123 と感嘆符を足せば補強できる」は、人が選んだ短いパスワードにはほぼ効かない。そういう接尾辞は、すでに辞書に入っている。一様ランダムな単語列でも、数字を一つ足すのは数ビットだ。追加の2語の代わりにはならない。
「オンライン生成器がパスフレーズを出せるなら、結果は強い」は、リスト次第だ。7,776語を使うページもあれば、主題語が数百、あるいは数十しかないページもある。開く前に三つ聞く。リストは公開されて何語あるか。乱数源は getRandomValues か。生成結果は業務データとして上がっていないか。スローガンは、この三つに代われない。
「HTTPS があるからパスワードは漏れない」が覆うのは、伝送路上の盗聴だけだ。生成ページが結果を POST したり、解析イベントへ平文を書いたりすれば、HTTPS はその平文を相手のサーバーへ届ける。確かめ方はブラウザで暗号化したとき、平文が送られていないことをその場で確かめるにある。見るのは Network のリクエスト行と本文であり、鍵マークではない。
作ったばかりのパスワードを、原文を上げる「強度サイト」へ貼らない
検査ページには、パスワード原文を POST するものと、ハッシュの先頭だけを送るものがある。端末の照合は、公開された弱いパスワード名簿をダウンロードし、調べる文字列は入力欄に残す。差は端末の漏洩名簿と Have I Been Pwned では、証明できることが違うで書いている。生成も照合も、登録なしで開いて使える。
その場で確かめる
次の手順は、ブランドの約束に頼らない。実在の口座には使わない文字列で試せば足りる。
- 生成ページを開き、パスフレーズを選び、単語数を4にして一度生成する。画面の強度帯とエントロピーを控える。上の表どおりなら、100語 × 4は弱(約27ビット)の近くに落ちる。
- 単語数を8または10へ上げて、もう一度生成する。帯は上がるはずだ。10語なら「強」に近づく。自分で思いついた4語に差し替えて「改善」しない。
- ランダム文字へ切り替え、長さは初期値の16、四種類の文字を全部オンにして生成する。帯は非常に強い(約101ビット)になるはずだ。三本を並べる。パスフレーズ4語が、16文字のランダム列より上に来てはいけない。
- 開発者ツールの Network を開き、「ログを保持」を入れて、もう一度生成する。ドキュメント要求と解析送信に、画面に出ているそのパスワードが載ってはいけない。乱数源は Web Crypto であり、ページスクリプトの
Math.random()ではない——後者は Sources で関数名を検索して確かめられる。 - 公開された弱いパスワード名簿とも照合するなら、捨てる予定の古いパスワードを端末の照合へ貼る。新しく作った主パスワードを、原文を上げるサイトへ送らない。当たらなかったことは、この名簿に無いことだけを示す。「一度も流出していない」とは書けない。
MyPassGen のパスワード生成は、この境界で動く。二つのモードとも、今開いているタブで getRandomValues を使う。ランダム文字は6–128、初期値16、8未満は弱いと警告する。パスフレーズは3–10語、リストは100語。区切り、数字、記号、各語の先頭大文字を足せる。一度に最大100本まで作り、コピーするか TXT に書き出せる。開いてすぐ使える。アカウントもパスワード保管庫も無い。タブを閉じたあと、これらのパスワードはサーバーに残らない。確かめるのは Network であり、スローガンではない。
今日替える一本から選ぶ
今日替える一本について、先にマネージャへ預けられるかを答える。預けられるなら、16文字以上のランダム文字を作り、サイトごとに別の文字列を書き、使い回さない。手入力が要るなら、8–10語のパスフレーズを作る。隣の人へ読むなら一度だけ読む。同じ一本をグループチャットへ「控え」として貼らない。遠隔の同僚へ秘密を一度だけ渡すときはワンタイムを使い、鍵は URL の # の後ろへ置く。平文のコピーをもう一通作らない。
ルーター、ゲスト Wi-Fi、プリンタは、典型的な手入力の場面だ。来客はスマホのキーボードを使い、記号と大小文字の混在は打ち間違いやすい。ここでは長い単語列の方が、8文字の「複雑な」ランダム列より、読み違いと書き写しが少ない。管理画面を自分だけが、しかもマネージャ付きの端末で開くなら、そのログインは16文字のランダムを優先する。
この振り分けが終われば、見出しの問いに答えられる。ランダムかパスフレーズかは、入力の仕方で決める。4単語で足りるかは、単語リストの大きさで決める。100語の表の4語は、重要な口座を担えない。初期値16文字のランダム列は担える。画面の帯は、この表と揃っていなければならない。揃わなければ、「文に見えるから安全」を信じない。
よくある質問
4単語のパスフレーズを、マスターパスワードにしてよいか。
100語の表では、いけない。約27ビットは、やや短いランダム列と同じ桁だ。マスターパスワードやディスク暗号化のパスフレーズのように、めったに替えず、漏れたときの影響が大きい秘密は、マネージャに預ける16文字以上のランダム列にするか、単語数を8–10へ上げ、乱数源が自分で作った一文ではないことを確かめる。
サイトの複雑さチェックを通すため、大小文字と記号を足すべきか。
サイトが今も文字種の混在を強制するなら、数字・記号の挿入や各語の先頭大文字をオンにして、フォームを通す。これは古い綴り規則を満たす作業であり、エントロピーの主因ではない。NIST は、検証側にこうした規則を課さないよう求めている。通ったあとも、見るのは単語数とリストの大きさだ。
ランダムパスワードやパスフレーズの生成に登録は要るか。結果は上がるか。
登録は要らない。生成は、今開いているタブに残るべきだ。原文を上げるサイトへ結果を渡したとき、ログのリスクが始まる。生成のあと Network を開く。リクエスト本文と解析イベントに、そのパスワードが載ってはいけない。控えが要るなら、自分がすでに信頼している場所へコピーするか書き出す。サイト内にパスワード保管庫は無い。
手入力の Wi-Fi パスワードは、ランダム16文字か、単語のパスフレーズか。
誰が打つかで決める。自分だけがマネージャ経由でつなぐなら、ランダム16文字。来客がスマホのキーボードでよく打つなら、8–10語にして、0/O、1/l、記号の連打を避ける。同じ Wi-Fi パスワードを、ルーター管理画面へ使い回さない。