-
タグ
タグ
- アーキテクト
- アジャイル開発
- アプリ開発
- インシデントレスポンス
- イベントレポート
- カスタマーストーリー
- カルチャー
- 官民学・業界連携
- 企業市民活動
- クラウド
- クラウドインテグレーション
- クラブ活動
- コーポレート
- 広報・マーケティング
- 攻撃者グループ
- 子育て、生活
- サイバー救急センター
- サイバー救急センターレポート
- サイバー攻撃
- サイバー犯罪
- サイバー・グリッド・ジャパン
- サプライチェーンリスク
- システム開発
- 趣味
- 障がい者採用
- 初心者向け
- 白浜シンポジウム
- 情シス向け
- 情報モラル
- 情報漏えい対策
- 人材開発・教育
- 診断30周年
- スレットインテリジェンス
- すごうで
- セキュリティ
- セキュリティ診断
- セキュリティ診断レポート
- 脆弱性
- 脆弱性管理
- ゼロトラスト
- 対談
- ダイバーシティ
- テレワーク
- データベース
- デジタルアイデンティティ
- 働き方改革
- 標的型攻撃
- プラス・セキュリティ人材
- モバイルアプリ
- ライター紹介
- ラックセキュリティアカデミー
- ランサムウェア
- リモートデスクトップ
- 1on1
- AI
- ASM
- CIS Controls
- CODE BLUE
- CTF
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- DevSecOps
- DX
- EC
- EDR
- FalconNest
- IoT
- IR
- JSOC
- JSOC INSIGHT
- LAC Security Insight
- NDR
- OWASP
- SASE
- Tech Crawling
- XDR
今でも、次のようなパスワードポリシーを見かけることはありませんか?
- 大文字・小文字・数字・記号をすべて含める
- 90日ごとにパスワードを変更する
- 過去5回のパスワードの再利用は禁止する
多くの企業で標準とされてきたこれらのポリシーの一部は、最新のガイドラインではすでに非推奨、あるいは禁止されています。
本記事では、強化のためのルールがなぜ逆効果になり得るのか、その背景にあるパスワード運用の歴史をひも解きながら、今求められるパスワードポリシーの考え方を解説します。
そのパスワードポリシーは、時代遅れかもしれない
あなたの組織では、冒頭に記したようなパスワードポリシーを今も適用していないでしょうか。もし該当するのであれば、そのルールはセキュリティ対策ではなく、むしろリスクを招く運用になっている可能性があります。これらのルールは長い間「セキュリティの常識」とされてきました。しかし現在では、ユーザーの行動実態や攻撃手法の変化を踏まえ、その有効性が大きく見直されています。
ここからは、米国立標準技術研究所(NIST)が公開している「デジタル アイデンティティ ガイドライン」における認証要件の変遷をたどりながら、最新版であるSP 800-63B Revision 4 Finalのポイントを整理します。
パスワードの起源
堅い説明に入る前に、少し柔らかめの話題から入りたいと思います。
古代ローマ軍の合言葉
パスワードのような仕組みは、コンピュータの登場よりはるか以前から存在していました。古代ローマ軍では、夜間の警備や部隊の識別のためにその日の秘密の合言葉(Victoria:勝利、Mars:マルス(ローマの軍神)、Libertas:自由、など)が決められていました。夜間の見張りが通行者に対して質問し、通行者はこの秘密の合言葉を答えなければなりません。正しい合言葉を答えられなければ侵入者と判断されます。つまり、秘密の合言葉を知っている者だけが通行できるという意味で、現代のパスワードとよく似た仕組みです。
また、古代ローマ軍の敵は、その対抗手段として、スパイを送り込んだり、秘密の合言葉の伝令役の兵士を拘束したりして合言葉を入手することを企んでいました。守る側と破る側のせめぎ合いは、古代ローマ時代から連綿と続いています。技術が進化しても、この構図自体は変わっていません。だからこそ、セキュリティは今もなお終わりのないテーマであり続けています。
コンピュータにおける最初のパスワード
私たちは日常的に「パスワード」という言葉を使っています。しかし、この言葉が誰によって生まれたのかを知っている人はあまり多くありません。実は、コンピュータの世界で「パスワード」という概念を最初に導入した人物は、マサチューセッツ工科大学(以下、MIT)の研究者フェルナンド・コルバト(Fernando J. Corbató)と言われています。
1960年代、MITでは巨大なコンピュータを複数の研究者が共有して利用していました。当時のコンピュータは非常に高価で、研究者はそれぞれ順番に利用する必要があったのです。しかし、ここで問題が生まれます。同じコンピュータを使う研究者たちが、互いのファイルを誤って(あるいは意図的に)見ることができてしまうのです。この問題を解決するため、コルバト氏はCompatible Time-Sharing System(CTSS)というオペレーティングシステムに、ユーザーごとの認証機能を導入しました。その仕組みが、現在の私たちにも馴染み深い「ユーザー名とパスワード」です。
しかし、この仕組みも早々に破られてしまいました。もっとコンピュータを使いたいという動機のもと、システムのバグを利用してパスワードが保存されたファイルを印刷してしまったというのです。これは、史上初のパスワード漏えい事件と言われています。
少し長いウォームアップになりましたが、ここから本題に入ります。次は、デジタル アイデンティティ ガイドラインに見るパスワードの変遷です。
デジタル アイデンティティ ガイドライン NIST SP 800-63とは
NISTが公開しているSP 800-63は、オンラインサービスにおけるデジタルID管理や認証方式の設計指針をまとめたガイドラインです。米国政府機関向けの基準として策定されたものですが、その実践的な内容から、現在では世界中の企業やサービスの認証設計でも広く参照されています。
その最新版であるNIST SP 800-63 Revision 4 Final(2025年8月公開)は、複数の文書(suite of volumes)で構成されています。まずSP 800-63が全体の枠組みと基本概念を示し、SP 800-63Aが本人確認と登録(Identity Proofing & Enrollment)、SP 800-63Bが認証方式やパスワードなどの認証要件(Authentication & Authenticator Management)、SP 800-63Cがフェデレーション認証や認証情報の連携(Federation & Assertions)について説明しています。
認証に関する変遷
続いて、認証に関する変遷をたどっていきます。
初期:複雑性の重視(~2017)
初期のSP 800-63(2004年の初版、2013年のRevision 2など)では、パスワードの安全性は主に複雑さによって確保されると考えられていました。当時は、比較的短く単純なパスワードが一般的であり、攻撃者は辞書に載っている単語や簡単な文字列を機械的に試す「辞書攻撃」や、「総当たり攻撃(ブルートフォース攻撃)」によって認証を突破するケースが多く見られました。
このような攻撃への対策として、次のようなパスワードルールが広く推奨されるようになります。
- 大文字・小文字・数字・記号を組み合わせる
- 最低文字数は8文字程度
- 一定期間ごとにパスワードを変更する
こうしたルールは、複雑なパスワードほど安全という考え方に基づいており、多くの企業システムやWebサービスのパスワードポリシーに取り入れられました。実際、2000年代から2010年代前半にかけては、このようなポリシーがセキュリティの常識として広く普及していきます。
しかしその後、こうしたルールには別の問題があることが明らかになっていきました。パスワード漏えいデータやユーザー行動を精査すると、ユーザーは複雑なパスワードを覚えきれずメモに書いたり、末尾の数字だけを変更したりするなど、結果として安全性が十分に向上しないケースが多く見られたのです。
ここで、あなた自身が普段、実際に使っているパスワードを頭に思い浮かべてみてください。単語のaを@、oを数字のゼロに置き換えるなど、単語の一部を記号や数字に置き換えたり、末尾に規則的な文字列を付けたりするなど、パターン化された加工でパスワードを作っていないでしょうか。実際に多くの人がこのような予測可能なパターンのパスワードを利用してしまい、これが攻撃者にとって大きなメリットとなったのです。
※ NIST Special Publication 800-63-1 Electronic Authentication Guideline
※ NIST Special Publication 800-63-2 Electronic Authentication Guideline
Revision 3(2017)の公開:実用性の重視(従来ルールは非推奨)
こうした状況を受けて、2017年に公開されたSP 800-63 Revision 3ではパスワードに関する考え方を大きく転換しました。改訂の背景には、大規模なパスワード漏えい事件の増加があります。2010年代には多くのオンラインサービスで情報漏えいが発生し、数千万から数億件規模のパスワードデータがインターネット上に公開される事例が相次ぎました。
攻撃者はこれらのデータを利用し、次のような新しい攻撃手法を広く使うようになります。
- パスワードリスト攻撃(漏えいパスワードを使い回す攻撃)
- クレデンシャルスタッフィング(他サービスのパスワードを試す攻撃)
これらの攻撃では、パスワードの「複雑さ」よりも、使い回しや既知のパスワードであることが問題になります。つまり、従来の複雑性ルールはこの種の攻撃に対して十分な防御にならなかったのです。そのため、Revision 3では従来のルールを見直しました。次のような方針が示されたので、一部を列挙します。
- 大文字・小文字・記号などの複雑性ルールは推奨しない(SHOULD NOT)※
- パスワードの定期変更は推奨しない(SHOULD NOT)
- 長いパスワード(パスフレーズ)を許可すべきである(SHOULD)
- 漏えいパスワードリストとの照合を行わなければならない(SHALL)
パスワードを複雑にすることよりも、人間が安全に運用できる仕組みを重視するという考え方へと大きく転換したのです。
※ NIST文書に登場するSHOULD NOTなどの意味。NIST SP 800-63などの技術文書では、要件の強さを示すためにSHALL / SHOULD / MAYといった特定の表現が使われます。これらは単なる英語表現ではなく、意味が厳密に定義された規範語(Normative Keywords)です。用語体系は、インターネット標準であるRFC 2119で定義されており、主な意味は次のとおりです。
| 表現 | 日本語での一般的な訳 | 意味 |
|---|---|---|
| SHALL | ~しなければならない | 必須要件 |
| SHALL NOT | ~してはならない | 明確な禁止 |
| SHOULD | ~することが望ましい | 強い推奨 |
| SHOULD NOT | ~しないことが望ましい | 推奨しない、原則として避ける |
| MAY | ~してもよい | 任意 |
例えば、NISTの文書で「SHALL」と書かれている場合、推奨の意味合いだけではなく守ることが前提の要件を意味します。一方で「SHOULD」は推奨事項であり、合理的な理由があれば別の方法を採用する余地があることを示しています。技術文書を読む際には、こうした表現の違いにも注目すると、ガイドラインが「必須なのか」「推奨なのか」を正しく理解できます。
※ NIST Special Publication 800-63 Revision 3 Digital Identity Guidelines
Revision 4(2025)の公開:従来ルールは非推奨から禁止へ
最新のRevision 4(DraftおよびFinal)では、安全に運用できる仕組みを重視するという考え方がさらに強化されています。Revision 3では、複雑性ルールや定期変更について「推奨しない」(SHOULD NOT)という表現でしたが、Revision 4ではこれらを禁止(SHALL NOT)という、より明確な方針が示されました。
具体的には次のような考え方が採用されています(一部列挙)。
- 大文字・小文字・記号などの文字種ルールの強制は禁止(SHALL NOT)
- パスワードの定期変更の強制は禁止(SHALL NOT)
ただし侵害された確証がある場合には変更する(SHALL) - 単要素認証の場合、最低15文字以上の長いパスワードが必須(SHALL)
多要素認証の一要素として使用する場合でも最低8文字以上が必須(SHALL) - よく使用されるパスワード、推測されやすいパスワード、漏えいしたパスワードを含むブロックリストとの照合が必須(SHALL)
さらに、認証技術そのものの進化も反映されています。近年はフィッシング攻撃によるアカウント乗っ取りが大きな問題となっており、パスワードだけでは十分に防御できないケースが増えています。そのためRevision 4では、多要素認証やフィッシング耐性のある認証方式の重要性がより強調されています。
また、FIDOなどの技術を利用したパスキー(Passkeys)と呼ばれる新しい認証方式も考慮されるようになりました。これらはパスワードを使わずにログインできる仕組みであり、フィッシングやパスワード漏えいに強いという特徴があります。
このようにRevision 4は、単にパスワードポリシーを変更しただけではなく、パスワード中心の認証から、より安全な認証方式へ移行する方向性を示したガイドラインと言えます。
この流れが示しているのは、セキュリティ設計において重要なのは理論的な強さではなく、人間の行動や運用の現実を踏まえた設計であるということです。現在の認証設計では、パスワードだけに依存するのではなく、多要素認証やパスワードレス認証などを組み合わせた、より現実的で安全な仕組みが求められるようになっています。
※ NIST Special Publication 800-63 Revision 4 Digital Identity Guidelines
さいごに
NISTのガイドラインは、パスワードを「複雑さ」から「実際の安全性」へと考え方を大きく変えてきました。今一度、運用しているパスワードポリシーを見直し、パスワードレス認証の導入も含めた次の一歩を検討してみてはいかがでしょうか。ラックでは、Oktaを活用したパスワードレス認証や多要素認証の導入支援も行っているので、具体的な検討段階にある場合はぜひご相談ください。
タグ
- アーキテクト
- アジャイル開発
- アプリ開発
- インシデントレスポンス
- イベントレポート
- カスタマーストーリー
- カルチャー
- 官民学・業界連携
- 企業市民活動
- クラウド
- クラウドインテグレーション
- クラブ活動
- コーポレート
- 広報・マーケティング
- 攻撃者グループ
- もっと見る +
- 子育て、生活
- サイバー救急センター
- サイバー救急センターレポート
- サイバー攻撃
- サイバー犯罪
- サイバー・グリッド・ジャパン
- サプライチェーンリスク
- システム開発
- 趣味
- 障がい者採用
- 初心者向け
- 白浜シンポジウム
- 情シス向け
- 情報モラル
- 情報漏えい対策
- 人材開発・教育
- 診断30周年
- スレットインテリジェンス
- すごうで
- セキュリティ
- セキュリティ診断
- セキュリティ診断レポート
- 脆弱性
- 脆弱性管理
- ゼロトラスト
- 対談
- ダイバーシティ
- テレワーク
- データベース
- デジタルアイデンティティ
- 働き方改革
- 標的型攻撃
- プラス・セキュリティ人材
- モバイルアプリ
- ライター紹介
- ラックセキュリティアカデミー
- ランサムウェア
- リモートデスクトップ
- 1on1
- AI
- ASM
- CIS Controls
- CODE BLUE
- CTF
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- DevSecOps
- DX
- EC
- EDR
- FalconNest
- IoT
- IR
- JSOC
- JSOC INSIGHT
- LAC Security Insight
- NDR
- OWASP
- SASE
- Tech Crawling
- XDR









