安全なパスワードとは？条件と作り方を解説

「安全」を判定するのは誰か

パスワードの安全性を判定する主体は、3つに分かれます。

• 作る側（利用者と生成器）。推測されにくい文字列を作ります。
• 受理する側（サイトの登録フォームと検証器）。上限文字数、使用可能な文字、必須の文字種、変更の頻度を決めます。
• 破ろうとする側（攻撃者）。保存方式、試行回数の制限、多要素認証の有無でコストが変わります。

利用者が選べる範囲は、受理する側が決めてしまいます。上限が12文字なら12文字までしか使えません。長さの考え方はパスワードは何文字あれば安全か、記号の効果はパスワードに記号は本当に必要かで扱っています。

標準は「してはならない」ことも定めている

NIST SP 800-63B-4（2025年7月）は、最低長だけでなくサイト側が課してはいけない条件も明記しています。

• 単一要素認証は最低15文字、多要素認証の一部としてのみ用いる場合は最低8文字（SHALL）。
• 最大長は少なくとも64文字を許容すべき（SHOULD）。
• 印字可能ASCII・空白・Unicodeの受容は推奨（SHOULD）。Unicodeは符号点を1文字と数えます（SHALL）。
• 文字種の混在を強制する合成規則は禁止（SHALL NOT）。
• 定期的な変更の強制も禁止（侵害の証拠がある場合のみ強制）。
• 登録・変更時にパスワード全体をブロックリストと照合し、拒否時は理由を示す（SHALL）。

これらは利用者への助言ではなく、検証側（サイト）に対する要件です。OWASPも文字種を制限する合成規則を置くべきでないとしています。条文ごとの内容はNISTはなぜパスワードを15文字以上にしたのかで扱っています。

前提となる理論エントロピー

以降の比較のため、文字数と文字集合から決まる理論値の目安を確認します。

表1：文字数と文字集合から決まる理論エントロピー（ビット）

一様ランダムに生成した場合の理論値です。詳細はパスワードは何文字あれば安全かを参照してください。

よくあるサイト要件と標準の乖離

表2は、登録フォームでよく見かける要件を標準と並べたものです。「衝突点と実測」の列は、Lee et al. (2022) が英語圏の主要120サイトを実際に登録して調べた結果です。

表2：よくあるサイト要件と、標準が定める内容の対照

出典：Lee et al. (2022) SOUPS 2022（2022年時点・英語圏）。国内の銀行は主要銀行7行のパスワード要件で別途調査しています。

押さえたいのは、「標準に反する要件」と「弱い要件」は別物だという点です。文字種の混在を課す54サイトは標準に反しますが、何も要求しないサイトより強い値を導く可能性があります。逆に、71サイトがブロックリストを実装していないことは標準違反であると同時に攻撃に対して無防備です。文字種の規則を課しながら、最もよく使われる値を受け入れてしまう。これが現場で最も多い失敗の形です。

公式文書で確認できる受理条件

表3は、管理基盤と大手サービスの公式文書に記載された受理条件です。

表3：公式文書に記載された受理条件（2026年9月17日確認）

最も重要なのは、Windows ADの「最小パスワード長」ポリシーが0〜14文字でしか設定できず、「14文字を超える最小長は現時点でサポートされない」と明記されている点です。NISTが単一要素認証に要求する15文字は、この設定では要求できません。組織が標準に合わせようとしても、管理基盤の仕様が先に上限を決めてしまいます。

期限の扱いには立場の変化が表れています。Microsoftは従来の「30〜90日」という推奨を残しつつ、自社のセキュリティベースラインにはパスワード有効期限ポリシーを含めていない（近代的な緩和策より効果が低いため）と説明しています。Entraの禁止パスワードリストは全テナントに適用され、カスタムリストは最大1,000語です。

受理条件が強度の天井を決めてしまう

表4は、受理条件ごとに「その条件が許す文字列の総数」と理論ビットを並べたものです。

表4：受理条件が許す文字列の総数と理論ビット

