強いパスワードの作り方と「生成ツール」の正しい使い方

なぜ「強いパスワード」が必要なのか

「自分みたいな一般人は狙われないでしょ」というのは、たぶんパスワードに関して一番危険な勘違いです。現代の攻撃者は「あなた」を狙っていません。彼らは「誰でもいいから開くアカウント」を探していて、そのために 何億件もの漏洩パスワードリスト を自動化ツールで無数のサービスに投げつけます。漏洩データの多くは Have I Been Pwned（HIBP）のような無料サービスで誰でも確認できますが、本物の攻撃者はもっと新鮮で大量のダンプを ダークウェブの闇市場 で入手しています。価格は驚くほど安く、数千万件のメール＋パスワードの組が数千円で売買されているのが現実です。

2024 年には「RockYou2024」と呼ばれる 98 億件規模のパスワードリストが公開され、話題になりました。過去の漏洩を総合したこのリストには、ほぼすべての「人間が思いつきそうな」パスワードが含まれています。つまり、あなたが「これなら大丈夫だろう」と思って考えたパスワードも、99% の確率ですでにリストのどこかに存在します。攻撃者はそれを知っているから、新しい漏洩があるたびに単純なリスト攻撃を流し込むだけで、大量のアカウントを開いてしまう。

もう 1 つ覚えておきたいのは、狙われる理由はあなた個人の情報ではなくアカウント自体だということ。開いたアカウントはスパム送信の踏み台、仮想通貨の換金、フィッシングの中継、ポイント不正利用など、様々な形で収益化されます。だから「私のアカウントには大した情報は入ってない」は防御にならない。攻撃者にとって価値があるのは、あなたが気づかないうちに使える「正当に認証されたログインセッション」そのものなのです。

パスワード強度はエントロピーで測る

「このパスワードは強い」「弱い」という感覚を、数学的に測る物差しが エントロピー です。単位は ビット（bit）。式はシンプルで、使用できる文字の種類数（charset）を底とし、桁数（length）を指数とした総組合わせ数を 2 の対数で表現します。

エントロピー(bit) = log2(charset^length)
                  = length × log2(charset)

具体例を見てみましょう。英小文字 26 種だけで 8 桁のパスワードを作った場合、エントロピーは 8 × log2(26) ≒ 8 × 4.7 = 37.6 bit。一方で、英大小 + 数字 + 記号（合計 94 種）で 12 桁なら 12 × log2(94) ≒ 12 × 6.55 = 78.6 bit になります。この「37.6」と「78.6」の差が、体感では見えない強度差の正体です。

目安として、40 ビット以下は 論外（家庭用 GPU で数分〜数時間）、60 ビットでぎりぎり日常利用に耐え、80 ビット以上あれば現在の技術では現実的に総当たり不能、100 ビット以上なら数十年オーダーでも安全、と考えておけばおおむね間違いありません。ここで重要なのは、エントロピーは 「人間が作った」パスワードには当てはまらない ということ。辞書にある単語や誕生日を含むパスワードは、理論上の組合わせ数よりはるかに少ない候補で破られます。エントロピーが意味を持つのは、乱数生成された パスワードの場合だけです。

だからこそ、自分で頭をひねって「強いパスワード」を考えるのは時間の無駄です。コンピュータに乱数で作らせて、長さだけ自分で決める。これがいちばん効率的な強度の確保方法になります。

桁数 vs 文字種 — どちらが効く？

「英大小 + 数字 + 記号を混ぜろ」と言われ続けてきたせいで、多くの人は「文字種を増やす」ことが強さの本質だと思い込んでいます。でも実際の数学は違います。結論から言うと、桁数を 1 増やす方が、文字種を倍にするより強くなるケースがほとんどです。

