パスワード完全ガイド:安全な作成・保管・運用の実践(NIST準拠)

はじめに:なぜ今パスワードに注目するのか

パスワードはインターネット時代の鍵であり、個人情報や企業システムへの最初の防御線です。しかし、パスワード漏えい、使い回し、ブルートフォース攻撃、フィッシングなどの手口が高度化し、単純な文字列ではもはや十分ではありません。本稿では、技術的背景(ハッシュ、ソルト、強度)、実務的な対策(パスワードマネージャー、MFA)、運用面のベストプラクティス(ポリシー、リセット、ログ)を、最新のガイドラインや実例に基づいて深掘りします。

パスワードの脅威モデル:何が問題を引き起こすのか

  • 辞書攻撃/ブルートフォース:短く単純なパスワードは総当たりや単語リストで簡単に破られます。

  • レインボーテーブル/ハッシュリストの流出:ハッシュ化だけでは十分でなく、ソルトなしのハッシュは辞書や事前計算で復元されます。

  • パスワード再利用:1つのサービスが侵害されると、別サービスでも同じ資格情報が悪用されます。

  • フィッシング/ソーシャルエンジニアリング:正規の入力画面を偽装して認証情報を盗みます。

  • キーロガーやマルウェア:端末が侵害されるとパスワードが収集されます。

パスワードの強度:長さと複雑さ、エントロピーの考え方

パスワードの強度は「エントロピー(情報量)」で評価できます。ランダムな文字列は文字集合と長さに基づきビット単位のエントロピーが計算できますが、実際のユーザーが選ぶ単語やパターンは低エントロピーになりがちです。重要な点は以下です。

  • 長さは力:同じ複雑さの条件なら長いパスワードが強い。パスフレーズ(複数の単語を並べる)を推奨します。

  • 複雑さの罠:大文字・小文字・記号を強制して短いパスワードにするより、長めのパスフレーズを許容した方が実用的かつ安全です。NIST SP 800-63Bでも同様の方向が示されています。

  • 使い回しを避ける:どんなに強くても他サービスで同じものを使っていればリスクは増大します。

NISTのガイドライン(SP 800-63B)からの主な示唆

米国標準技術研究所(NIST)のSP 800-63Bは、近年の認証に関する重要な指針を示しています。代表的なポイントを要約すると:

  • ユーザーが作成する「memorized secret(記憶による秘密)」の最小長は一般に8文字を推奨し、サービスに応じて長さを引き上げること。

  • 定期的な強制的パスワード変更(期限によるリセット)は原則不要。リスクがなければ変更を強制しない。

  • 一般的なパスワードや既に流出した資格情報はブロックすべき。辞書やPwnedリストとの照合が有効。

  • 複雑な文字種の強制より、長さとユニーク性を重視する点を推奨。

パスワード保存の技術(開発者・運用者向け)

パスワードを安全に保存する基本は「常にハッシュ化してプレーンテキストを保存しない」ことです。さらに詳細:

  • ソルト(Salt):各パスワードにランダムな一意ソルトを付けることでレインボーテーブル攻撃を防ぎます。

  • コストのかかるハッシュ関数:bcrypt、scrypt、Argon2などのストレッチング(時間・メモリを要する)アルゴリズムを用いる。現在はArgon2(特にArgon2id)が推奨される選択肢です。bcryptは広く使われているが、パラメータのチューニングが必要です。

  • ペッパー(Pepper):特定のサーバー側で保持する追加の秘密値(DB外に安全に保管)を用いることで、DB漏えい時のリスクを低減できます。ただし管理を誤ると逆効果です。

  • ハッシュパラメータの運用:アルゴリズムやコストパラメータは時間経過に合わせて見直し、ログイン時に段階的にリハッシュを行う仕組みを準備してください。

パスワードリセットと回復フローの設計

パスワードリセットは最も悪用されるポイントの一つです。安全に設計する要点:

  • リセットトークンは一意で推測不可能、短期間(例:15分〜1時間)の有効期限とし、一度使ったら無効化する。

  • トークンはハッシュ化してDBに保存し、プレーンで保存しない。

  • 多要素認証や登録済みメール・電話への通知を組み合わせて不正なリセットを検出する。

  • リセット要求が複数回あった場合はレートリミットやCAPTCHAで自動化攻撃を防止する。

実践的なエンドユーザー向けアドバイス

  • パスワードマネージャーを使う:ユニークで長いランダムパスワードを生成・保存することで使い回しと弱パスワードの問題を解消できます。ローカル暗号化とマスターパスワード+MFAを併用しましょう。

  • MFA(多要素認証)を有効化:可能な限りFIDO2/WebAuthnやTOTP、SMSは補助として。FIDO2やパスキーはフィッシング耐性が高く推奨されます。

  • フィッシング対策:メールの送信元/リンク先を常に確認し、不審なログイン要求には応じない。ブラウザやOSの認証プロンプトを鵜呑みにしない。

  • バックアップと緊急アクセス:パスワードマネージャーは緊急アクセス機能やオフラインバックアップを活用して突然のロックアウトに備える。

組織が取るべき運用措置(ポリシーと教育)

技術対策だけでなく、運用と教育も重要です。

  • パスワード方針の見直し:短期的な期限切れルールや無意味な複雑化は避け、NISTの勧告に沿った方針を採用する。

  • 監査とログ:ログイン失敗の閾値、異常な地理的アクセス、デバイスの変化を監視して自動アラートを出す。

  • ブリーチ対応:外部の流出チェック(Have I Been PwnedのPwned Passwordsなど)を利用して、流出した資格情報をブロックする。

  • 社員教育:フィッシング訓練、マルウェア対策、パスワード管理の研修を定期的に実施する。

移行・互換性:古いハッシュ方式からの脱却

レガシーなMD5/SHA1などはもはや安全ではありません。移行の一般的手順:

  • ログイン時にユーザーのパスワードを検証し、新方式(Argon2など)で再ハッシュして保存する「ジャストインタイム移行」を活用する。

  • 全ユーザーに一括リセットを強制する方法はUXを損なうため、段階的移行が現実的。

  • 移行計画には既存データのバックアップ、互換性テスト、負荷試験を含める。

将来の認証トレンド:パスワードからパスキーへ

セキュリティ界隈ではパスワードレス認証が急速に普及しています。FIDO2/WebAuthnやパスキーは、公開鍵暗号を用いてフィッシング耐性の高い認証を提供します。可能であれば、新規サービスではパスワードレスを第一選択肢として検討してください。

実践チェックリスト(まとめ)

  • ユーザー:ユニークな長いパスフレーズ+パスワードマネージャー+MFAを必ず利用。

  • デベロッパー:Argon2等のメモリ・CPU負荷型ハッシュを利用し、ソルトを一意にし、ハッシュパラメータを定期的に見直す。

  • 管理者:パスワードポリシーをNIST準拠で設計し、ブローチェック(Pwned等)を導入、リセットフローを厳格化。

  • 組織:社員教育、ログ・監視、インシデント対応計画を整備する。

結論

パスワードは便利である一方、適切に扱わなければ大きな脆弱性になります。最新のガイドライン(NIST)や現実的な運用ノウハウ(ハッシュ化、ソルト、MFA、パスワードマネージャー)を組み合わせることで、リスクを大幅に下げられます。将来的にはパスワードレスの採用が進むでしょうが、当面は上記のベストプラクティスを実践することが重要です。

参考文献