情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

令和6年春期試験 午後試験【問4】についての投稿を受け付けるスレッドです。

マネジメント系の問題かな？と思って問4見たら、セキュアプログラミングでしたね。びっくり。

私もやられました  4を選ぼうと思ったら、プログラミングなんて。。。(笑)

自分も問題用紙だけ見て4に丸つけたけど、問題文みて速攻丸消しましたw

3問ぐらい解いてちゃんと見たらセキュアプログラミングで途中から問1に変更しました。先入観で時間無駄にした〜

問4を選択した人は少ない感じですかね。

プログラミングと言っても、何かの攻撃の対処というよりかは、業務アプリケーションにおける、要求仕様にマッチしているかという問いだったので、問3ではなく問4選択しました。でも、自信なし…。

まったく自信なく、当てずっぽうもありますが、私の解答です。
採点・指摘・コメントいただけると嬉しいです！

1.
(1)イ
(2)personal
(3)4
2.
(1)7
(2)NosuchAlgorithmException
(3)
システム運用者
  データ：氏名、住所、電話番号
  場所：ウ
システム開発者
  データ：氏名、住所、電話番号、メールアドレス
  場所：オ
(4)SHA-2
(5)例外をthrowして以降の処理を中断する
(6)finally
(7)イ

全体的に自信ないです。とりあえず全部埋めたというレベルです。

1.
(1)ア
(2)develop（personalだと権限多いかなと思った）
(3)4
2.
(1)5
(2)NoSuchAlgorithmException
(3)
システム運用者
  データ：氏名、住所、郵便番号、メールアドレス
  場所：エ
システム開発者
  データ：氏名、住所、郵便番号、メールアドレス
  場所：オ
※ 郵便番号は重要情報の「住所」に含まれるのか迷いました。
(4)SHA-2
(5)
this.userId = null;
this.password = null;
throw e;
(6)finally
(7)ウ

＞(2)develop（personalだと権限多いかなと思った）
私も権限多いかな？と迷ったのですが、developは「開発環境と本番ログサーバ」しかアクセスできないし、、、と思いました。

＞※ 郵便番号は重要情報の「住所」に含まれるのか迷いました。
私も迷いました！でも、「郵便番号」と「住所」は別物と考えました

(1)ア
(2)personal
(3)4
2.
(1)7
(2)NoSuchAlgorithmException
(3)
システム運用者
  データ：氏名、住所、郵便番号、メールアドレス
  場所：エ
システム開発者
  データ：氏名、住所、郵便番号、メールアドレス
  場所：オ
(4)SHA-2
(5)プログラムの停止
(6)finally
(7)ア
最後はソルトが平文で入ってないと複合できないと思いアにしました。

私も上のお二人と似通った回答です。

設問2(3)
コードのSQLが省略されているので、郵便番号以降もセットしてるよね？そうだよね？と不安になりました…。

設問2(5)
スローの綴りをど忘れしてカタカナで書いちゃいました。普段コード補完に頼っているせいですね。

私も郵便番号を迷ったのと、パスワードが平文で保存される可能性があるのでパスワードを入れるか迷いました、パスワードも買いてしまったorz

自分の解答は以下です。finnalyはミスしました。


設問１
（１）ア
（２）personal
（３）4
設問２
（１）d. ５
（２）e. NoSuchAlgorithomException
（３）
    列名
      ・氏名
      ・住所
      ・電話番号
      ・メールアドレス
      ・パスワード
    場所：エ

      ・氏名
      ・住所
      ・電話番号
      ・メールアドレス
      ・パスワード
    場所：オ
（４）f.SHA-256
（５）g. throw new RuntimeException("system error")
（６）h. catch(Exception e)    //このミスした確かにfinnaly
（７）イ、オ

設問2-(7)は イ と迷いましたが、
下線部の前に「レインボーテーブル攻撃を受けたときに攻撃が成立する」とあったので、
複数回ハッシュ化するのかなと思って「ウ」を選びました。
やっぱり復号できないから イ でしょうか？

この投稿は投稿者により削除されました。(2024.04.21 17:31)

設問２の（５）においてそこから例外をthrowするとコンストラクタの宣言にthrowsにしないとコンパイル通らなくないですか？
コードで書くならSystem.exit(1);なのではないでしょうか

>設問２の（５）においてそこから例外をthrowするとコンストラクタの宣言にthrowsにしないとコンパイル通らなくないですか？

