メインコンテンツまでスキップ

パスワード管理・失念対応フロー改善案

要旨​

「パスワードを忘れた」と問い合わせた利用者に対し、管理者が保存済みパスワードを参照して伝える運用は、業務上は便利でも、認証の設計としては維持しにくい。NIST SP 800-63B は、検証側がパスワードをオフライン攻撃に耐える形で保存することを求め、OWASP もパスワードは原則としてハッシュ化し、可逆に取り出せる前提を置くべきではないと整理している。12

改善の本質は、管理者が「元の秘密を教える」運用を残すことではなく、管理者はパスワードを見られず、本人確認後に本人が安全に再設定する運用へ変えることにある。失念対応は「照会」ではなく「リセット」を中心に再設計し、保存方式は平文からソルト付きハッシュへ移行するべきである。34

現状フロー（As-Is）​

一般ユーザー
  ↓ 「パスワードを忘れた」
管理者が問い合わせ受付
  ↓
管理者が保存済みパスワードを参照
  ↓
メール・電話・口頭などで通知
  ↓
一般ユーザーが同じパスワードで再ログイン

このフローは、システムまたは管理者が元のパスワードを取り出せることを前提にしている。OWASP のテストガイドでも、アプリケーションが現在のパスワードをメール送信したり画面表示したりする場合、それは平文または復号可能な形式で保存している兆候かもしれないと指摘している。5

なぜ危険か​

1. 平文または可逆保存を前提にしやすい​

NIST SP 800-63B は、検証側がパスワードをソルト付きハッシュで保存することを要求している。OWASP も、パスワードは「ほぼすべてのケースで暗号化ではなくハッシュ化すべき」とし、可逆に元の値を取り出す必要がある設計自体を例外扱いにしている。12

つまり、管理者が元のパスワードを見て伝えるという業務要件を残す限り、保存方式は平文または復号可能な形に引っ張られやすい。これは漏えい時の悪用容易性を上げ、他システムでの使い回し被害も広げやすい。2

2. 人手による失念対応はソーシャルエンジニアリングに弱い​

NIST SP 800-63B は、認証回復を認証全体の弱点になりやすい部分と位置づけており、人手を介する回復にはソーシャルエンジニアリングのリスクがあると明記している。さらに脅威例として、顧客サポート担当者のような内部者が攻撃者と共謀してアカウントへアクセスを与えるケースまで挙げている。46

電話やメールでの伝達は、誤送信、聞き取り、なりすまし問い合わせ、内部不正の影響を受けやすい。元の秘密を人が扱うほど、認証強度ではなく運用者の善意と注意力に依存する面が大きくなる。4

3. 最小権限と監査説明に反する​

NIST の用語集でいう least privilege は、「役割を果たすのに必要な最小限の権限だけを与える」原則である。7 パスワード照会対応のために管理者へ閲覧権限を残す設計は、この原則に逆行しやすい。

加えて、OWASP の Logging Vocabulary Cheat Sheet は、パスワード変更をログに残すべきイベントとして挙げている。8 しかし、元のパスワードを人が見て伝える運用では、「誰が、なぜ、どの経路で秘密を知り、どこまで拡散したか」の説明が難しい。監査で求められるのは、秘密の共有履歴ではなく、リセット操作と本人確認の証跡である。

改善の基本方針​

  • 管理者がパスワードを見て伝える運用は廃止する。
  • 失念時対応は「照会」ではなく「再設定」を中心にする。
  • パスワード保存は平文ではなく、ソルト付きハッシュへ移行する。
  • 失念受付では、登録済みの連絡先や事前に定義した回復手段を使う。
  • リセットや変更の操作履歴を残し、既存セッションの失効や再認証を組み合わせる。3910

目指す業務フロー（To-Be）​

案A：セルフサービス型​

一般ユーザー
  ↓ 「パスワードを忘れた」
失念受付
  ↓
登録済みメール等へ再設定URLまたは回復コードを送信
  ↓
ユーザー本人が新しいパスワードを設定
  ↓
システムがハッシュ化して保存
  ↓
必要に応じて既存セッション失効・再認証

OWASP は、失念受付で一貫した応答を返し、リセット方法はサイドチャネルで通知し、トークンは暗号学的に安全な乱数で生成し、十分な長さを持たせ、単回使用かつ期限付きにすべきとしている。3 NIST SP 800-63B でも、回復コードや回復リンクを登録済みの回復先へ送り、通知を発する設計が整理されている。11

案B：管理者関与型​

一般ユーザー
  ↓ 管理者へ失念問い合わせ
管理者が本人確認を実施
  ↓
管理者は再設定トークン発行または失効処理のみ実施
  ↓
ユーザー本人が新しいパスワードを設定
  ↓
システムがハッシュ化して保存
  ↓
