不正ログインの原因の多くは、パスワードの使い回しや推測されやすいパスワードに関係しています。
IT研修やセキュリティ教育の場でも、最初に取り上げる基本テーマです。
この記事では、利用者として守りたいパスワードの考え方と、サービスを開発する側がパスワードを安全に扱うための基本を、まとめて解説します。
利用者向け：安全なパスワードの考え方
長さを優先する
パスワードの強さは、複雑さよりも長さに大きく左右されます。
記号を混ぜた短いパスワードより、ランダムな単語を組み合わせた長いパスワード（パスフレーズ）のほうが、推測されにくく覚えやすいことが知られています。
目安として、12文字以上、できれば14〜16文字以上を推奨するのが近年の流れです。
使い回さない
あるサービスから流出したID・パスワードを使い、ほかのサービスへログインを試みる「パスワードリスト攻撃」が広く行われています。
サービスごとに異なるパスワードを使うことが、被害を限定する基本です。
推測されやすいものを避ける
- 名前、誕生日、電話番号、キーボード配列（qwerty、123456など）
- 辞書にある単語に、数字を1つ付けただけのもの
- ほかのサービスで使っているものの、一部だけを変えたもの
パスワードマネージャーと多要素認証
大量の長いパスワードを覚えるのは現実的ではありません。
パスワードマネージャーを使えば、サービスごとにランダムな文字列を生成して管理できます。
さらに、重要なサービスでは、多要素認証（MFA）を有効にしましょう。
パスワードが漏れても、不正ログインを防ぎやすくなります。
定期的な変更は必須ではない
以前は「3か月ごとに変更」といった運用が一般的でしたが、強制的な定期変更は、かえって弱いパスワードを招くとして、見直しが進んでいます。
漏えいの疑いがあるときに、速やかに変更する運用が基本です。
開発者向け：パスワードの保存と扱い
平文で保存しない
パスワードは、データベースに平文で保存してはいけません。
データベースが漏えいしたときに、すべての利用者のパスワードがそのまま流出してしまいます。
専用のハッシュ関数を使う
SHA-256のような高速なハッシュ関数は、攻撃者に大量の推測を許してしまうため、パスワード保存には向きません。
bcrypt、scrypt、Argon2など、意図的に計算コストが高く設計されたパスワード用のハッシュ関数を使い、ソルト（利用者ごとのランダムな値）を付けて保存します。
多くのライブラリでは、ソルトは自動的に付与されます。
パスワードの通信とログ
- 通信は必ずHTTPSで行う。
- パスワードをログやエラーメッセージに出力しない。
- パスワードを、メールで送らない。
再設定が必要な場合は、有効期限付きの再設定用リンクを送る。
ログインの保護
- 連続した失敗に対する、試行回数の制限やアカウントの一時ロック。
- 「IDが存在しない」と「パスワードが違う」を区別しないエラーメッセージ（アカウントの存在を推測されないため）。
- 多要素認証への対応。
入力側の制約を緩やかに
文字種の強制や、貼り付けの禁止は、利用者の負担を増やし、パスワードマネージャーの利用を妨げます。
最小長を確保し、推測されやすいパスワード（漏えいリストに含まれるものなど）を拒否する方向が、より効果的です。
教育の現場で伝えたいこと
セキュリティ教育では、「複雑にしなさい」という指示よりも、「長くする」「使い回さない」「多要素認証を使う」という具体的な行動を伝えるほうが、実際の行動変容につながります。
担当者が、攻撃の実例（パスワードリスト攻撃など）を交えて説明すると、納得感が高まります。
まとめ
利用者は、「長く、使い回さず、多要素認証」。
開発者は、「平文で保存せず、専用のハッシュ関数を使い、ログインを保護する」。
この基本を押さえるだけでも、パスワードにまつわる多くの事故を防げます。