確かに。throw e; だとthorwsがないからコンパイルエラーになりますね。
コード補完に頼りすぎていて忘れていた。 orz

(4)はAESと書いたけどSHAかも
  コーディング離れてると忘れますね
(5) throw eかとおもいましたが引っ掛けありそうな感じがして言葉で同じことを記載しました。

(4)はsha2に含まれてるのならええんちゃうんか？
といういみでsha256かsha512でもいいんじゃないかなと

この投稿は投稿者により削除されました。(2024.04.21 18:28)

>>(4)はsha2に含まれてるのならええんちゃうんか？
といういみでsha256かsha512でもいいんじゃないかなと

とおもってjavaの実装例みたらsha2の場合具体的な値かかんとあかんのか？

SHA-256をSHA256と書いてしまった。
finallyをfinalyと書いてしまった。
などは不正解になるんでしょうか？
部分点は貰えるのでしょうか…？

SHA-2の書き方はSHA-2ファミリーにたくさんいるんできちんとしないと実装できないんですね。
業務でjavaやってますが知らなかったですorz

問2 (3), システム運用者のやつですが, ユーザIDも入りますかね..?
ログファイルの権限の話がちょろっと出たのと, 
csvファイルの中にユーザIDが含まれるので特定できてしまう情報になる..と考えました

(4)について

Oracle公式ドキュメントには、Messeageダイジェストのインスタンス生成時に指定できるアルゴリズム名は以下の通りらしいです。

MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512

もしかしたら"SHA-2"だと×？

ChatGPTに訊いてみました。設問1(2), 設問2(3)を含めて自分の回答とはいくつも相違がありますが、なんだか人間が要らなそうな立派な答えが返ってきました。

Q1-1. 【データ連携機能のセキュリティレビュー】において、[a]には「システム運用担当者」が適切であることが示唆されています。これは、batchappuserが本番バッチサーバへのアクセス権を持っており、CSVファイルに重要情報が含まれるため、不正アクセスのリスクがあります。バッチ処理の運用を担当するため、[a]はシステム運用担当者になります。

   解答: ア

Q1-2. 【データ連携機能のセキュリティレビュー】で指摘された問題に対処するために、batchappuserの所属グループを変更する提案がありました。batchappuserに対してより制限的なグループへの変更が求められており、表3において「personal」グループが本番環境へのアクセス権を持ち、重要情報にアクセスする可能性があるため、このグループに変更することでセキュリティが向上します。

   解答: personal

Q1-3. CSVファイルの暗号化と復号を行うプログラムに関しては、暗号化を行うのは注文データのCSV出力を行うバッチ処理であるため、表4に基づきNo.3の「注文データ CSV 出力バッチ処理」で暗号化を追加し、受け取ったCSVファイルを読み込んでDBを更新するプログラムはNo.4の「注文データ CSV 取込みバッチ処理」で復号処理を追加することが適切です。

   解答: 4

Q2-1 本文中の[d]で指摘されている行は、例外が発生した場合にパスワードが平文で保存される可能性がある行です。この場合、ハッシュ化処理が失敗した場合を想定しているため、ハッシュ関数のインスタンス化を試みる行（5行目）が該当します。

   解答: 5

Q2-2 本文中の[e]は、例外が発生すると述べられています。図3の8行目ではNoSuchAlgorithmExceptionがキャッチされています。

   解答: NoSuchAlgorithmException

Q2-3a システム運用担当者がアクセスできてしまう情報は、図3の22行目と23,24行目にて出力されているユーザーマスターテーブルの全ての列が含まれます（ユーザーOID、ユーザーID、パスワード、氏名、郵便番号、住所、電話番号、メールアドレス、作成日時、更新日時）。この情報が出力される場所は、開発ログサーバのAPログを保存したテキストファイルです。

   解答: ア

Q2-3b システム開発者がアクセスできてしまう情報も、図3の22行目と23,24行目にて出力されているユーザーマスターテーブルの全ての列が含まれます（ユーザーOID、ユーザーID、パスワード、氏名、郵便番号、住所、電話番号、メールアドレス、作成日時、更新日時）。この情報が出力される場所も、開発ログサーバのAPログを保存したテキストファイルです。

   解答: ア

Q2-4 図4中の[f]には、以前よりセキュアなハッシュ関数名が入る必要があります。CRYPTREC 暗号リスト（令和5年3月30日版）の推奨されるセキュアなハッシュ関数の一例として「SHA-256」が適切です。

   解答: SHA-256

