情報処理安全確保支援士 2011年 秋期 午後1 問02

解答の論理構成

• 【問題文】の表1には
  「ソルトを付加したパスワードの、ハッシュ関数 a によるハッシュ値を表す。」
  と記載されています。
• パスワード保存用のハッシュ関数には、 ① 衝突耐性が高い
  ② 出力長が十分に長い
  ③ 現時点で実用上の脆弱性が公表されていない
  ものを選ぶ必要があります。
• 旧来よく用いられていた「MD5」や「SHA-1」は、衝突攻撃が現実化しており①を満たしません。一方、同族の「SHA-256」は、256bit 出力であり現在も広く推奨されています。
• さらに【問題文】にはソルトを付与する設計が明記されているため、レインボーテーブル攻撃への耐性も考慮されており、ハッシュ関数自体にも高い安全性が求められます。
• 以上より、選択肢の中で要件を満たすのは「SHA-256」に対応する記号「エ」であるため、 a ＝ 「エ」 となります。

誤りやすいポイント

• 「ソルトを付加しているから弱いハッシュでも良い」と誤解し、MD5 や SHA-1 を選んでしまう。
• 「出力長が長いほど計算コストが高いので性能優先で短いものを」と考え、強度より速度を優先してしまう。
• SHA-2 ファミリの複数候補（SHA-224／SHA-256／SHA-384／SHA-512）の数字だけで迷い、根拠のない“最大値”を選んでしまう。

FAQ

解答の論理構成

1. 表1で status は “0：ログイン可能　1：ロックアウト状態　2：サスペンド状態” と定義されています。ログインを続行できるのは “ログイン可能” のときだけなので、判定②では「statusの値が0」を確認します。
2. “ロックアウト状態は、60分以上経過した後の最初のログイン時に解除される” という図1の要件から、ロックアウト中(status＝1)であった場合は lockout_t と現在時刻の差が60分以上かどうかを調べる必要があります。したがって判定④は「lockout_tの値から60分以上経過している」になります。
3. パスワード誤り時には fails を1加算し、5回連続で誤るとロックアウトに移行します。加算後に fails が4以下であればまだロックアウトさせずに再試行させるので、判定⑥は「failsの値が4以下」です。
4. 仮パスワード状態(temppass＝1)でログインした場合は強制的にパスワード変更ページへ遷移させる仕様です。そのため、通常のログイン成功か強制変更かを分ける判定⑦では temppass が0（仮パスワードではない）かどうかを確認します。

誤りやすいポイント

• status は「ログイン可能＝0」を見落としがちで、つい “2” と答えてしまうケースがあります。
• fails のカウントは “加算後” に判定される点に注意が必要です。加算前と勘違いすると誤答の原因になります。
• ロックアウト解除判定は “60分以上経過＋最初のログイン” という二つの条件があるため、時間だけで解除されると早合点しやすいです。
• 仮パスワード判定では password ではなく temppass を使う点、そして 0/1 の意味を取り違えるミスが多発します。

FAQ

解答の論理構成

1. サスペンド状態の設定方法
   • 問題文には「バッチ処理は、毎日00:00に実行し、現在時刻がlastlogin_tの値から90日以上経過した全てのUIDに対して、表2の設定変更（e）に示す各属性値を設定する。」とあります。
   • 表2の設定変更（e）では status に “2” を設定し、これがサスペンド状態であることが読み取れます。
2. サスペンド解除が許可されている主体
   • 「利用責任者は、ヘルプデスクに対して、UIDの新規登録の他、UIDの削除、パスワード初期化、サスペンド解除を申請できる。」とあり、解除はヘルプデスク経由で実施することが前提です。
3. 設計案が行うパスワード初期化処理
   • 図4の手順(iii)では「UIDの各属性に対して、表2の設定変更bに示す値を設定する。」と記述されています。
   • 表2の設定変更bは status に “0” を設定する仕様です。
4. 要件違反が発生する流れ
   • サスペンド状態（status＝2）のUIDが自力で手順(i)～(v)を実行すると、手順(iii)で status が “0” へ上書きされます。
   • その結果、本来ヘルプデスクだけが行えるはずのサスペンド解除が、利用者自身の操作で行えてしまいます。
