パスワードポリシーの考え方——ユーザビリティとセキュリティを両立する設計
過剰なパスワードポリシーが招く逆効果をNISTガイドラインとともに解説。ユーザビリティを損なわずセキュリティを高めるための設計原則を紹介。
パスワードポリシーが逆効果になる典型パターン
「定期変更強制」「複雑さルール」「頻繁なロックアウト」——これらはセキュリティ強化のために導入されたはずが、実際にはユーザーの行動を悪化させることが多いよ。
NISTが明確に「やめろ」と言っていること
NIST SP 800-63Bで否定されている慣行：
- 定期的な強制変更：「漏洩の証拠がない限り変更を強制しない」
- 複雑さルールの強制：記号や大文字の必須化はユーザーに弱いパターンを生む
- パスワードヒント：秘密の質問や入力ヒントは攻撃に利用される
- 以前と似たパスワードの禁止：変更パターンが予測可能になる
- ハードコードされた一般的なパスワードの許可：「password」「123456」を弾くのは正しい
良いパスワードポリシーの設計要素
要素1：長さを重視する
- 最低文字数：8文字（推奨は16文字以上に引き上げ）
- 最大文字数：64文字以上（制限しない）
- スペースを含む入力を許可する（パスフレーズ対応）
要素2：漏洩パスワードリストとの照合
新しいパスワード設定時に、既知の漏洩パスワードリスト（HaveIBeenPwnedのAPIを使ったk-anonymityチェックなど）と照合して弾く。複雑さルールより実効性が高いよ。
要素3：コンテキストに基づく認証強化
毎回複雑な認証を求めるのではなく、リスクが高い場合（新しい端末・新しい場所・高額取引など）に追加認証を求めるアダプティブ認証が理想的だよ。
要素4：多要素認証を標準化
パスワードポリシーを複雑にするより、MFAを必須にする方が圧倒的にセキュリティが上がる。パスワードは「MFAがある前提での第一要素」として設計しよう。
ユーザーへの表示の改善
- パスワード強度メーターをリアルタイムで表示する
- 「マスク解除」ボタンで入力内容を確認できるようにする
- エラーメッセージは具体的に（「8文字以上が必要です」ではなく「あと3文字追加してください」）
サービス設計者が参照すべきドキュメント
- NIST SP 800-63B：米国標準技術研究所のデジタル認証ガイドライン
- IPA「パスワードリスト攻撃への対策について」：日本語の実装ガイド
- OWASP Authentication Cheat Sheet：Webアプリ向けの実装チェックシート
ポリシーは「ユーザーが安全に行動しやすい環境を作る」ためにある。複雑さで締め付けるより、安全な選択が自然にできる設計を目指そう。
作ったパスワードは頭で覚えるのではなく、マネージャーに任せると安全です。 編集部がふだん使っているサービスをご紹介します。
洗練されたUI・Watchtower侵害通知・旅行モード搭載。Apple製品ユーザーに特に人気の老舗マネージャー。
オープンソースで透明性が高く、無料プランでも基本機能をフルに使える。セルフホストも可能。
SOC2 Type2認証取得済み。BreachWatch によるダークウェブ監視と法人向け管理コンソールが強力。
NordVPN 系列の老舗。XChaCha20 暗号化・データ漏洩スキャナ・パスワードヘルスを内蔵。日本語UI対応。
スイス拠点・Proton Mail 系列。E2E 暗号化・メールエイリアス・2FA を1つに統合。プライバシー重視派に。