Q2-5 図4中の[g]で例外が回復不能な場合、適切な処理はアプリケーションが安全に停止または異常終了することを保証する処理です。例えば「throw new RuntimeException("Unable to hash password", e);」とすることで、システムの安全を確保します。

   解答: throw new RuntimeException("Unable to hash password", e);

Q2-6 図4中の[h]には、PreparedStatementを適切にクローズする処理が必要です。例外が発生した後にリソースを正確に解放するためのコードは以下のように記述します。

   解答: finally

Q2-7 図4の6,7行目のレインボーテーブル攻撃に対する脆弱性を解決するためには、ソルトを使用したハッシュ化が必要です。適切な修正コードは、「イ」です。
   解答: イ

＞opus25bさん(No.24)  
重要情報に入っていないので、違います。

「パスワード」が抜けている解答が多いですね。
ハッシュ化されているからセーフとでも思ったのでしょうか。
「パスワード」は重要情報に該当し、重要情報にはアクセスしてはならないとあります。
素直に読めば、「パスワード」はアクセスしてはならないと読めますよね？
百歩譲って、ハッシュ化されていればセーフだとしても、
修正前のプログラムに対する指摘事項なので、
パスワードがハッシュ化されていない可能性があることも考慮すると、
やはりアクセスしてはならないとしか読めないです。

全て書け系は完答で点数が得られます。
この問題は４点✕２から６点✕２までの可能性があり、
「パスワード」が抜けた方々は、８点から１２点までの失点です。
不合格の大きな一歩を踏み出したと言えるでしょう。

>>もしかしたら"SHA-2"だと×？

認識の通りjavaの仕様的にもoracleリファレンス的にも具体的にsha-256だったりsha-512って書かないとプログラムが認識しないとおもうから×かもしれないね・・・

CRYPTRECの方にも、SHA-256、SHA-384、SHA-512と個別に書いてありますしねぇ

設問2の(3)のパスワードについてはいくらでも解釈可能なな気がしていて正解が思いっきりバラけそうですね。なんとなくですが部分点も入る気がします。。。

自分の解答は以下です。


設問1

（1）ア
（2）personal
（3）4

設問2

（1）5
（2）NoSuchAlgorithmException
（3）
◆システム運用担当者
データ：パスワード、氏名、住所、電話番号、メールアドレス
場  所：エ


◆システム開発者
データ：パスワード、氏名、住所、電話番号、メールアドレス
場  所：ア

（4）SHA-2
（5）プログラムを異常終了する
（6）finally
（7）ア

※「ユーザーマスターテーブルの定義に変更はないものとする。」とあるので、
  ハッシュ化する"前"のソルトをパスワードと同じ項目に格納される「ア」か「エ」に絞られる。
  「エ」はパスワードのみでハッシュ化しており、
  テーブル格納後の33バイト以降の文字列が修正前と変化ないため修正後として不適当。
  よって答えは「ア」と思われる。


【感想】
設問2(3)は5行目で例外が発生した場合はthis.passwordが平文のままになるので記述したのですが、ここでは例外考えなくて良かったのかも？（設問2(1)ですでに触れてるので、、、

設問2(4)はみなさん言われてるようにSHA-2ではなく、SHA-256,SHA-512 のように具体的に書かないとダメそうですね...

大混乱の中、何を思ったか当て勘でAES-256って書いたわ

設問2(3)の個人情報の件ですが、たしか郵便番号は単体だと個人情報にならないけれど氏名と合わせると個人特定可能として扱われたはずなので、今回は対象になると思います。
うろ覚えですが、、、

「重要情報にアクセスしてはいけない」が仕様で、郵便番号は重要情報に該当する項目に入っていなかったので外しました

設問2の(3)の、システム運用担当者の方にパスワードは書かなくていいかなと。
ハッシュ計算のプログラムをデバッグできるわけではないので。

逆に、システム開発者の方では必要なのかな。
コード知ってればログから引っ張ってきてリバースすればいいし。

＞設問2の(3)の、システム運用担当者の方にパスワードは書かなくていいかなと。
ハッシュ計算のプログラムをデバッグできるわけではないので。

図2の24行目で log.debug("InsertData:" + this.toString()); 
としているので、運用担当者が閲覧可能なログにパスワード（ハッシュ値）が含まれるのかな？と思ったので私はパスワードも書きました。

（log.debugでのログにthis.toString()を使用していることから、toString()が適切にオーバーライドされている前提だと判断しました。）

設問2の(7)はアですよね。
自分もISKさんと同じ選定理由です。