比較してみましょう。8 桁で英数字記号フル（94 種）のパスワードは 8 × log2(94) ≒ 52.4 bit。一方、16 桁で英小文字のみ（26 種）は 16 × log2(26) ≒ 75.2 bit。記号だらけの 8 桁より、英小文字だけの 16 桁の方が 圧倒的に強い のです。人間にとって記憶しやすいのも当然、後者の方。これは単純な対数の性質によるもので、桁数は指数として効き、文字種は底として効くから、長さを伸ばす方が効率がいい。

この事実を世界で一番わかりやすく示したのが、ウェブコミック XKCD の 936 番「Password Strength」です。Tr0ub4dor&3 みたいに記号と数字を無理やり混ぜた 11 文字のパスワードと、correct horse battery staple という単純な 4 単語のパスフレーズを比較し、後者の方が強くて覚えやすいことを示しました。この図はセキュリティ業界の定番引用になっており、現代の NIST ガイドラインもこの考え方を採用しています。

もちろん「桁数さえあれば何でもいい」わけではありません。全桁が同じ文字や辞書単語だと攻撃者は最初にそこを試すので、長さ + 乱数性の両方が必要です。ただ、ランダム性が確保されている前提なら、長くする方が覚えやすくて強いという非常にありがたい結論になります。

パスフレーズの考え方

「16 桁の乱数なんて覚えられない」という正直な悩みに対する答えが、パスフレーズです。単語をいくつかつなげて 1 つのパスワードとして使う方式で、覚えやすさと強度を両立できます。よく使われるのは Diceware 方式。サイコロを 5 個振って出た数字で単語リスト（7776 語）から 1 語選ぶというローテク手法で、6 単語選べば log2(7776^6) ≒ 77.5 bit の強度が得られます。

# Diceware の例（日本語対訳は覚えやすさのため参考）
correct horse battery staple mountain river
↑ 4 単語で約 51.7 bit、6 単語で約 77.5 bit

ここでの重要ポイントは、単語は必ず乱数で選ぶということ。自分の好きな単語を並べると「自分の好きなもの」を知っている攻撃者には筒抜けですし、英単語の頻出語で構成された文章は OSINT（公開情報からの推測）で予測されやすくなります。Diceware はこの「自分で選ぶ」誘惑を物理的に排除するための装置だと考えてください。

日本語パスフレーズの是非もよく聞かれます。結論としては「使えるが罠がある」。日本語単語（ひらがな・カタカナ）は英単語に比べて辞書数が少なく、変換ミスで入力できない場面もあります。ローマ字に変換して使う手もありますが、その場合は攻撃者の日本語辞書攻撃対象になりやすい。国際的なサービスで使う前提なら、英単語の Diceware の方が実用的です。

また、「文章っぽいフレーズ」にしたくなる気持ちもわかりますが、文法的に自然な文章は マルコフ連鎖攻撃（自然言語の統計的性質を利用した攻撃）で予測されやすくなります。Diceware の出力は単語の並びが不自然なほど強い、というのを忘れないでください。

よくあるダメなパスワード

毎年公開される「最悪のパスワード Top 100」リストの顔ぶれは、10 年以上ほとんど変わっていません。123456、password、qwerty、111111、abc123、letmein、admin……これらは今でもリスト上位を占めています。攻撃者はまずこのリストを試すため、同じパスワードを使っていれば秒で破られます。2023 年の調査では、漏洩アカウントの約 30% が Top 100 リストに含まれるパスワードだったと報告されています。

もう少し「工夫」したつもりのパターンも危険です。具体的には以下のようなもの。

• 個人情報由来：誕生日、名前、ペット名、出身地、電話番号。SNS から集められる情報は攻撃者にとっては公開辞書です。
• 語尾の 1 や !：password1、password! は、そのままの password と同程度の強度しかありません。全攻撃ツールが自動でこの変換を試します。
• Leet 変換：p@ssw0rd のような a→@、o→0 などの置換。これも全部辞書攻撃のマングリングルールに入っています。
• キーボード配列：qwerty、asdfgh、1qaz2wsx。見た目はランダムですが攻撃辞書の常連です。
• 有名な引用・歌詞：映画のセリフ、曲の歌詞、書籍の一節。公開コーパスが辞書化されています。
• 連番の派生：Password1 → Password2 → Password3。定期変更の副作用で生まれる典型パターン。

