【安全なパスワードの作り方】強力なパスワードを自動生成するコツと管理術

「パスワードを作るたびに，大文字や記号を混ぜろと言われてイライラする...」「そんなに複雑なパスワード，覚えられるわけがない！」そう思ったことはありませんか？

ネットバンキングやSNS，社内システムなど，毎日たくさんのサービスを使う現代において，パスワードの管理は本当にストレスが溜まる問題ですよね．「使い回すのは危険」と分かってはいても，ついつい覚えやすい同じものを使ってしまう気持ち，とてもよく分かります．しかし，ひとつのパスワードが漏洩した場合，同じパスワードを使っている他のサービスも連鎖的に不正アクセスを受けるリスクが高まります．

この記事では，そんな日々のストレスと不安をすっきり解消するために，なぜパスワードにそれほどの強度が求められるのか，そしてどうすれば「覚える労力を最小限に抑えながら，十分なセキュリティ」を作れるのかを分かりやすく解説します．

難しい専門用語や数式も少し登場しますが，大丈夫です！まずは肩の力を抜いて，セキュリティを高める具体的なコツを一緒に見ていきましょう．

§2. パスワード強度の数学的基礎：情報エントロピー

暗号学および情報理論において，生成されたパスワードの予測不可能性（強度）の目安は，シャノンが提唱した「情報エントロピー（Information Entropy）」によって定量化されます．

「情報エントロピー」は，一見難しそうですが，要するに「パスワードの『予測しにくさ（複雑さ）』を表す数値」のことです．

例えるなら，「宝箱の鍵穴の数と，鍵のパターンの組み合わせ」のようなもの．鍵穴の数が多くて，鍵の凹凸のバリエーション（文字セット）が複雑なほど，攻撃者がでたらめな鍵を差し込んで宝箱を開けようとしたときに，偶然開いてしまう確率がぐっと低くなります．

① エントロピーの計算式と前提となる仮定

パスワードの各文字が，選択肢となる文字セット（文字プール）から完全に独立かつ均等な確率（一様分布）でランダムに選択されると仮定した場合，パスワードの情報エントロピー (H) （単位：ビット）は以下の数式で定義されます．

H = L × log2(R)

• パスワード長 (L): パスワードの文字数（長さ）
• 文字セットサイズ (R): 使用される文字セットの文字数（サイズ）

この数式は，パスワードが持つ可能性の総数（探索空間サイズ）を S = R^L としたとき， S = 2^H となるような2進数の桁数（ビット数）を表しています．この独立一様モデルの仮定のもとでは，エントロピーが高いほど，攻撃者がパスワードを特定するために必要な推測回数の期待値が多くなります．

② 文字セットのサイズ (R) と1文字あたりのエントロピー

使用される文字セット (R) の構成によって，1文字あたりに追加されるエントロピー（ log2(R) ）は以下のように推移します．

• 数字のみ（0-9）:

R = 10 ➔ log2(10) ≒ 3.32 bits/char

• 英小文字のみ（a-z）:

R = 26 ➔ log2(26) ≒ 4.70 bits/char

• 英大文字小文字（a-z, A-Z）:

R = 52 ➔ log2(52) ≒ 5.70 bits/char

• 英大小文字＋数字（a-z, A-Z, 0-9）:

R = 62 ➔ log2(62) ≒ 5.95 bits/char

• 当生成器の初期設定（類似文字除外）:

大文字24種，小文字24種，数字8種，記号28種

R = 84 ➔ log2(84) ≒ 6.39 bits/char

• 当生成器の全文字（類似文字除外なし）:

大文字26種，小文字26種，数字10種，記号29種

R = 91 ➔ log2(91) ≒ 6.51 bits/char

• 仮想的なASCII印字可能文字全体:

R = 94 ➔ log2(94) ≒ 6.55 bits/char

③ 具体的なエントロピー算出例

• 例A: 8文字の英大小文字＋数字のパスワード

H = 8 × log2(62) ≒ 8 × 5.95 = 47.6 bits

• 例B: 16文字の当生成器全文字 (R=91) パスワード

H = 16 × log2(91) ≒ 104.1 bits