2行目は印字可能ASCII 95種を4文字種に分け、長さ4〜12で4種すべてを含む文字列を包除原理により数えた値です。3行目はMicrosoftの公表値を引用しています。

上限12文字のサイトでは、使える文字をすべて動員しても約78.8ビットが天井です。15文字を英数字で満たした89.3ビットとは10.5ビット、倍率にして約1,400倍の差があります。サイトが上限を決めた時点で最大強度が決まるため、この差は利用者の努力では埋められません。上限12文字のまま4文字種すべてを必須にすると総数は5.40 × 10²³から3.79 × 10²³へ減ります。文字種の規則は集合を広げる操作ではなく、その一部を禁止する操作です（記号の記事）。

3行目はMicrosoft自身が示した数値で、最小長8文字と複雑性要件の組み合わせで「少なくとも159,238,157,238,528通り」と説明されています。約47.2ビットで、一様な英数8文字の47.6ビットより小さい値です。複雑性要件を課しても、62種の文字を使えるようにする場合を上回りません。

なぜサイトは古い規則を残すのか

受理条件が標準から外れる理由は、多くの場合、意図的な設計ではなく歴史的な経緯です。NISTは付録A.3で、サービスが空白や特殊文字を拒否するのはSQLインジェクションなどを避ける意図であることがあるが、未加工のパスワードがデータベースへそのまま渡ることはないため、そのような予防策は不要であると指摘しています。上限文字数も、データベースのカラム長やフィールド設計がそのまま残っていることがあります。

ただし上限を設けること自体に正当な理由はあります。OWASPは、ハッシュ実装によっては非常に長い入力がサービス妨害につながりうるとして最大入力長の制限を挙げ、NISTもメガバイト級の入力には上限が妥当だとしています。問題は上限の存在ではなく、その水準です。付録A.5は、推奨を超える要件が逆効果な回避行動を招くとし、ブロックリストやレート制限を優先するよう求めています。

衝突したときに何を優先するか

サイトの受理条件は変えられません。変えられるのは自分の選択だけです。

1. 使い回しをしない。漏えいした認証情報が別サイトで試される攻撃に対し、文字数を1〜2文字増やす効果はほとんどありません。
2. 多要素認証またはパスキーを有効にする。NISTが多要素認証の一部に8文字を許容しているのは、この前提があるためです（二要素認証ガイド）。
3. サイトが許す最大限の長さを使う。上限が12文字なら12文字、64文字以上ならそれ以上です。
4. 生成器で作り、パスワードマネージャーに保存する。

要件ごとの対処は次のとおりです。

• 上限が12文字以下。そのサイト専用の値を作ります。既存の値を切り詰めると、他サービスと似た形になり使い回しに近づきます。
• 記号を要求される。生成器で記号を含めて作れば済みます。危険なのは、末尾に「!」を足す、「a」を「@」に置き換えるといった人間の対応です。
• 90日ごとの変更を求められる。派生を作らず新しい値を作り直します。

サイトごとに異なる値を使うことが、個々の値の強度より優先されます。

受理条件に合わせるための、当サイトの機能

パスワード生成ツールは、サイト側の受理条件に合わせて出力を調整できるように作っています。

• 文字数の完全な指定：4〜128文字を1文字刻みで指定できます。
• 必含ルール：チェックした文字種を最低1文字含めます。
• 追加で除外する文字：受け付けられない記号を除外できます。
• 頭文字の指定：先頭を英大文字で開始といった規則に対応します。

生成にはブラウザ標準のcrypto.getRandomValues()を使います。乱数をそのままvalue % 文字数に当てると一部の文字が選ばれやすくなるため、割り切れる範囲だけを採用して範囲外を取り直す拒否サンプリングを行っています。並び替えも同じ乱数源によるFisher–Yates方式です。ただし必含ルールを有効にした出力は条件付きの集合から生成されるため、画面の強度表示は条件を課さない場合の候補空間の目安（上限）として読んでください。詳細はパスワード生成の安全設計と実装方針で公開しています。

実践例：英数字16文字の条件に合わせて作り、保存する