ハッシュ化した値を“復号する“と書いてる方がこのスレに何名か居るのが気になりますね…

設問2の(7)は
※「ユーザーマスターテーブルの定義に変更はないものとする。」とあるので、ハッシュ化したパスワードに32バイトのsaltを連結してDBに保存しようとすると、文字数オーバーでエラーになるのかと思い、イにしました。
同じハッシュ関数でハッシュ化するなら、パスワード列のデータ型は固定長かなというのは考えすぎでしょうか。

この投稿は投稿者により削除されました。(2024.04.22 18:05)

この投稿は投稿者により削除されました。(2024.04.22 18:16)

元のパスワードにソルトを足してハッシュ化するのだから、パスワードに対する桁長は変わらないけど、
そういやそのソルトはどこにしまっとくのか？（ログインの処理に触れないから、今回は気にしなくていいの？）ということは思いました。
テーブル列の桁長が書いていないから、sqlite3のTEXT型みたいな入るだけ入るよみたいなものを想像するのがよいように思います

＞元のパスワードにソルトを足してハッシュ化するのだから、桁長は変わらんでしょうね。

アの選択肢のように、ハッシュ化後のパスワードに平文のソルトを付け足すと桁長が変わってしまうことに言及しておりました。

どう解釈しようが結局はIPAが想定していたものと違っていれば間違いなので考えるのはやめにします。

＞「ユーザーマスターテーブルの定義に変更はないものとする。」

問題内にパスワードカラムの文字長が定義されていないので、この注釈は「salt用のカラムを追加しない」という意図に読めます。

とすると、saltは毎回ランダム生成されるものなのでパスワードにくっ付けて保持することを想定した問題なんだろうな、と思いました。

「ユーザマスターテーブルの定義に変更はない」は、
テーブル項目として「ソルト」は追加しないよ？って言っているように解釈しました。
addUserで毎回変更されるsaltを平文で保存していないと一致確認の処理(復号)ができないので、平文のまま保存するアorエで絞り込みました。
ソルト処理のセオリーとしては、ソルト+パス平文でハッシュ値をとるなので、アかなと。
それにしてもsaltのスコープどこやねんとはツッコミいれたくなりましたが。

この投稿は投稿者により削除されました。(2024.04.22 18:31)

そうなると、ログインのときは入力パスワードをハッシュにして前方一致みたいにするんですかね？

>そうなると、ログインのときは入力パスワードをハッシュにして前方一致みたいにするんですかね？

横からで失礼します。
ログイン処理を想定するとしたら以下のような感じになるのではと思います。

①ユーザマスターテーブルからパスワード列の値を取得

②①で取得した値の先頭から32バイト分と、
利用者が入力したパスワードを結合した上でハッシュ化

③①で取得した値の33バイト目以降の文字列と②を比較、一致していればログイン成功

>ISKさん(No.48) 
ありがとうございます。どこからソルトを取るかの問題ではあるのですが、ソルトはせめて別の列で管理しときたいですね。

>アの選択肢のように、ハッシュ化後のパスワードに平文のソルトを付け足すと桁長が変わってしまうことに言及しておりました。

元々はSHA-1(20バイト)だったものをSHA-256(32バイト)などに変更するので、桁長はアルゴリズムの変更の時点ですでに変わっています。
アルゴリズムの変更時に桁長の制限はなかったので、パスワード列の桁長には余裕があるという解釈でいいと思います。

設問2の(2)はNoSuchAlgorithmExceptionがどういう例外か答えろってことかなと思い「アルゴリズム参照での例外」と書いたのですが、流石に×でしょうか。

また、設問2の(1)は5と7の２つの意見がありますが、結局どちらが正しいのでしょう？有識者の方居ませんでしょうか？

元々はSHA-1(20バイト)だったものをSHA-256(32バイト)などに変更したときに、32バイトを上限に設定してたら、アだと桁数オーバー
ユーザー定義は、salt追加前に上限設定しているので、そこから変えてないという意味では矛盾がない
桁数オーバーのリスクがないとは言い切れないので、saltがないと対応できないなら、全選択肢がダメ

問題として不適切な要素はあるクソ問題

>また、設問2の(1)は5と7の２つの意見がありますが、結局どちらが正しいのでしょう？有識者の方居ませんでしょうか？

NoSuchAlgorithmException例外が発生するのはMessageDigestクラスのgetInstanceメソッドなので、5行目が正しいと思います。