• 例C: 12文字の仮想的なASCIIフルセット (R=94) パスワード

H = 12 × log2(94) ≒ 78.7 bits

これらの計算はあくまで完全にランダムに生成された場合の理論値であり，人間が考えたパスワードには当てはまりません．

§3. 総当たり（ブルートフォース）攻撃と解読所要時間の計算モデル

ハッカーがパスワードを破る代表的な手法に「総当たり（ブルートフォース）攻撃」があります．これは，「考えられるすべての組み合わせを，当たるまでひたすら試し続ける」という力技です．現代の攻撃者は手動ではなく，プログラムを用いて自動的かつ高速に試行を行います．

攻撃者がパスワードを突破するために必要な平均時間は，探索空間のサイズ (S) と攻撃者の試行速度 (v) に依存します．

① 計算モデル

独立一様分布から1つの正解が選ばれ，攻撃者が重複なく1候補ずつ順番に試行し，試行速度が常に一定であるという仮定のもとでは，全探索に必要な最大時間 T_max および平均時間 T_avg は以下の通り定義されます．

T_max = S / v = (R^L) / v
T_avg = (S + 1) / (2v) ≈ (R^L) / (2v)

② 攻撃ベクトルによる速度 (v) の仮定

ハッカーの攻撃環境には，大きく分けて以下の2つのシナリオが想定されます．パスワードを保護するシステム側で意図的に計算コスト（時間）をかけるストレッチングという手法が採用されているか否かで，状況は大きく異なります．

• オンライン攻撃（Web API経由）:

対象サービスのログイン画面やAPIに対して通信を行い，実際にログインを試みる手法．ネットワークの遅延や，サービス側のロックアウト機能（一定回数間違えると一時凍結される仕組み，フェイルツーバンなど）があるため，試行速度は大幅に制限されます．

ここでは均等モデル比較のための仮定として v = 10 回/秒 とします．

• オフライン攻撃（漏洩ハッシュの解析）:

サービスから流出したパスワードのハッシュ値（暗号化されたようなデータ）を，攻撃者が自身の高性能な手元環境（多数のGPUを並列稼働させる専用リグなど）で直接解析する手法．通信が発生しないため，非常に高速な試行が可能です．ここでは均等モデル比較用の仮定として v = 10^11 回/秒 （1,000億回/秒）とします．実際のシステムでArgon2やbcryptなどの強力なハッシュ関数が正しく適用されている場合は，計算処理が重くなるため試行速度は大幅に低下しますが，過去の古いシステムから漏洩したMD5やSHA-1などの単純なハッシュであれば，極めて高速に解析される危険があります．

③ エントロピー・文字数・平均探索時間の比較表

以下の表は，前述の計算モデル（独立一様・一候補のみ・試行速度一定）に基づき，各条件での平均時間 T_avg を計算したものです．オンラインは v=10/s，オフラインは v=10^11/s の仮定値を用いています（1年 = 31,557,600秒で計算）．

【重要な注意点】

これらの時間は，あくまで均等独立モデルを比較するための計算上の数値に過ぎません．実際のパスワードの安全性を絶対に保証するものではなく，実際の解読時間を予測するものでもありません． 実際の被害は，フィッシング詐欺による直接の盗用，別のサービスからのパスワードの使い回しによる漏洩，マルウェアによる端末からの抜き取りなどによって発生することが多く，パスワードの桁数を増やすだけではこれらの脅威は防げません．攻撃者は総当たりを行う前に，すでに漏洩しているパスワードリストを用いた効率的な攻撃を優先するため，理論値の膨大な時間は「同じパスワードを使い回していない」かつ「辞書に載っていない完全にランダムな文字列である」という前提が成立して初めて意味を持ちます．

§4. ハッカーによる主要な攻撃手法と脅威分析

攻撃者は，単純な総当たりだけでなく，人間の行動パターンや計算の最適化に基づいた様々な手法を巧妙に組み合わせます．ランダムなパスワード生成器を用いるのは，こうした人間の癖を狙った攻撃を回避するためでもあります．

① 辞書攻撃（Dictionary Attack）

