暗証番号をログに吐くとかあり得なさすぎて卒倒した

新人の頃からしばらくやっていた仕事も暗証番号の流れるものだったけどさあ…ログに吐くとかないよなーって。でも勘定系を直接触っていたわけじゃないのでそっちで吐いてたかも知れないけど、少なくとも僕の携わっていた部分ではこのような話は徹底されていたからな。

NTTデータは千数百台ある横浜銀行ATM（富士通製）にそれぞれ蓄積される「解析用ログ」を、NTTデータが運用するサーバーに集約した後、MOディスク（光磁気ディスク）で富士通フロンテックへと渡していた。集約や受け渡しの過程においては解析用ログは暗号化されており、解読は不可能だという
富士通フロンテックは保守管理業務の一環として、ATMの故障時の調査目的などで解析用ログを復号して利用している。容疑者はこの復号後の口座番号・暗証番号を元に偽造カードを作成、不正出金を繰り返していたという。

「対策を打つ前にやられた」、NTTデータが横浜銀行データ不正取得事件について釈明 | 日経 xTECH（クロステック）

受け渡しで暗号化してたとかは関係ない（当たり前過ぎる）。復号できる立場の犯行である以上、本題ではない。

NTTデータは内部犯行は防ぎ得ないという見解のようだが、そもそも暗証番号をログに吐く事自体が間違っているのではないか。

今思えばそうだったかもしれない。だが、「ATMで正しい暗証番号を入力しているはずなのに出金できない」という利用者からの問い合わせは少なくない。暗証番号を間違えただけなのか、ATMが故障しているのか、何らかのシステム障害が発生しているのかなどを切り分ける必要がある。

「対策を打つ前にやられた」、NTTデータが横浜銀行データ不正取得事件について釈明 | 日経 xTECH（クロステック）

これはわりとひどい言い訳で、問い合わせに対して「暗証番号を間違えただけなのか」という切り分けを解析用ログを外部に持ちだしてそこで解析しなければわからないって時点でシステムとして終わっている。「暗証番号を間違えた」という事実がシステムの機能としてわからないのはダメだし、「暗証番号があっているか」をログをみて確認する時点でもっとダメ（少なくとも調査者には暗証番号がわかってしまう）だし、お客さんが正しいと思っている暗証番号を聞き出さないと結局は真実がわからないので結局全然ダメ。仮に「暗証番号を間違えたエラー」がバグで誤出力されるとしたらそれは銀行システムとしては「コンソールにコーヒーこぼしたからタオルで拭こうとしたら間違えて世界終了核ミサイル発射ボタン押しちゃった。てへ♪」レベルにダメなシステムなのでそれを想定してはいけないだろう。
というわけで、暗証番号が必要だ、というのはどう評価しても言い訳にすぎない。

内部犯行は避けられない、というのはある程度しかたがないことではあるが、生電文が普通には見れない、暗証番号も原則見れないという環境にしておくだけでも相当犯行のハードルが高くなる。事務手続きにおいてもそういった努力はされていて、口座の申込書を見ると複数枚綴りのうち暗証番号が特定の紙にしか書かれない（裏写りしないガードもある）ようになっているのは、申込時点で手続きフローの中で口座番号と暗証番号を作業者が直接紐づけることがないようにするための仕組み。そういった形での努力をあっさり無にするような「ログに暗証番号を載せる」という行為は前回発覚した「地銀共同センター」での不正に比べてもまだお粗末な事件であると言えるのではないか。

追記

少しずつブコメ増えてきたので続き置いときますね　つ4桁数字の暗証番号という負の遺産 - novtan別館