>また、設問2の(1)は5と7の２つの意見がありますが、結局どちらが正しいのでしょう？有識者の方居ませんでしょうか？

NoSuchAlgorithmExceptionの発生は指定した暗号化アルゴリズムがない時に行われるので
7と書きましたが５行目が正解だと思います。

実際に2-4の問題でSHA-2でやったらどうなるのか兼ねて
MessageDiggest.getInstance("SHA-2");とやったらそこでNoSuchAlgorithmExceptionが発生しました。

図4（SHA256でハッシュ化するように変更したコード）に対してsaltの利用を追加するよう修正するって内容でしたので、
①ユーザーマスターテーブルのパスワード列はSHA256に対応した形に定義を変更済み。
② saltはユーザーマスターテーブルとは別のテーブルに保存する。
といった前提条件を脳内で設定してしまっていました。。。
本番中はやけに妄想が働いてしまってましたが、冷静に考えると「ア」が正しそうですね。

>ハッシュ化した値を“復号する“と書いてる方がこのスレに何名か居るのが気になりますね…

自分も書いていましたがパスワードの検証のことです

設問1
（1）ア
（2）develop
（3）10

設問2
（1）8
（2）NoSuchAlgorithmException
（3）
◆システム運用担当者
データ：氏名、住所、電話番号、メールアドレス
場  所：エ

◆システム開発者
データ：氏名、住所、電話番号、メールアドレス
場  所：オ

（4）知らん
（5）errorを通知して処理を終了、後続処理を実行しない
（6）catch()無理
（7）ア

おいくら頂ける？

この投稿は投稿者により削除されました。(2024.04.23 08:32)

郵便番号✖️
電話番号○

この投稿は投稿者により削除されました。(2024.04.24 20:19)

個人的に一番無難だと思う答え
住所が抜けてて草
パスワード入れてるのは好感が持てる

パスワード抜けてる答案多くてビビる
ハッシュ化有無関係ねーから

しかも今回はハッシュ化できず生パスワード入れられるリスクもあるのにアクセスさせて言い訳がねえ

結局パスワードってハッシュ化自体はされるじゃなかったっけ
ハッシュ化されてるされてないに関係なくパスワードにアクセスできること自体が問題って趣旨だと思うが

まあパスワード抜いたけど俺は

大問4の話だけど、確かに要件のユーザと役割には重要情報にはアクセスしてはならないとあるけど、ログ保存部分は”どこ”に”どんな”形式で”どの”パーッミッションで保存するかしか書いてないから重要情報保存するなってのは読み取れないね。そもそも問題が重要情報にアクセスできてしまうだからログには重要情報が載ってないとだめ。
あというとプログラムの記述的に
  APログ・デバッグログ共に
  SQL： + sql ；SQL:のあとに14,15行目のSQL内容をそのまま出力
だから全部の情報が出力されて保存されることになる。でいいよね。

＞だから全部の情報が出力されて保存されることになる。でいいよね。

合ってる。
だからハッシュ化されたパスワード含め、重要情報に指定されてるカラム名を書き出せばOK

2-5、「return e」とかいうガバガバコード書いたんだけど部分点貰えねえかな

2-5については、コンパイルエラーが発生しないことは前提として、
フェイルセーフの考え方として、強制終了
フェイルソフトの考え方としては、変数null化もありかなと個人的に思う。

暇だし解説していこうかなー

6.はFinallyではなく、

catch(OutOfMemoryException e)

ではないでしょうか。メモリリークの可能性と言ってるので。

> ペンネさん(No.68)

6 は finally が妥当ですね。

仮に「catch(OutOfMemoryException e)」とすると、正常時に psObj.close が明示的に呼ばれないので微妙かなと思います。

2-5、「this.password = ""」で空文字入れちゃったんですけど部分点もらえますかね...笑

> jataroさん(No.70) 

基本的には「プログラムを異常終了 (実行時例外を投げる) 」が妥当な回答なのかなと思います。

もし、this.password = "" (パスワードを空文字列) とした場合、全てのユーザがパスワード無しで登録しているというようなことになってしまうので、ダメそうな気がします。

例えば、

- ユーザが自分の設定したパスワードでログインできない
- 誰でもパスワード無しでログインできる

というバグが埋め込まれてしまいます。

> scさん(No.70) 

さすがに厳しいですよね笑

解説ありがとうございます。

パスワード無しだと、別のエラーで結果的に処理落ちしそうだけどね

> おにきさん(No.73) 