これらに共通するのは「人間が覚えやすい = 統計的に偏りがある = 攻撃者が狙いやすい」という構造です。言い換えると、「自分で考えたパスワード」は本質的に弱いということ。強いパスワードに必要なのは創造性ではなく、予測不能性 = 乱数だけなんですね。

パスワードマネージャが最強の理由

ここまで読んで「じゃあどうしろと？」と思った方、答えは明確で パスワードマネージャを使う の一択です。マネージャは各サービスごとに別々のランダムパスワードを自動生成・保存してくれて、ログイン時に自動入力する仕組み。あなたが覚えるのは マスターパスワード 1 本だけ。この 1 本を強くすれば、芋づる式に数百個のアカウントが守られる、という非常にコスパのいい構造になっています。

代表的な選択肢は以下の通り。

• Bitwarden：オープンソース、無料プランでも機能充実、クラウド・セルフホスト両対応。個人利用で最もバランスがいい選択肢。
• 1Password：有料だが UI/UX が洗練されていて家族・チーム運用が楽。シークレットキー方式でマスターパスワード単独では復号不能という追加の安全機構あり。
• KeePassXC：完全ローカル、オフライン、オープンソース。同期は自分で用意する必要があるが、クラウドを一切信用したくない人向け。
• Apple パスワード（iCloud キーチェーン）：Apple 純正。エコシステム内で完結するなら十分実用的。パスキー対応済み。

「ブラウザ保存はダメ？」という質問もよく聞きます。Chrome・Safari・Firefox の内蔵パスワードマネージャは、昔と比べるとかなり堅くなりました。暗号化も OS 認証との統合もあり、「ないよりは圧倒的にマシ」レベルには達しています。ただしブラウザ横断の同期が難しい、エクスポート機能が限定的、2FA コードや安全メモのような拡張機能がないなど、専用マネージャに比べると機能は見劣りします。とりあえず何も使っていない人は今日からブラウザ保存に切り替えるだけでも十分効果があり、その後に専用ツールへ移行するのがおすすめです。

マスターパスワードには本記事のパスフレーズ方式を適用してください。Diceware 6 単語 + α、もしくは 20 文字以上の乱数パスワードを、物理的な紙にバックアップして金庫に保管する。これで「マスターパスワードを忘れた」という最悪のケースにも備えられます。

使い回し禁止 — クレデンシャルスタッフィング

「強いパスワードを 1 つ作って、それを全サービスで使い回してる」という人、多いです。気持ちはわかりますが、これは 強度とは無関係に壊滅的に危険です。理由は クレデンシャルスタッフィング（credential stuffing）と呼ばれる攻撃手法が存在するから。

仕組みはこうです。ある 1 つのサービスが漏洩し、メールアドレスとパスワードの組が流出します。攻撃者はその組を大量にまとめ、自動化ツールで 他の数百・数千のサービスに同じ組合わせを試します。銀行、SNS、EC サイト、メール、クラウドストレージ……使い回している人は、漏洩した 1 つのサービスを起点に全アカウントが芋づる式で奪われます。攻撃者にとっては、漏洩リストを入手すれば「同じパスワードを使っている別サービス」が自動的にボーナスで手に入る、非常にコスパのいい攻撃です。

歴史的に有名なのが 2012 年の LinkedIn 漏洩事件。約 6500 万件のメール + ハッシュ化パスワードが流出しました。当時の LinkedIn のパスワードハッシュは弱い SHA-1（ソルトなし）だったため、大部分が短期間で平文復元され、その後数年にわたって他サービスへのクレデンシャルスタッフィング攻撃に使われ続けました。Dropbox の大量漏洩（2016 年公表）も、元をたどれば LinkedIn 由来のパスワードを使いまわしていた Dropbox 従業員のアカウントが起点だったと報道されています。1 箇所の漏洩が全社を倒す、というのは誇張ではなく実際に起きた話です。