5. よって、図1のセキュリティ要件「サスペンド解除は利用者自身では行えない」という条件を満たさなくなるため、指摘1の内容として「サスペンド状態のUIDに対するパスワード初期化によって利用者がサスペンドを解除できる。」が成立します。

誤りやすいポイント

• サスペンド状態とロックアウト状態を混同し、「status＝1」か「status＝2」かを取り違える。
• 表2の「設定変更b」が status＝0 を設定することを見落とし、パスワード初期化が状態を解除しないと誤解する。
• 「利用責任者→ヘルプデスク→解除」という手続上の制約が機能追加後も維持されるかを確認し忘れる。

FAQ

解答の論理構成

1. 図1のセキュリティ要件には「（カ）90日間ログインに成功していないUIDは、ログイン不可能になる。このUIDの状態をサスペンド状態と呼ぶ。サスペンド状態は、契約企業の利用責任者からのサスペンド解除申請によってだけ解除でき、利用者自身では解除できないようにする。」とあります。
2. 表2の「設定変更b」はパスワード初期化時に status の値を 0 にします。
3. 図4の設計案では、(iii) でサスペンド状態かどうかを確認せずに表2の設定変更bを適用しています。結果として status が 2 → 0 に変わり、利用者自身でサスペンド解除が起こり得ます。
4. これは前掲の要件「利用者自身では解除できないようにする」と矛盾します。
5. よって、「status の値が 2 の UID にはパスワード初期化を実行しない」という修正で要件不一致を防げます。

誤りやすいポイント

• 「ロックアウト状態（status＝1）はパスワード初期化で解除してよい」とあるため、サスペンド状態（status＝2）も同じ扱いと誤解しがちです。図1の（オ）と（カ）は別の状態です。
• 表2の status 列だけを見て、「常に 0 に更新すれば良い」と短絡すると要件違反になります。
• サスペンド解除は「利用責任者の申請のみ」という運用ルール（図2‐5.）も見落とされがちです。

FAQ

解答の論理構成

1. 図2の運用手順③では
   「設定した仮パスワードは、ヘルプデスク担当者が利用責任者に電話し、読み上げて通知する。」
   とあり、ヘルプデスク担当者が仮パスワードを把握します。
2. 一方、図4の手順(iii)では
   「プログラムが仮パスワードを発行し、ブラウザに表示する。」
   とあり、仮パスワードは利用者のブラウザにのみ提示され、ヘルプデスク担当者は介在しません。
3. したがって、図1のセキュリティ要件（エ）が求める強制パスワード変更は、ヘルプデスクが仮パスワードを知る旧方式を前提にした措置であり、新機能では不要と判断されました。
4. 以上より「仮パスワードを知っているのが利用者だけであるから」という理由が導かれます。

誤りやすいポイント

• 図1（エ）の「強制パスワード変更」を形式的に残す理由を誤解し、ヘルプデスクの関与有無を見落とす。
• 図4(iii)の「ブラウザに表示」をメール送信と混同し、第三者の閲覧可能性を誤判定する。
• 図2③の電話通知を「安全」と評価し過ぎて、担当者が内容を把握している事実を軽視する。

FAQ

解答の論理構成

1. 攻撃対象は「図4」で追加されたパスワード初期化機能です。
   − 「（ii）入力されたUID名が存在する場合は、プログラムがパスワード取得ページのURL…を発行し、利用者にメールで通知する」と記載されています。
2. 取得ページURLさえ先に押さえれば、誰でも「（iii）…プログラムが仮パスワードを発行し、ブラウザに表示する」段階へ進めます。
3. URLはメールで配布されるだけで、本人確認や追加認証はありません。
4. よってメールを途中で傍受・盗聴できる攻撃者は、正規利用者より先に該当URLへアクセスして仮パスワードを取得できます。
5. 以上から、設問が求める「不正に仮パスワードを取得する手口」は、取得ページURLを含むメールの盗聴→早期アクセスという流れになります。

誤りやすいポイント

• 取得ページURLが「十分に長いランダムな文字列」であることから安全と思い込み、配送経路の盗聴リスクを見落とす。
• 「（v）一度アクセスされた取得ページURLは無効」という仕様だけを根拠に、先取りアクセスの可能性を軽視する。
• SSL通信の言及はブラウザ‐サーバ間のみであり、メール配送経路を保護していない点を混同する。

FAQ