問題に記載されているソースコードを読めばわかりますが、別のエラーにはなりません。

4は「SHA256」と解答してしまったのですが、実際のコードでハイフンなしで指定した場合はエラーになりますか？

5は「利用者の登録を行う一連の処理を強制的に終了させる」と解答しましたが、正答または部分点は貰えそうでしょうか？

> しょうゆさん(No.75) 

Java のプログラミングにはあまり詳しく無いのですが、リファレンスを見る限りSHA256 ではエラーになると思われます。また、一般的にハイフンを省略する形式をドキュメントで見ることは無いので回答としては不十分と思われます。

docs.oracle.com/javase/jp/17//docs/specs/security/standard-names.html#messagedigest-algorithms

「利用者の登録を行う一連の処理を強制的に終了させる」であれば、部分点がもらえる可能性はありそうですね。(強制的に終了というのはキーワードな気がします)

>scさん
ご回答ありがとうございます。

普段業務で使うC#の関数だとSHA256表記だったので、それに引っ張られてしまいました。
JAVAのプログラミングでエラーになるなら、意図を汲み取って部分点とかも無さそうですね。

> しょうゆさん(No.77) 

なるほど、C# 詳しくなくてすみません。確かに調べてみると SHA256 ですね。(C# では、文字列ではなくクラス指定なので存在しない値を指定した場合、コンパイルエラーになりますね。モダンな言語はだいたいこういう傾向にありますね)

learn.microsoft.com/ja-jp/dotnet/api/system.security.cryptography.sha256?view=net-7.0

僕が問題作成者で、そういう主張があれば正解にします。(この試験では難しいかもしれませんが・・・)

>scさん
いえ、ご丁寧にありがとうございます。

まあでもここ以前に
6を「finally」ではなく「finaly」って書いてしまったり、
7を「イ」にしていたりするので、
いろんな意味で勉強不足でした。笑

> しょうゆさん(No.79) 

(7) は実務の感覚と解くと (イ) にしてしまう気持ちはわかります・・・。
問題をよく読まないといけないですね。

SHA-1
の1を256に変えるだけのはずなのにハイフン漏れも結構多いですね
最初は問4の平均点6割くらいかと思ってましたが5割ないくらいですかね
ちょっと意地が悪い問題多いです

設問7について、パスワードのハッシュ値化について問われているよりsalt値の保管の方法を問われているように感じました。
私はアかイかを迷ったんですが、saltが暗号的な文字でなかったら、salt+passハッシュ値が流出したときにsaltが解読されて、辞書攻撃に用いられそうだったのでイにしました。
教本にはpass+saltをハッシュ化するとしか書いてなかったのですが、salt値の保管や、どのようなsalt値を使うか疑問を持ちました。

実装経験のあるかたに質問です。
・saltはどのような文字を使いますか
・saltはどのように保管しますか

設問としては、このあたりの前提があった上の問題にしてほしかったです。
前提が自由なら、今回の場合だったらsaltにユーザ0IDや郵便番号を使うとかして、イの方法で良さそうではないかなと思いました。

saltの保管場所がパスワードそのものなんですわ
これがいやらしいところ
一応saltと生パスワードでハッシュ化してるので、saltが桁数から解読されて漏れてもいいのでしょう
よりセキュアなのは当然イですが、saltの保管が必要なのでアとせざるを得ないという感じです
レインボー攻撃の対策が分かってるかをとう問題にすればいいのに、と思いますね。

個人的には、勝手に桁数32桁増やす改修するのは、データ定義変更しなくてokな根拠が分かりませんね
難癖に近いですが、saltの作り方がユーザIDを組合せた規則的に異なる文字列なら、別にイでも良いような気もします

この投稿は投稿者により削除されました。(2024.04.24 21:34)

パスワードは必須
なぜなら、ハッシュ化しててもレインボーアタックされるリスクは残る
しかも修正前のコードに対する指摘なので、生パスワードが入れられる可能性もある
生パスワードは当然アクセス禁止でしょ

パスワードは必須ですよ。

＞実装経験のあるかたに質問です。
＞・saltはどのような文字を使いますか
＞・saltはどのように保管しますか

・今回のような乱数
・パスワードが保管されているDBテーブルとは異なるテーブル

普通実装する場合にはsaltをパスワードと一緒に保管するようなことはしないと思います。

ただ、今回は保管場所に関する前提条件が無いんです。なのに、「saltは一度きりしか生成されない」という条件が書いてあります。