対策は極めてシンプルで、全サービスで別々のパスワードを使う。それを人力でやるのは無理なので、パスワードマネージャに任せる。これだけです。Have I Been Pwned などの漏洩通知サービスに自分のメールアドレスを登録しておくと、新しい漏洩が見つかったときに通知が来るので、すぐにそのサービスのパスワードだけを変更すれば被害を最小化できます。

パスワードより 2FA（TOTP・パスキー）

強いパスワードを使い、使い回しもせず、マネージャで管理する。ここまでやっても「パスワードだけに頼る」のはまだ危険です。フィッシングで偽サイトに入力してしまえば一瞬で渡ってしまいますし、キーロガーやブラウザ拡張のマルウェアも存在します。そこで 2 段階認証（2FA）、特に TOTP と パスキー / FIDO2 の出番です。

TOTP（時間ベースワンタイムパスワード）

TOTP は 30 秒ごとに変わる 6 桁のコードを、専用アプリ（Google Authenticator、Authy、1Password、Bitwarden など）で生成する仕組みです。サーバーとアプリが同じシード（秘密鍵）と現在時刻を元に同じコードを計算するため、ネットワーク通信なしで検証できます。セットアップ時に QR コードを読み取りますが、その中身は次のような URI です。

otpauth://totp/Example:alice@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Example&algorithm=SHA1&digits=6&period=30

この URI を認証アプリが解釈してシードを保存し、以降は時刻から自動的にコードを算出します。TOTP は実装がシンプルで、対応サービスも多く、ハードウェアキーなしで利用できる手軽さが魅力です。

SMS は避けるべき理由

パスキー / FIDO2 / WebAuthn

2024 年以降に急速に普及している次世代の認証方式が パスキー（正式には FIDO2 / WebAuthn ベースの同期型クレデンシャル）です。公開鍵暗号を使い、サーバーには公開鍵しか保存されないため、サーバーが漏洩しても認証情報は盗まれません。さらにサイトのドメインと紐付けて動作するため、フィッシングサイトに誘導されても ブラウザが自動的にブロックします。これが 2FA コードの手打ちにはない決定的な強みです。Apple・Google・Microsoft が同期基盤を提供しており、iCloud キーチェーンや Google パスワードで複数デバイスに安全に同期されます。

より堅牢な選択肢として YubiKey のようなハードウェアセキュリティキーもあります。物理的に持っていなければ認証できないため、リモート攻撃に対しては事実上無敵。管理者アカウントや暗号通貨ウォレットなど、絶対に奪われたくないアカウントには最低 2 本（紛失時の予備含む）を用意しておくのがおすすめです。

バックアップコードの保管

TOTP やパスキーを設定する際、多くのサービスは バックアップコード（10 個程度のワンタイムコード）を提示します。これはデバイスを失ったときの最後の手段なので、必ず保存してください。推奨は「紙に印刷して物理的に金庫・耐火ボックスへ」または「パスワードマネージャの別項目として暗号化保存」。Google Docs やメモアプリの平文保存は NG です。

ベンリーのパスワード生成ツールの使い方

ここまで読んで「ランダムなパスワードをどう作るか」が気になっているはずです。ベンリーの パスワード生成ツール は、この目的専用に作られています。特徴を簡潔にまとめると次の通り。