架空の「練習用会員サービス」が、16文字ちょうど・半角英大文字と英小文字と数字を各1文字以上・記号と空白は不可と定めているとします。これは手順を説明するための仮定であり、実在サイトで会員登録やログインを試した結果ではありません。実際には登録先の公式案内で最小長・最大長・使用可能文字・必須文字種を確認してください。

1．要件を生成器の設定に置き換える

記号なしパスワード生成を開き、「生成条件」の詳細設定で文字数を16にします。「英大文字」「英小文字」「数字」をすべてオンにし、記号を使わない状態を確認します。「チェックを入れた文字種を必ず1文字以上含める（偏り防止）」もオンにします。文字種を使用可能にするだけでは、各種が必ず入るという条件とは異なるためです。「頭文字の指定」は空欄、「追加で除外する文字」も空欄にします。画面の操作は使い方ガイドで確認できます。

手入力が必要なら「似ている文字を除外」を任意でオンにできます。架空の要件に「Oと0は禁止」が加わった場合は、「追加で除外する文字」にO0を入力します。除外は候補となる文字を減らす設定なので、必要な場合だけ使い、大文字・小文字・数字それぞれに使える文字が残っていることも確認します。

2．このアカウント専用の値を新しく生成する

設定変更は出力へ自動で反映されます。設定を見直した後に「もう一度生成」を押して、新しい候補を作ります。既存のパスワードを切り詰めたり、末尾の数字だけ変えたりせず、毎回独立した値を用意します。この記事や他の公開ページに載った例は誰でも知ることができるため、パスワードとして使わないでください。ここではコピーして使える完成例を掲載しません。実際のパスワードを説明用の入力欄、公開メモ、問い合わせ、外部の確認サイトへ貼り付ける必要もありません。

3．生成結果を要件と照合する

• 長さ：出力が16文字であることを確認します。コピー時に前後の空白や改行を含めないようにします。
• 文字：半角のA〜Z、a〜z、0〜9だけで、記号・空白がないことを確認します。
• 必須条件：大文字・小文字・数字がそれぞれ1文字以上あり、任意で指定した除外文字が入っていないことを確認します。

条件と違う場合は、値を手で修正せず設定を直して再生成します。登録先で拒否された場合も、表示された理由と公式要件を再確認してください。フォームで受理されたことは、安全性の証明ではありません。この16文字はNISTの単一要素認証の最低15文字を満たす長さですが、架空の文字種強制や16文字上限をNISTが推奨しているわけではありません。NISTの検証器の要件には、漏えい済み・よく使われる値との照合、試行回数の制限、適切なハッシュによる保存などもあります。生成器の出力確認だけで登録先の実装まで検証することはできません。使い回しを避け、多要素認証やパスキーも利用できるか確認します。

4．正しいURLとユーザー名を付けて保存する

パスワードマネージャーには、生成した値だけでなく、登録先の正しいログインURLと、そのアカウントのユーザー名またはメールアドレスを一緒に保存します。練習用なら自分が管理するテスト環境のURLとテスト用ユーザー名を使い、本番の項目とは区別できる名前を付けます。自動入力を使うときも、ブラウザのアドレス欄と保存項目のサイトが一致していることを確認します。

Chromeを使う場合は保存先も確認します。Chromeの公式ヘルプでは、ChromeにログインしてGoogle アカウントへ保存する場合は他のデバイスや一部のアプリで利用でき、Chromeにログインしていない場合はデバイス内へローカルに保存すると説明しています。別端末で使いたいなら、同じGoogle アカウントに保存されているかを確認してください。デバイスだけに保存した値が別端末にもあるとは限りません。当サイトの生成履歴はマネージャーへの保存の代わりにはなりません。

5．テスト用アカウントで保存とログインの対応を確認する

ここからも説明用の手順です。自分が管理するテスト環境で、練習用アカウントに新しい値を設定し、保存項目を確認してからログアウトします。正しいログインURLを開き直し、マネージャーから対応するテスト用ユーザー名とパスワードを入力して、想定したアカウントへログインできることを確認します。失敗した場合はURL・ユーザー名・保存した値・設定完了の有無を見直し、何度も試してロックさせないようにします。この確認で分かるのは保存した認証情報がそのテスト環境で使えることまでで、サービス全体の安全性ではありません。本記事では実在サイトへの登録試験や実アカウントでのログイン確認は行っていません。