人間がパスワードを記憶しやすくするために使用する実在の単語，人名，地名，映画のタイトルなどのリストをベースに試行を行う手法です．さらに，単語の頭文字を大文字にする，末尾に「123」や西暦（例：「2026」）を付加するといった，人間が選択しがちなパターンをプログラム的に予測して適用する「ハイブリッド辞書攻撃」も広く用いられています．人間が考えたパスワードはエントロピーの計算値よりもはるかに早く突破される危険があります．

② リスト型アカウントハック（Credential Stuffing）

ある特定のWebサイトから漏洩したIDとパスワードのリストを利用し，他の多数の主要サービスに対して自動でログイン試行を行う手法です．ユーザーがパスワードを「使い回し」ている場合，単一サイトのセキュリティ破綻が，無関係な全アカウントの侵害へ直結するドミノ倒し的な被害を生みます．

③ キーの配列パターンを狙う攻撃（Keyboard Walk）

キーボード上の並びをそのまま入力した文字列（例：qwerty，asdfgh，zxcvbnなど）や，文字を斜めにタイピングするパターンなどを検出する攻撃．これらは通常の辞書データと同等の優先度で攻撃者の解析リストに登録されています．

§5. NIST SP 800-63Bガイドラインに見る現代のパスワード標準

米国国立標準技術研究所（NIST）が策定したデジタルアイデンティティ指針「NIST SP 800-63B」では，従来の不合理なパスワード運用ルールが見直され，より実践的なガイドラインが提示されています．なお，このガイドラインは米国NISTの方針であり，世界全体の一律規則ではありませんが，現代のセキュリティの重要な参考基準となっています．また，これはサービスを提供する「検証者側（システム側）」がどのような基準でパスワードを受け入れるべきかを示したものであり，パスワード生成器の機能がこれに完全準拠しているかを認定するものではありません．

① 定期変更ルールの非推奨化と侵害時の対応

「定期的にパスワードを変えてください」というルールは，NISTの方針では推奨されていません．頻繁な変更を強制されたユーザーは，既存のパスワードの末尾の数字を「1」増やすだけ（例：Password1 → Password2）といった，予測が極めて容易な変更パターンを選択しがちです．これによりかえって強度が低下し，攻撃者に推測されやすくなるため，NISTは「システムに対する侵害の証拠がない限り，定期的な変更を義務付けるべきではない」としています．

② 複雑性の強制よりも長さの許容

「大文字・小文字・数字・記号を必ずすべて混ぜる」という細かな文字種の強制ルールも，NIST方針では必須要件とはされていません．記号の混在を強制すると，ユーザーは記憶しやすいように記号を末尾に置く（例：!, ?）といった行動を取りやすく，攻撃パターンとして固定化されてしまいます．

NIST SP 800-63B-4では，文字種の多さだけで長さを代替することはできないとし，検証者側は少なくとも最大64文字までの長さを許容することを推奨しています．単一要素認証の場合は最低15文字以上，多要素認証（MFA）の一部として用いる場合は最低8文字以上と定めています．長いパスフレーズも許容されるべきだという方針です．

③ 漏洩済みパスワードの拒否と多層的な防御

システム側は，新規パスワードの設定時に，過去にデータ侵害で流出している既知のパスワードリスト（いわゆるブラックリスト）と照合し，一致した場合は登録を拒否することが求められます．さらに，パスワードの強度だけでシステムを守るのではなく，サービス側が提供する多要素認証（MFA）やパスキーへの対応，あるいは端末側での生体認証を用いた保護などを活用し，万が一パスワードが突破された場合でも被害を防ぐ多層的な防御策が重要となります．

§6. 暗号学的に安全なランダム文字列の生成メカニズム（CSPRNG）

パスワード自動生成ツールを使用する際，ベースとなる「乱数発生器（RNG）」の品質が極めて重要になります．質の低い乱数で作られたパスワードは，ランダムに見えても裏側に法則性が隠れている可能性があるためです．

① PRNG（擬似乱数生成器）の偏りと脆弱性