操作履歴を記録し、必要に応じて既存セッション失効

人手を介す場合でも、管理者の役割は「現在のパスワード照会」ではなく「本人確認と再設定起点の付与」に限定すべきである。NIST SP 800-63B は、回復手段として回復コード、回復連絡先、再度の本人確認などを挙げつつ、回復はリスク分析に基づいて設計すべきとしている。11

実装・運用で押さえる論点​

1. 保存方式はソルト付きハッシュへ移行する​

NIST SP 800-63B は、パスワードをソルト付きハッシュで保存し、ソルトやコスト係数も保持して将来の移行に備えることを求めている。1 OWASP は実装上の推奨として、Argon2id を第一候補とし、利用できない場合は scrypt、レガシーでは bcrypt、FIPS 準拠が必要なら PBKDF2 を挙げている。12

ここで重要なのは、「ハッシュ化すると業務ができなくなる」のではなく、元の秘密を取り出して伝える業務を終わらせることが正しい方向だという点である。2

2. リセットはトークン中心で設計する​

公開向けの失念受付画面では、OWASP が推奨するように、存在するアカウントにも存在しないアカウントにも同じメッセージを返し、応答時間も極力そろえるべきである。これはアカウント列挙対策になる。133

再設定用 URL や回復コードは、次の条件を満たすべきである。311

  • 暗号学的に安全な乱数で生成する。
  • 単回使用にする。
  • 短寿命にする。
  • 登録済みの連絡先へ送る。
  • 成功時と回復イベント時に本人へ通知する。

NIST SP 800-63B の issued recovery code では、メール送信時の有効期間は最大 24 時間、音声や SMS は最大 10 分としている。パスワード再設定 URL でも、これを上限の目安として短めに設計するのが妥当だと考える。これは回復コード要件をリセットリンク設計へ援用した実務上の推論である。11

3. 本人確認は「登録済み情報と別経路確認」を優先する​

NIST SP 800-63B は、回復を登録済み回復先、回復コード、再本人確認などで設計している。11 一方で、OWASP はセキュリティ質問をパスワードリセットの唯一の手段にしてはならないと明記している。14

そのため、管理者関与型であっても、社員番号、生年月日、契約番号のような静的属性だけで通すのは避けたい。登録済みメールアドレスへの通知、別経路での折り返し、上長承認、既存の本人確認基盤との照合などを組み合わせ、知識ベースの確認は補助要素に留めるのが安全である。414

4. ログと権限を「秘密の共有」ではなく「操作の証跡」に寄せる​

記録すべきなのは、誰がどのアカウントに対して、いつ、どの理由で、どの方法で本人確認し、どの回復操作を実施したかである。OWASP はパスワード変更をログ対象に挙げており、失敗イベントやロックも同様に記録対象としている。8

同時に、最小権限の原則に基づき、管理者が持つ権限は「リセット起動」「トークン失効」「一時的なロック」などへ限定し、パスワード本文を閲覧できる権限は残さない方がよい。7

5. 変更後は既存セッション失効と再認証を組み合わせる​

OWASP の Forgot Password Cheat Sheet は、パスワード再設定後に既存セッションを失効させることを勧めている。3 Session Management Cheat Sheet でも、パスワード変更のような権限状態の変化ではセッション ID を更新し、旧セッションを破棄すべきとしている。9

さらに Authentication Cheat Sheet は、アカウント回復やパスワードリセットの後は再認証が重要だとしている。10 したがって、高リスク業務では、変更後に MFA 再確認や追加認証を求める設計が望ましい。

「ハッシュ化すると業務ができない」への整理​

この論点は半分正しく、半分誤っている。

ハッシュ化すると、確かに管理者は元のパスワードを利用者へ伝えられない。だが、それは困ることではなく、そうあるべき状態である。OWASP の Password Storage Cheat Sheet が述べるように、パスワードは検証のために保持されるのであって、業務上いつでも読み出せる秘密として保持されるべきではない。2

変えるべきなのはハッシュ方式ではなく、業務フローである。必要なのは「本人だけが新しい秘密を決める」設計への移行であって、「管理者が今まで通り秘密を教えられること」ではない。

移行ステップ案​

Phase 1：緊急対策​

  • 管理者によるパスワード参照・通知運用を停止方針にする。
  • 失念時の案内文を「照会」から「再設定」へ差し替える。
  • 公開向けの失念受付では、列挙につながる応答をやめる。133

Phase 2：システム改修​

  • 保存方式をソルト付きハッシュへ変更する。1
  • 再設定トークンまたは回復コード発行機能を追加する。311
  • 回復・変更・失効の監査ログを追加する。8
  • セッション失効と再認証フローを追加する。910

Phase 3：業務定着​

  • 管理者向け手順書を「照会禁止、リセット中心」に改訂する。
  • 本人確認ルールを明文化する。
  • 例外運用を承認制にし、監査対象へ入れる。

