安全なパスワードの作り方｜やってはいけない5つのパターンと現在の推奨

「大文字・小文字・数字・記号を混ぜて8文字以上」——多くのサービスで求められるこのルールは、実は現在のセキュリティガイドラインでは推奨されていません。この記事では、パスワードの強さが何で決まるのかを数値で整理し、実際にどう作ればよいかを解説します。

パスワードの強さは「長さ」で決まる

パスワードの強度は、エントロピーという指標で表せます。「総当たりで試すべき組み合わせが何通りあるか」を、情報量（ビット）に換算したものです。

計算式はシンプルです。

エントロピー（bit） = パスワードの長さ × log2(使える文字の種類数)

文字種ごとの1文字あたりの情報量は次のとおりです。

ここから、実際のパスワードを比較してみます。

注目すべきは3行目です。 「16文字の英小文字だけ」のパスワードは、「8文字で記号まで混ぜた」パスワードより強度が高くなります。

つまり、記号を無理に混ぜて覚えにくくするより、単純に長くするほうが効率的です。エントロピーは長さに比例して増えますが、文字種を増やしても1文字あたりの情報量は対数的にしか増えないためです。

記号を1種類増やすより、文字を1文字増やすほうが効く。これがパスワード設計の基本原則です。

やってはいけない5つのパターン

1. 使い回し（最悪のパターン）

これが単独で最大のリスクです。 どれだけ複雑なパスワードでも、複数のサービスで同じものを使っていれば、1か所の漏洩ですべてが破られます。

攻撃者は、漏洩したIDとパスワードの組み合わせを他のサービスで片端から試します（クレデンシャルスタッフィングと呼ばれる手法です）。パスワードの複雑さは、この攻撃に対して一切の防御になりません。

2. 個人情報から作る

誕生日、名前、電話番号、ペットの名前、勤務先——これらはSNSや名刺から容易に推測されます。標的型の攻撃では、まずこうした情報を組み合わせた候補から試されます。

3. 末尾の数字だけ変える

Password2024 → Password2025 のような変更です。定期変更を求められたときに多くの人がやる方法ですが、規則性が明白なため、1つ漏れれば他も推測されます。

4. 単純な文字置換（リート表記）

password → p@ssw0rd のように、a→@、o→0、i→1 と置き換える方法です。

この変換は攻撃ツールに標準で組み込まれています。 辞書攻撃のツールは、辞書の各単語に対して自動的にこの種の変換を適用して試すため、元の単語のままとほとんど変わりません。

5. 短くて複雑

Xq7!@z のような、覚えにくいわりに短いパスワードです。前述のとおり、6文字では記号を混ぜても強度が足りません。複雑さで長さを補うことはできません。

実際にどう作るか

用途によって現実的な方法が変わります。

方法1：ランダム生成（推奨）

自分で入力する必要がないパスワード（後述するパスワード管理アプリに保存するもの）は、ランダム生成が最適です。人間が考えたパスワードには必ず癖が出るためです。

パスワード生成ツールでは、文字種と長さを指定してランダムなパスワードを生成できます。ブラウザ内で生成するため、生成したパスワードがサーバーに送信されることはありません。

推奨する設定は次のとおりです。

• 長さ：16文字以上（サービス側の上限が許す限り長く）
• 文字種：英大小＋数字（記号は、サービスによって使えない場合があるため必須ではない）

手書きで転記する必要がある場合は、0 と O、1 と l のように紛らわしい文字を除外するオプションを有効にすると、読み間違いを防げます。その分だけ文字種は減りますが、長さで十分に補えます。

なお、当ツールは暗号論的に安全な乱数生成器（crypto.getRandomValues）を使用しています。JavaScript の Math.random() は乱数の質が保証されておらず、パスワード生成には適していません。

方法2：パスフレーズ（覚える必要がある場合）

PCのログインパスワードやパスワード管理アプリのマスターパスワードなど、自分で覚えて入力する必要があるものには、複数の単語をつなげる方式が向いています。

correct-horse-battery-staple

無関係な単語を4つ以上つなげると、覚えやすさを保ったまま十分な長さを確保できます。ただし条件があります。