プログラミング言語の標準機能として提供されている乱数関数（例：JavaScriptの Math.random() やC言語の rand() など）の多くは，一般的な「擬似乱数生成器（PRNG）」を採用しています．これらはゲームやシミュレーションでの計算の高速性を重視して設計されているため，初期値（シード）さえ分かれば出力される結果がすべて決まってしまうという性質があります．内部状態の周期性や法則性が推測されると，次に出る値が完全に予測可能になってしまう可能性があり，重大な情報の保護を目的とするセキュリティ用途には適していません．

② CSPRNG（暗号論的擬似乱数生成器）による解決

セキュリティ用途には，OS等を通じて提供される暗号論的擬似乱数生成器（CSPRNG）を使用します．現代の主要なWebブラウザは，この機能を利用するための Web Crypto API（crypto.getRandomValues()） を標準で実装しています．このAPIは，OSやブラウザの実装に依存する多様なエントロピー源（予測困難なノイズ）を元にして乱数を生成するため，一般的なPRNGに比べて予測されるリスクを大幅に低減しています．

ZeroToolsのパスワード生成器では，このWeb Crypto APIを用いて生成処理を行っています．Uint32Array（32ビット符号なし整数配列）を用いて高品質な乱数を取得し，古いブラウザなどで安全な乱数生成が利用できない環境では，危険な Math.random() での代替処理（フォールバック）を一切行わずにエラーとして処理を完全に停止する安全設計を採用しています．

ただし，これは量子力学的な現象を用いたような「真の物理乱数（TRNG）」であることや，未来永劫どのような技術革新が起きても完全に予測不能であることを保証するものではありません．あくまで現在の暗号学的な標準において安全とみなされている仕組みを利用しているという意味です．

§7. ZeroToolsジェネレーターの技術設計とセキュリティへの配慮

当サイトの Web Cryptoパスワード生成器 は，クライアントサイド（ブラウザ内）での処理を中心とした以下のアーキテクチャとセキュリティ配慮に基づいて実装されています．

① 処理のフローと文字の選択

当ツールでは初期表示として16文字のパスワードを3件生成します．利用者が画面上でパスワード長（4文字〜最大64文字まで指定可能）や同時生成数（1/3/5/10件），使用する文字種（大文字・小文字・数字・記号），および類似文字の除外設定を指定し，「生成」または「パスワードを再生成」ボタンを押すことで処理が開始されます．ブラウザ上でJavaScriptが実行され，Web Crypto APIから暗号論的に安全なバイト列を取得します．その後，取得した乱数を元に，許可された文字プールの中から1文字ずつ選択し，最終的な文字列を構築して画面に表示します．

なお，選択した文字種（例えば「記号」）が，生成されたすべてのパスワードに必ず1文字以上含まれるという保証の仕組みや，特定の記号だけを任意に選んで組み合わせる機能，複数の単語を繋ぎ合わせたパスフレーズ化する機能，過去の生成履歴を保存する機能はありません．

② 剰余バイアス（Modulo Bias）の排除

乱数を特定の文字セットのサイズ（例えば，類似文字除外時の84文字やフルセットの91文字）に割り当てる際，単純な割り算の余り（剰余演算）を使うと，特定の文字が他の文字よりもわずかに選ばれやすくなる「剰余バイアス」が発生する問題があります．たとえば，0から255までの乱数を91で割った余りを求めると，余りが0から73になる確率は，74から90になる確率よりも高くなってしまいます．

ZeroToolsのジェネレーターでは，この偏りを防ぐために Uint32Array （約42億の範囲）を用いた上で，「棄却サンプリング（Rejection Sampling）」という手法を実装しています．文字プールのサイズできれいに割り切れる最大値（上限）をあらかじめ計算しておき，その上限以上の乱数値が出た場合はその値を棄却し，条件を満たすまで再度新しい乱数を取得し直すという処理です．これにより，選ばれる確率の偏りを数学的に回避しています．

③ ブラウザ内での実行と通信に関する注意

パスワードの生成処理自体は，利用者の端末のブラウザ内でJavaScriptとして実行され完結します．生成した文字列のデータそのものを外部のWebサーバーやデータベースへ送信したり，永続的に保存したりする独自の処理は実装していません．