これは暗に「ハッシュ化したパスワードはどうやって突合するのか？」を聞いているのではないか、と思いました。

自分が過去見てきたシステムを参考にすると、saltはハッシュ値と並べて保管するのが一般的かと思います
さらに安全性を高めたい場合は、固定値のpepperをDBとは別領域で管理してsalt+pepperでハッシュ化する場合が多いかと

2(4)で「SHA-512」と書いたのは少数派ですかね。。。
暗号強度を深読みしすぎました。
CRYPTREC暗号リストには載ってるので正解となるとは思いますが。

パスワードの記載漏れたら、バツだろうね
2問あるから8点の2倍で16点減点かな
かわいそう

この投稿は投稿者により削除されました。(2024.04.24 18:09)

この投稿は投稿者により削除されました。(2024.04.24 21:29)

itecはパスワードいらないって言ってる悲

>>itecはパスワードいらないって言ってる悲

先頭32倍とソルド＋32バイトのパスワードとソルドのハッシュをDBに保存しているにも関わらず、パスワードが入らないのは腑に落ちないですね。
ハッシュ値が漏れたら、ソルドと一緒に攻撃に利用されるのではないかと思っています。
最後の選択肢はアを選択していますね

パスワードの有無で問4の出来が結構変わってくるからしんどいなぁ
選択問題じゃないから最低でも4点はあるだろうし-8以上かぁ泣きそう悲

パスワードがアクセスしようがないというのであればitecの通りなんだが、今回はアクセスできる上に、平文格納のリスクもあるとのことなので、許容できる要素がないんだが
しかも、レインボーアタックにも言及してて、ハッシュ化すら微妙という論調やぞ

itecの回答見てきましたが、お粗末な答えもあるのであまり信じられないですね…
チェック例外って何のことでしょうか。

やっぱり安心安全のTAC
毎回ITECは的外れ気を衒いすぎ

> チェック例外って何のことでしょうか。
Java では、例外は「チェック例外」と「非チェック例外」に分類されるんですよね。
前者は catch/メソッド宣言に throws 例外名 の実装が必須ですが、後者はなくても良いです。

NoSuchAlgorithmException は一応チェック例外という種類に分類される例外ではあるのだけれど、
この答えでいいのか...という疑問が残ります。。
間違ってはいないけれど、かなり曖昧な答えになってしまうのでグレーな気がします。

しかも、Java では try-catch で catch するチェック例外がメソッド内で絶対に発生しない場合は、コンパイルエラーとして報告されるので、しっかり NoSuchAlgorithmException と回答する必要がある説を推しています。

確かにチェック例外で間違ってはいない
(省略)に発生しうる他のcatch exceptionがあるとも考えられるからね。

NoSuchAlgorithmExceptionも間違ってはいないと思う

全く参考にならんな
まあ今回そもそも解答割れそうではあるが……

修正版のコメントに、「回復不能な例外」と書いてあったので、素直に書いてしまったわ
ソースコードではなく字句でという部分にも惑わされた
まあ字句にコードも含まれるならこのスレの通りかもしれんが

問7について教えて頂いてありがとうございました。
salt+ハッシュで保存するものであると理解するようにします。
「ユーザーマスターテーブルの定義変更はない」という文面をどうとるかですね。
ユーザーマスターテーブルの項目追加はない・・・ア
ユーザーマスターテーブルのパスワード項目の文字長定義に変更はない・・・イ

TACもITECもアだったので、イは望み薄いかなと思いますが、非常に紛らわしい問題なので温情的な措置があったらいいなと夢見ます。

この投稿は投稿者により削除されました。(2024.04.25 17:40)

自分は問1と問4を解きましたが、TACの方が正しそうですね

パスワードが入るか入らないかで合否が決まるぐらいギリギリだけど、まあ多分入るだろうねえ
残念

設問2(3)の重要情報が完答ならパスワードありなしで10点近く変わってくるので、パスワードの有無で合格が決まるといっても過言じゃないですね。。。

itecもtacもちゃんとした企業だから、根拠あっての解答速報だろう。

パスワードの有無は問題作ったところの正式解答例出るまで分からんね。

正規表現もろくに分かってないitecがパスワード無し

こりゃ勝負あったでしょう
TACの通りパスワード有が正解

というか予想配点も5点×2とは限らない
出来が悪い大問ではあるので、
10点×2で処理されるかも

そうするとパスワード抜けの答案は30点以下のスタートとなります

＞10点×2で処理されるかも