• 単語同士に意味的なつながりがないこと（「東京-大阪-新幹線」のような関連語はNG）
• ことわざや歌詞など、既存のフレーズを使わないこと
• 単語は自分で恣意的に選ばず、ランダムに選ぶこと

方法3：サービスのルールに合わせる

「記号を1つ以上含めること」といった要件があるサービスでは、生成したパスワードの末尾に記号を足す形で対応します。要件のために全体を短くしてはいけません。

定期変更は推奨されなくなりました

「パスワードは3か月ごとに変更する」というルールを見たことがあると思いますが、現在の主要なガイドラインでは、定期的な変更の強制は推奨されていません。

米国立標準技術研究所（NIST）のガイドライン SP 800-63B では、定期変更の強制を求めず、漏洩の兆候がある場合にのみ変更する方針が示されています。日本の総務省も同様の方針に改定しています。

理由は明快です。定期変更を強制すると、利用者は次の行動を取るためです。

• 覚えやすい単純なパスワードを選ぶようになる
• 末尾の数字だけを変える（パターン3）
• メモに書き出す

つまり、定期変更はかえって全体の安全性を下げることが分かってきたためです。

変更すべきタイミングは次の場合です。

1. サービスから漏洩の通知があったとき
2. 不審なログイン通知を受けたとき
3. 他人に見られた可能性があるとき
4. 使い回していたパスワードを整理するとき

作った後の管理が本題

強いパスワードを作っても、16文字のランダム文字列を数十サービス分は覚えられません。 ここで多くの人が使い回しに戻ってしまいます。

現実的な選択肢は3つです。

「紙に書く」は、想像されるほど悪い方法ではありません。 自宅の引き出しに保管する分には、オンラインの攻撃対象になりません。ただし、持ち歩くと紛失リスクが生じます。

いずれの方法を選ぶにせよ、優先順位は「使い回しをやめること」が先です。管理方法の最適解を探して行動が止まるより、まずブラウザ保存でもよいので、サービスごとに違うパスワードにするほうが効果があります。

パスワードだけに頼らない

現在の実務では、パスワードの強度以上に2要素認証（2FA）の有無が重要です。

パスワードが漏洩しても、2要素目（スマートフォンのアプリが生成するコードなど）がなければログインできません。逆に言えば、2要素認証を設定していないサービスは、パスワード1つが破られた時点で終わりです。

最低限、以下のサービスでは必ず有効にしてください。

• メールアカウント（最優先。他サービスのパスワード再設定の起点になるため）
• ネットバンキング・決済サービス
• SNSアカウント
• クラウドストレージ

認証方式には強度の差があります。SMSによるコード送信は、SIMスワップ攻撃の対象になり得るため、認証アプリ（TOTP）やパスキーが選べる場合はそちらを推奨します。

補足：ハッシュ化と暗号化は別物

パスワードに関連してよく混同される2つの概念を整理しておきます。

まともなサービスは、パスワードをハッシュ化して保存しています。そのため「パスワードを忘れた」際に元のパスワードを教えてもらうことはできず、再設定になります。逆に、問い合わせたら現在のパスワードを平文で教えてくれるサービスは、平文または復号可能な形で保存している可能性が高く、危険な兆候です。

ハッシュ値の挙動はハッシュ生成ツールで確認できます。1文字変えるだけで結果が全く変わることが確認できます。なお、テキストを暗号化して保管したい場合はテキスト暗号化ツールが使えます（こちらは鍵があれば復号できます）。

まとめ

1. 強度は長さで決まる。 記号を混ぜるより1文字長くするほうが効く
2. 使い回しが最大のリスク。 複雑さでは防げない
3. 単純な文字置換（p@ssw0rd）は攻撃ツールに織り込み済み
4. 定期変更は不要。 漏洩の兆候があるときに変更する
5. 覚える必要がないものは生成ツールでランダムに、覚える必要があるものはパスフレーズで
6. 2要素認証、特にメールアカウントの設定を最優先で

「完璧な管理方法を決めてから」ではなく、まずは重要なサービスから使い回しをやめることが、最も効果の大きい一歩です。