しかし，これは「完全なオフライン環境である」や「通信が一切ゼロである」という意味ではありません．このツールページを表示するためのHTML/CSS/JSファイルのダウンロード通信や，サイトのアクセス解析などの一般的な通信はバックグラウンドで発生します．また，生成された結果をクリップボードへのコピー機能を使用してコピーした場合，端末のOSやバックグラウンドで動いているクリップボード履歴拡張機能などを通じて情報が記録・漏洩する可能性はゼロではありません．生成されたパスワードを表示している間に，画面共有ツールで他人に画面を見せたり，チャットツールに誤って貼り付けたりしないよう，利用環境には十分な注意が必要です．

§8. パスワード管理の運用とトラブルシューティング

強固で推測されにくいパスワードを生成できても，それを正しく管理し，安全に入力できなければ意味がありません．実際の運用時の注意点と，よくあるトラブルへの対処法を具体的に確認しましょう．

① パスワードの管理と保管

生成した長く複雑なパスワード（例えば16文字以上のランダム文字列）を，複数サイト分すべて頭の中だけで記憶することは極めて困難であり，大きな負担となります．使い回しを避けるためには，利用先や所属組織が認める適切なパスワードマネージャーや，OS・ブラウザに搭載されている管理機能などの利用が考えられます．

パスワードを端末やアプリに保存して運用する場合は，端末自体の画面ロック（強固なパスコードや指紋・顔などの生体認証）を徹底し，第三者が物理的に端末を操作しても容易にアクセスできない状態を維持してください．生成結果をデスクトップのメモ帳などの暗号化されていない平文ファイルに無防備に保存したり，付箋に書いてモニターに貼ったりすることは避けてください．

② 運用上のよくある問題と解決策

Q1. サービス側で「使用できない文字が含まれている」とエラーになる

• お悩み: 生成したパスワードを入力すると，登録時に「不正な文字が含まれています」とエラーになってしまう．
• 解決策: 利用先のシステムによっては，特定の記号が仕様上の制約で使用できない場合があります．エラーになった場合は，利用先のサービスの必須規則や使用可能文字のリストを確認してください．当ツールの「記号」オプションは，対象の文字プールに記号を含めるものであり，生成結果に必ず記号が含まれることを保証するものではありませんが，エラーとなる文字が含まれてしまった場合は，問題のない文字種のみになるようオプションを調整して再生成してください．記号を使わない分，長さを増やすことで強度を補うことができます．

Q2. 文字数の上限（例：12文字まで）や下限が設定されている

• お悩み: 生成器は最大64文字まで作れるが，登録先のサイトが「12文字以内」など短い上限を設けている．
• 解決策: 当ツールの実装上の最大文字長（64文字）は，各Webサービスが許容する制限とは全く異なります．利用先のシステムが許容する最大文字数に合わせて生成器の文字数を数値入力欄で調整してください．可能であれば，文字数をシステムの上限（この場合は12文字）までいっぱいに設定し，大文字・小文字・数字・記号をすべて含めることで可能な限りエントロピーを高めてください．さらに，二要素認証（MFA）が提供されている場合は必ず併用してアカウント全体のセキュリティを高めてください．

Q3. 自動生成したパスワードをコピー＆ペーストできない場合

• お悩み: アカウント登録画面やパスワード変更画面で，確認用入力欄への貼り付け（ペースト）が禁止されている．
• 解決策: ブラウザの開発者ツールを使って入力欄の readonly 属性や onpaste イベントを無理やり書き換えるといった迂回行為は，予期せぬ動作を引き起こす可能性があるため推奨しません．利用先の正規の手順に従うか，ブラウザやパスワードマネージャーの「自動入力機能」を利用して入力させてください．どうしても手入力が必要な場合は，生成器の設定で「類似文字（l/1/I, o/0/O 等）を除外」のトグルをオンにして生成し，見間違いによる入力ミスを防ぎながら慎重に一文字ずつ入力・検証を行ってください．

生成した新しいパスワードを入力した後は，一旦ログアウトし，保存した新しいパスワードで確実にログインできるかを必ず確認してください．正しく保存され，機能することが確認できてから実際の運用を開始することが重要です．