Phase 4：既存データ整理​

  • 既存の平文または可逆保存データを廃止する。
  • 次回ログイン時変更または一括リセットで新方式へ移行する。
  • 旧運用に紐づく権限と画面を棚卸しする。

改善前後比較​

項目改善前改善後
保存方式平文または可逆参照前提ソルト付きハッシュ
管理者の役割現在のパスワード照会・通知本人確認とリセット起動
失念時対応元の秘密を伝える本人が新しい秘密を設定する
主な回復手段電話・メール・口頭登録済み連絡先、回復コード、再設定 URL
内部不正耐性低い最小権限化で改善
監査証跡「秘密を誰が知ったか」が曖昧「誰がどの回復操作をしたか」を記録
セッション安全性再利用しがち失効と再認証を前提化

まとめ​

一言で言えば、変えるべきはパスワードのアルゴリズムだけではない。「管理者が利用者の秘密を知っている業務」から、「秘密は本人しか知らず、忘れたら安全に再設定する業務」へ変えることが本題である。

平文保存の廃止、管理者の閲覧権限廃止、本人確認後の再設定、操作ログ、セッション失効までを一体で設計すれば、漏えいリスク、内部不正リスク、監査リスクは大きく下げられる。1439

参考資料​

Footnotes​

  1. NIST, SP 800-63B, Password Authenticators（Web版, 2025-08-26更新）。検証側はパスワードをオフライン攻撃に耐える形で保存し、ソルト付きハッシュを用いることを要求している。 https://pages.nist.gov/800-63-4/sp800-63b.html ↩ ↩2 ↩3 ↩4 ↩5

  2. OWASP, Password Storage Cheat Sheet。パスワードは原則ハッシュ化すべきであり、可逆に元の値を取り出す前提を避けるべきと説明している。 https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html ↩ ↩2 ↩3 ↩4 ↩5

  3. OWASP, Forgot Password Cheat Sheet。一貫した応答、サイドチャネル通知、乱数トークン、単回使用、期限付き、通知、既存セッション失効などを推奨している。 https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  4. NIST, SP 800-63B, Authenticator Recovery / Account Recovery（Web版, 2025-08-26更新）。人手を介する回復はソーシャルエンジニアリングのリスクを持ち、認証回復は認証全体の弱点になりやすいと整理している。 https://pages.nist.gov/800-63-4/sp800-63b.html ↩ ↩2 ↩3 ↩4 ↩5

  5. OWASP, Web Security Testing Guide v4.1, Testing for Weak Password Change or Reset Functionalities。現在のパスワードがメール送信されたり画面表示されたりする場合、平文または復号可能保存の兆候となり得ると述べている。 https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/04-Authentication_Testing/09-Testing_for_Weak_Password_Change_or_Reset_Functionalities ↩

  6. NIST, SP 800-63B, Table 3 Authenticator Threats（Web版, 2025-08-26更新）。内部脅威の例として、顧客サポート担当者の共謀を挙げている。 https://pages.nist.gov/800-63-4/sp800-63b.html ↩

  7. NIST CSRC Glossary, least privilege。利用者やプロセスの権限は、割り当てられた業務に必要な最小限へ制限すべきという原則。 https://csrc.nist.gov/glossary/term/least_privilege ↩ ↩2

  8. OWASP, Logging Vocabulary Cheat Sheet。パスワード変更や失敗イベント、ロックなどをログ対象として定義している。 https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html ↩ ↩2 ↩3

  9. OWASP, Session Management Cheat Sheet。パスワード変更時などの権限変化ではセッション ID を更新し、旧セッションを破棄すべきとしている。 https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html ↩ ↩2 ↩3 ↩4

  10. OWASP, Authentication Cheat Sheet。アカウント回復やパスワードリセットの後は再認証が重要としている。 https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html ↩ ↩2 ↩3

  11. NIST, SP 800-63B, Account Recovery Methods（Web版, 2025-08-26更新）。回復コード、回復連絡先、再本人確認の方式、通知、回復コードの有効期間上限を定めている。 https://pages.nist.gov/800-63-4/sp800-63b.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  12. OWASP, Password Storage Cheat Sheet。Argon2id を第一候補とし、利用不可時は scrypt、レガシーでは bcrypt、FIPS 準拠では PBKDF2 を挙げている。 https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html ↩

  13. OWASP, Authentication Cheat Sheet。パスワードリカバリでは generic な応答を返し、アカウント列挙を防ぐべきとしている。 https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html ↩ ↩2

  14. OWASP, Forgot Password Cheat Sheet, Security Questions。セキュリティ質問はパスワードリセットの唯一の手段として使うべきではないと整理している。 https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html ↩ ↩2

に最終更新