• 完全ブラウザ内動作：生成処理は全部あなたのブラウザの JavaScript の中で完結します。サーバーに生成結果を送信することは一切ありません。
• 暗号学的に安全な乱数：Math.random() のような予測可能な疑似乱数ではなく、ブラウザ標準の crypto.getRandomValues() を使っています。
• 長さ・文字種のカスタマイズ：4〜128 桁、英大小・数字・記号のオンオフ、紛らわしい文字（0/O、1/l/I）の除外などに対応。
• 複数個まとめて生成：一度に複数のパスワードを作って好きなものを選べます。

内部で使っている乱数生成の仕組み

中身の実装はシンプルです。Web Crypto API の crypto.getRandomValues() で 1 バイトずつ乱数を取り、使用する文字集合の範囲にマッピングします。擬似コードで書くとこんな感じ。

const charset = "ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz23456789";
const bytes = new Uint8Array(16);
crypto.getRandomValues(bytes);
let result = "";
for (const b of bytes) {
  result += charset[b % charset.length];
}
// result: 例 "K7mPq3RxV9tLwZnH"

厳密には b % charset.length は少しだけ偏る（モジュロバイアス）ので、本番実装では棄却サンプリング（文字集合の倍数超過分を再取得）を使っていますが、考え方はこれと同じです。

使い方のコツ

• 最低 16 桁：英大小 + 数字 + 記号なら 16 桁で約 105 bit、実用的に総当たり不能。
• 紛らわしい文字を除外：紙に書き写す可能性があるなら 0/O、1/l/I の混同を避けるオプションを ON に。
• 記号が使えないサービス向けに英数字のみモード：たまに「記号不可」という古いサービスがあるので、そのときは 20 桁以上の英数字だけで対応。
• マネージャと組み合わせる：生成したパスワードはその場でパスワードマネージャに保存。人間が覚える必要はありません。

Python で同じことをしたいときは、標準ライブラリの secrets モジュールが使えます。こちらもスクリプト作業や CI/CD のシークレット生成で便利。

import secrets
# URL 安全な 16 バイト（約 128 bit）のトークン
print(secrets.token_urlsafe(16))
# 出力例: pJ8kX9LmN3qR4sT6uVwYz_
# 任意文字集合からのパスワード生成
import string
alphabet = string.ascii_letters + string.digits + "!@#$%^&*"
pw = "".join(secrets.choice(alphabet) for _ in range(16))
print(pw)

random モジュールの代わりに secrets を使うのがポイントです。random はメルセンヌツイスタという決定論的な疑似乱数で、セキュリティ用途には不適切。secrets は OS が提供する暗号学的乱数源（Linux の /dev/urandom など）を使います。

NIST SP 800-63B の最新ガイドライン

米国連邦政府の標準文書である NIST SP 800-63B「Digital Identity Guidelines: Authentication and Lifecycle Management」は、パスワードポリシーに関する最も影響力のあるガイドラインです。2017 年の初版、2020 年の改訂版、2024 年のドラフト版を経て、現在のベストプラクティスが形になっています。要点だけ抜き出すと以下の通り。

注目すべきは 「文字種の強制禁止」と 「定期変更の強制禁止」の 2 点です。どちらも昔は「セキュリティのベストプラクティス」と思われていたもので、現在は効果がないどころか逆効果であることが実証されています。文字種ルールはユーザーを Password1! のような最小限の変形に追い込むだけですし、定期変更は覚えやすい派生パターンを量産するだけです。どちらも「ユーザーに覚えさせる設計」そのものが誤りで、マネージャで生成・保存する前提に立てば全て不要になります。

代わりに重要視されているのが ブラックリストチェックです。ユーザーが設定しようとしたパスワードが既に漏洩リスト（HIBP Pwned Passwords など）に存在していないか、サービス名やユーザー名と類似していないかを、サーバー側でリアルタイムに検証する。これが「弱いパスワードを事前にブロックする」唯一有効な方法だとされています。サービス開発者側の実装ポイントは、この事前検証と、強制ルールの廃止の 2 つ。ユーザー側としては、マネージャで長い乱数パスワードを生成しておけば、ブラックリストに当たる心配もありません。