長い語句を使いたい場合はパスフレーズ生成の説明を参照し、登録先がその長さや文字を受け付けるか先に確認します。今回の16文字・英数字のみの条件では、上記のランダム文字列の手順を使います。

よくある質問

覚えやすさと安全性を両立するには

当サイトの「覚えやすい」モードは、EFFの7,776語から6語を重複を許して独立に選びます。候補空間は約77.5ビットで、区切りや大文字設定を追加のランダム性として数えません。パスフレーズ生成と詞庫の出典を確認し、利用先が長さと空白を受け付ける場合に使ってください。日本語話者が覚えやすいかは実測していません。単語を削ったり、別サイトで使い回したりせず、多要素認証またはパスキーも利用します。

まとめ

1. 「安全」を判定する主体は3つある。作る側、受理する側、破ろうとする側で、利用者が選べる範囲は受理する側が決めます。
2. 標準は「してはならない」ことも定めている。文字種の混在と定期変更の強制はSHALL NOT、最大長64文字以上の許容はSHOULDです。
3. 実装は標準から離れている。主要120サイトの実測では、54サイトが文字種の規則を採用し、71サイトがブロックリストを未実装、17サイトが64文字未満の上限を設けていました。
4. 受理条件は強度の天井を決める。上限12文字では約78.8ビットが上限で、15文字の英数字（89.3ビット）とは約1,400倍の差がつきます。
5. 優先順位は、使い回しの回避、多要素認証、上限までの長さ、生成器とマネージャーの順です。

本記事の調査範囲と限界

• 記事の役割を分けています。長さとエントロピーの数学、攻撃予算、保存方式ごとの費用はパスワードは何文字あれば安全か、記号と文字種の効果はパスワードに記号は本当に必要か、標準の条文はNISTはなぜパスワードを15文字以上にしたのかで扱っています。本記事は受理条件と強度要求の衝突を扱い、架空の条件を使った設定・生成・保存・ログイン確認の実践手順も示します。この手順は説明用で、実在サービスの登録試験や安全性の監査ではありません。
• 実サイトの調査は2022年の英語圏のデータです。表2の実測値はLee et al. (2022) に基づき、現在の状態を示すものではありません。
• Microsoftの公表値は再現できていません。導出方法は文書に記載がなく、本記事が同じ前提で包除原理により計算すると約2.66 × 10¹⁵（51.2ビット）となり一致しません。公開値と計算値は分けて提示しています。
• Windows ADの最大文字数は確認できていません。該当ページを取得できなかったため、表3では最小長のみを記載しています。表3は特定ベンダーの既定値であり、表のビット値も一様ランダム生成を前提とした上限です。

参考資料

• NIST SP 800-63B-4（§3.1.1.1・§3.1.1.2・付録A）
• NIST SP 800-63B-4 本文PDF（DOI）
• Lee et al. (2022)・主要120サイトのパスワードポリシー実測（SOUPS 2022）
• OWASP・Authentication Cheat Sheet
• Microsoft Learn・Minimum password length（0〜14文字の設定範囲）
• Microsoft Learn・Password must meet complexity requirements
• Microsoft Learn・Maximum password age（既定42日）
• Microsoft Learn・Microsoft Entra ID のパスワードポリシー
• Microsoft Learn・Entra Password Protection の禁止パスワードリスト
• Google Workspace 管理者ヘルプ・パスワードポリシーを設定する
• Google Chrome ヘルプ・パスワードを管理する（Google アカウントとデバイスへの保存）
• NIST SP 800-63B-4・Password Verifiers（保存・照合・マネージャーの利用）
• W3C・Web Cryptography API（Crypto.getRandomValues()）

著者・編集：passwordgenjp.com 情報セキュリティ研究チーム。既存調査の公開資料確認日：2026年9月17日。実践例とChrome・NISTの関連資料の確認日：2026年10月8日。