そんな訳はないので馬鹿な煽りはやめた方が良いですよ

まあIPAは過去午後2でろくでもない傾斜配点して不合格出したこともあるし多少はね
掲示板でログ見てゾッとしたよ

ただ全部書き出し7点×2(記号は3点×2)
という意味で10点×2なら無いわけではないし、
プログラム苦手な人でも国語の問題だから解けるという意味であり得るかな

パスワード抜けは14点失う可能性はあると思うよ
他の問題で多くの人が間違えてるのって、これ除くともはや最後くらいだし

やたら強気だが、パスワード無しが正答の可能性も全然あるので、弱気の裏返しの煽りはやめましょう

さすがにパスワード抜けだけであれば大幅減点かもしれませんが、部分点は来るのでは？と思います
配点10-14点飛んじゃうと、一気に不合格に傾くレベルなのでそう思いました。

総務省の国民のためのサイバーセキュリティサイトでは

パスワードとは、そのIDを割り振られた本人だけが知る情報で、それを入力することでIDを持つ本人であることを確認するための符号です

と書かれてる。パスワードなしが正解も十分ありえるで

パスワードはアクセスしてはいけません
パスワードは見える状態です(何なら例外的に平文が入ってるかも)

↑これでなぜパスワードが除外できるのか理解できん
最後の問題を正解してる優秀な人たちもパスワード入れてないからビックリ

＞Oyajiさん

（そもそも問題とは関係ないですが）
何故それを読んで尚パスワード無しが正解だと思えるのでしょうか

B部長＞ 今回はレインボーテーブル攻撃を回避するため、パスワードのハッシュのロジックの改修を君にお願いしてもいいかな？
A君  ＞ ユーザマスタテーブルの定義は明記されていませんので、ソルト値はどこに保存するのでしょうか？
B部長＞ ユーザマスタテーブルの定義に変更はないものとする。
A君  ＞ 承知いたしました。

後日、Ａ君は選択肢Ａのように実装を改修し、無事に本番へのリリースがされました。
しかし、リリース後、新規ユーザ登録処理のＤＢのＩＮＳＥＲＴで以下のような大量にエラーが発生しています。
  ERROR 1406 (22001): Data too long for column 'password' at row 1

B部長はＡ君に原因の調査を指示した。
Ａ君は「ユーザマスタテーブルの定義に変更はないものとする」と指示されましたので、
passwordの桁拡張を行っていませんでした。と回答していたようです。

あなたがA君ならどうしますか？

>No.117

まさにこの考えで(7)はイにしましたね。

公式解答はアになるんでしょうけど。

>あなたがA君ならどうしますか？
A君:SHA-1からCRYPTREC政府推奨暗号リスト記載のハッシュ関数に変更した時点で元のデータ長より絶対に長くなるから、定義変更無しの実装は無理ゲー

2-7
ア選択だけど。図2でパスワード列にはハッシュ値を入れるって書いてるじゃないですかー。ソルト値付けてもハッシュ値なんすかーって思った。

＞A君  ＞ ユーザマスタテーブルの定義は明記されていませんので、ソルト値はどこに保存するのでしょうか？
＞B部長＞ ユーザマスタテーブルの定義に変更はないものとする。

B部長が質問に答えられないアスペなので部長を殴る

「ソルトはDB以外のストレージに保管する」っていうのをIPAが強いてきてるならイだけど、普通に考えたらアじゃないの？

だってソルト保管に使えそうなストレージなんて言及されてないし、そもそもパスワード列の桁数についても言及されてない。

＞図2でパスワード列にはハッシュ値を入れるって書いてるじゃないですかー。ソルト値付けてもハッシュ値なんすかーって思った。
今問題読み返してたら下線②の直前に「図2の仕様も修正しろ」って書いてあったわｗ
もしかしたらそのツッコミ用かも

>No.117
>No.118
いやほんとその通り
定義変更なしってのが厳密なようで曖昧

B部長はＡ君に原因の調査を指示した。
Ａ君は「ユーザマスタテーブルの定義に変更はないものとする」と指示されましたので、
passwordの桁拡張を行っていませんでした。と回答していたようです。


↑これでイにしたわ
桁触れられてないから勝手に増える方向持っていくのもセンスないでしょ
saltは別んとこから持ってきてるに一票

俺もイにしたけど、徳丸先生の「ソルト付きハッシュのソルトはどこに保存するのが一般的か」っていうQiitaの記事読んでアの方が正しい気がしてきたわ