岩井コスモ証券のネット取引システムで認証トラブル、解決法は「パスワードの後ろにスペースを入力する」 62
ストーリー by hylom
どうして金融系のシステムはこうなるのか 部門より
どうして金融系のシステムはこうなるのか 部門より
岩井コスモ証券のネット取引システムで、3月2日よりユーザーがパスワードを入力してもログインできないという障害が発生していたようだ（読売新聞）。
3月5日時点では解決済みのようだが、当初は解決方法として「パスワードが6～9桁のユーザーはパスワードの後ろにスペースを入力して10桁にする」ことが提示されていたという（岩井コスモ証券のお知らせページのGoogleキャッシュ）。
なぜ解決できた？ (スコア:1)
10桁に満たないパスワードを勝手にスペースで埋めて登録してたんですよね．
あっちが持ってるデータは，10桁に埋められたものから生成されたものですよね．
それを，スペース埋めなくてもいいようにしたってことは，もしかして例の生パスワードを保存してるんですってやつ？
と思ったけど，手動でスペースを入力してたのを，あっちで勝手にスペースを埋めるようにしただけかな．
Re:なぜ解決できた？ (スコア:3, 参考になる)
新システム発注時にパスワード長10文字は有っても、「半角スペースで埋めて」という仕様が要求仕様書に無くてやっちまった感がありますね。
で、テスト環境だと誤った仕様のみだから問題なかったと。
受け入れ試験時に旧システムのテスト環境を構築してパスワードのMin/Mid/Maxの境界チェックしなかった代償は高い。
流れを見る限り生パス保存だったのでアカウントロック解除と同時にDBを変換した。
もしくはハッシュ仕様なら
3/2：障害でスペース埋め仕様発覚
3/3：スペース埋めへ仕様変更(ただし、新システムで生成したハッシュへの対応出来ず)
3/4：スペース埋めないでハッシュ生成して比較、失敗したらスペース埋めてハッシュ生成して比較みたいなロジックに変更
といった感じでしょうか？
ログイン画面のお知らせ [iwaicosmo.co.jp]が修羅場を妄想させられて他人ごとながら胃が痛い。
(以下抜粋)
Re:なぜ解決できた？ (スコア:1)
> あっちが持ってるデータは，10桁に埋められたものから生成されたもの
平文じゃなくても、ハッシュ化処理を10文字固定でやってるとか？
Re:なぜ解決できた？ (スコア:1)
10文字より長いパスワードを使っていると、１１文字目以降は実はデタラメでもOK、とかだと笑える。
Re:なぜ解決できた？ (スコア:2)
10文字より長いパスワードを登録すると、勝手に10文字に切ってから登録するシステムがあったことを思い出した。
Re:なぜ解決できた？ (スコア:1)
Jetstarが今まさにそれだよ...いくら言ってもなおしてくれない
Re: (スコア:0)
そもそもパスワードの文字数の上限って、なんのためにあるんだろう。
異常なほど長いパスワードで通信量を逼迫させる馬鹿対策としても、1024文字くらいはOKにすればいいのに。
どうせ俺はパスワード覚える気は無いので、システムが受け入れる最長文字数のパスワードをランダムに生成して使ってるが。
Re:なぜ解決できた？ (スコア:2)
ネットで送信されてサーバーが解釈するデータである以上、上限値は必要でしょう。
仮に10億文字（1GB）のパスワードとか送られたらって考えればわかります。
ネットワークのリソースもhash化のための負荷も相当になります。
要するに正規のパスワード認証を繰り返すだけで攻撃が成立してしまいます。
Re: (スコア:0)
「なんで上限が必用？」なんて言ってる奴は、たぶんプログラミングしたこと無い人。
パスワードに限らず、何を作る場合でも上限は必用。
無限長なんてものを認めた時点で、プログラムもデバッグも必用とするリソースも、
そしてかかる工数と費用も桁違いに増える。動作保証も出来なくなる。
だからよほどのバカじゃ無きゃそんなことはしない
＃自動車の乗員しかり、トラックの積載量しかり。無限大などありえない。
Re: (スコア:0)
んー…
・ハッシュ関数の知識のない人が外部仕様を決めた
・ハッシュ関数の知識のない人に説明するのが面倒なので目立ちそうな仕様は避けた
・上限を増やすとそんなに長いパスワードを使わなければいけないのかと不安がって問い合わせるユーザーが増えるかもしれないので避けた
・長く設定できるようにすると律儀に手入力するユーザーの誤入力を誘引してクレーマーに進化する恐れがあるのでトラブルの芽は予め摘んでおいた
どうなんでしょうね実際。
Re: (スコア:0)
えっ、ハッシュ化して記録してあるパスワードと、入力パスワードを同様にハッシュ化して比較しないの？
どうせハッシュ化するんだし、パスワード長なんて関係ないと思ってたけど？
無限長とか言ってるトコ見ると、平文パスワードで保存してるの？もしかして？
Re: (スコア:0)
とりあえず、#2772663は１行以上コメントが読めない人だという事はわかった。
Re: (スコア:0)
平文か暗号化したものを持ってるとこもあるんじゃない？
ハッシュ化は衝突がないことが保証できないので、
例えそれが2の512乗分の1という宇宙が滅びるよりあり得ない確率でも
承認しない役員がいてもおかしくない。
Re: (スコア:0)
ダウト
(ソルトが無い糞設計の場合は)野球とかドラゴンとかサッカーとかみんな大好きだからガリガリ君が当たる確率くらいにはぶつかっているに決まっている
#ハッシュすれば良いんでしょ？とか言ってソルトとストレッチングしてないところも多そうだ
Re:なぜ解決できた？ (スコア:1)
＞「なんで上限が必用？」なんて言ってる奴は、たぶんプログラミングしたこと無い人。
なんていう人は、多分ウェブサーバ書いたことがない人。
RFCに最大長なんて規定されてないんだぜ。
なんで、ウェブサーバ（Apacheはデフォルト8,190）とブラウザ（IEは2，083）がそれぞれ勝手に制限をもってる。
パスワードについては例えば、LimitRequestBody とか、下のレイヤで制限されてれば特になにもしなくても問題にはならない。
Re:なぜ解決できた？ (スコア:1)
今、（IDじゃなく）パスワードの話ししてるんだよね。
衝突してなにが困るのさ。
普通、パスワードなんて平文の状態でもいくらでも衝突するんじゃないの。「１２３４」とか。
まあ、SALT付HASHなら、衝突の確率が格段に下がるな。
Re:なぜ解決できた？ (スコア:2)
> なんで、ウェブサーバ（Apacheはデフォルト8,190）とブラウザ（IEは2，083）がそれぞれ勝手に制限をもってる。
だっ、誰です？
パスワード認証を GET メソッドで実装しようとしてるのは！
Re: (スコア:0)
何文字までOKかとか、どの記号まで使えるのかとか明記されてないのが世の中多すぎる。
中には、登録・パスワードの変更時には通る記号が、ログインしようとすると蹴られるというのまであった。
以来、記号トラブルを避けるため、パスワードマネージャーに覚えさせるつもりのパスワードは、
できる限り長いランダムなアルファベットと数字の羅列にするようにしたら、今度は文字数の方のトラブルがちらほら…
Re:なぜ解決できた？ (スコア:1)
パスワード最大文字数を明示しない上に、入力したパスワードが長すぎるとパスワードの末尾を勝手に切り詰めて登録し、その上何も言わない腐れシステムもある。こういう場合、もうログインできなくなっちゃうんだよね。
たしかpixivがパスワード文字列の条件がわからなかったので、問合せをしたけれどなしのつぶてだったな。
せめて、どういう文字列なら正常に受け付ける(つもり)なのか、表示してほしいよな。"今"どういう条件なのか、後で変わったっていいから教えて欲しい。
Re: (スコア:0)
パスワードの17文字以降を無視する、マイクロソフトの悪口はそこまでだ。
Microsoft アカウントのパスワードを 17 文字以上にできないのはどうしてですか? [microsoft.com]
Re:なぜ解決できた？ (スコア:2)
たしか認証に RADIUS [wikipedia.org] を使用していると、16文字しか最初のパケットに入らず、分割が必要になったと思う。手抜きの実装で 16文字しか認証に使われないというのを経験している。
Re:なぜ解決できた？ (スコア:1)
解決できたという事は平文がどっかに保存されていたということで。
スペースで比較が成功／失敗ってのは Oracle の CHAR/VARCHAR2 あたりの問題だろうか・・・？
Re:なぜ解決できた？ (スコア:2)
私も「解決できた」ってあたりからして、平文パスワードでCHAR/VARCHARの違いが問題になったんだろうと想像しましたが、これは別にOracleに限った話じゃないですよね。
・元のシステムではVARCHAR(10)のカラムに可変長のパスワードを平文保存していた。
・新システムも可変長で格納されるのを前提として設計開発。
・ところが新システムのDBカラムをCHAR(10)になっていた。データ移行の際、10文字未満のパスワードはスペースが付加されて10桁固定になってしまう
・結果、認証時にも、後ろにスペースを付加しないとログインできなくなる
って感じで。
で、新DBをVARCHAR(10)に直してから、改めてデータ移行し直すことで、復旧、っと。
新システムが開発段階に入ってから、COBOL流れの「固定長信者」な設計者が、影響を深く考えずに横やりを入れて、データ型をCHAR(10)に変えちゃった、というのを想像しました。
Re: (スコア:0)
たしかに、ありそう。
だとしても、性根がCOBOLerかどうかよりも、ザルなテストしかしていなさそうな性根の方がよっぽど罪。
Re:なぜ解決できた？ (スコア:1)
受け取った入力にサーバー側でスペースくっつけて処理するようになったのなら（つうか最初からそうしとけ）、平文を保存しておく必要は無いだろ。
Re:なぜ解決できた？ (スコア:3)
それだったら今度は末尾のスペースが無視される不具合が発生だな
Re: (スコア:0)
たったそれだけのために、まさかの2日がかりｗ
Re:なぜ解決できた？ (スコア:2, すばらしい洞察)
①問題の原因と修正箇所の特定
②修正案作成
③修正案の承認
④修正作業
⑤単体試験
⑥結合試験
⑦リリース判定会議
⑧リリース
これだけ手順踏むんだぜ？
Re:なぜ解決できた？ (スコア:1)
この会社は知らないけど、少しの変更をするのにもシステム全体をテストをして問題が発生しない事を確認したり、稟議書を回して全役員の承認を貰ったりしなければいけない場合があります。（特に金融系の場合は）
直す以外の作業が圧倒的に多い場合が有るので、一瞬で直せる事が２日かかっても何の不思議もありませんよ？
Re: (スコア:0)
>>システム全体をテストをして問題が発生しない事を確認
これに必要な時間は仕方ないとしても
>>稟議書を回して全役員の承認を貰ったりしなければいけない
これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。
Re: (スコア:0)
>>稟議書を回して全役員の承認を貰ったりしなければいけない
>これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。
？
たとえばどんなことを見失ってんの？
顧客サービス優先とか？
たとえ見失っていなくても手順は必要で、
緊急だから省略していいなんてことは無い。
Re: (スコア:0)
軽く煽ったら思いのほか反論されて
漠然とモラル方面に逃走してるだけでしょう。
深い意味はないと思いますよ。
Re:なぜ解決できた？ (スコア:1)
＞たとえ見失っていなくても手順は必要で、
＞緊急だから省略していいなんてことは無い。
顧客が主要サービスにログインできないレベルの大トラブルなら、稟議に必要な役員みんなあつめて迅速に承認できるようにしたりするだろ。
少なくとも私の知ってるとある金融サービス会社はそうだった。社長からみんな会議室に勢揃い。
Re: (スコア:0)
会社の一大事に稟議を回すのに時間をかける役員なんてものを認めることが間違いって話です。
そもそも稟議なんてのは会議で集まってやるほどのことでもない程度のことを書類回して会議で承認したことにしましょう的なもんです。
この状況でそんなもんでいいの？って言いたかったのです。
役員たるもの、何かコトがあったときには即座に会議に出席できる状態にしておくべきです。
リモート会議でもなんでもいいから。
役員の承認を省略していいなんて言ってないです。
何か問題あったときに現場に責任取らされちゃたまりませんから。
Re: (スコア:0)
× 私の知ってるとある金融サービス会社
○ 私の想像上の金融サービス会社
Re:なぜ解決できた？ (スコア:1)
回避方法も早々に確立してたし、元々そんな緊急性ないでしょ。
#2772546のきまぐれな結果論を無理筋で擁護してるうちに
「役員たるもの」なんてどんどん大仰になった雪ダルマ。
Re:なぜ解決できた？ (スコア:1)
SIerでコードを組まないプログラマは幸せである
Re: (スコア:0)
パスワードにスペースを含んではいけないとかいう謎慣習がパスワードのエントロピーを劇的に低下させる
Re:なぜ解決できた？ (スコア:1)
完全に想像だけど……。
・パスワード制限を強化して、10文字以上にしないといけなくした
・併せてログイン画面で、10文字未満だとエラーを出すようにした
・既存のユーザが10文字未満で登録していることをすっかり忘れてた
・スペースも一文字とカウントされるので、末尾にスペースを足すと文字数チェックをパスできた
・内部のログイン処理は末尾のスペースを切り捨ててから行っていたので、影響がなかった
・結局ログイン時の文字数チェックを廃止した
とか、どうだろう。
Re: (スコア:0)
・最低10文字という仕様で作った
・ほとんど完成後、「短いパスワードが使えないのは不便だ」と騒ぎ出したエラい人
・できる限り変更を少なく修正すべく、「自動でスペースを足す」というのを加えた
・それを忘れて何らかの改修をしちゃった
とか…無理があるか
Re: (スコア:0)
いや、新システムに移行する時の変換プログラムでミスっただけで、パスワード自体は暗号化されてるだろｗ
ハッシュ化して非可逆で保存されて無いのは、金融系としてはどうよと思わなくもないけど・・・
可逆保存するのって未だに一般的だったりするのかな？
Re: (スコア:0)
可逆とは限らないと思う。ハッシュを生成するときにクライアントでスペースを追加していたかも…しれないw
Re: (スコア:0)
認証システムに入れるかは別として、どこかには生パスワード保管してるとは思うけど。
じゃないと例えばハッシュ関数が脆弱化した時とかに
全ユーザーのパスワード再発行でしかハッシュ方式を変更する事ができなくなる。
Re:なぜ解決できた？ (スコア:1)
よく分かっていない素人の発想なんですが，
そういうときは脆弱化したハッシュ関数によるハッシュ値を，
さらに強いハッシュ関数でハッシュ化するみたいなことで解決できないんですか？
途中に脆弱性があるとダメですか？
Re: (スコア:0)
10文字のバッファの初期値がnull埋めじゃなくスペース10文字だったんじゃ。
誰かがnull埋めしたら動かなくなって元に戻したとか。
Re: (スコア:0)
拡張を繰り返した仕様だとフィールドによってNull文字(0x00)で埋めるのと半角スペース(0x20)で埋めるのが混在しててサンプルのASCII記載がどっちも同じ空白という嫌な仕様書を見たことが有ります。
しかもどっちか明示してないのが1個あったけど、質問票の返答が何時まで経っても来ないでのでページの改版履歴を元に推測して2種類のロジック実装。
モジュールごと切り替え可能にして結合試験通すしかなかったという笑えない話が。
試験時に相手側の実装にも詳しい人に聞いたらどっちでもOKにしているというオチだったけど、仕様書の版を上げてもらってクローズにしました。
Re: (スコア:0)
フォームも満タンに
コスモ証券
できるかぎりあかんパターンを考えてみる (スコア:0)
うっかり前方一致検索にしていた不具合を修正した。
どうしてこのバグを発見できなかったか (スコア:0)
このバグを見つけるテストを作るのって、そんなに難しいことだったのでしょうか。
普通にこのレベルのバグを見つけられない、あるいはテストをしていないとしたら、
他にどんな酷いバグが潜んでいるのか分かったもんじゃない。
難しい気はしないのですが、この単純なことに誰も突っ込まないということは、
コードレビューで見つけるより、テストで見つける方がずっと難しいと
考えているからなんでしょうかね。
Re:どうしてこのバグを発見できなかったか (スコア:1)
現に起こった不具合に対して
「なんでこんな簡単な事が」
と外野が後から腐す意義について
皆わかってるからじゃないですかね？