パスワードを忘れた? アカウント作成
11949965 story
バグ

岩井コスモ証券のネット取引システムで認証トラブル、解決法は「パスワードの後ろにスペースを入力する」 62

ストーリー by hylom
どうして金融系のシステムはこうなるのか 部門より

岩井コスモ証券のネット取引システムで、3月2日よりユーザーがパスワードを入力してもログインできないという障害が発生していたようだ(読売新聞)。

3月5日時点では解決済みのようだが、当初は解決方法として「パスワードが6~9桁のユーザーはパスワードの後ろにスペースを入力して10桁にする」ことが提示されていたという(岩井コスモ証券のお知らせページのGoogleキャッシュ)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 10桁に満たないパスワードを勝手にスペースで埋めて登録してたんですよね.

    あっちが持ってるデータは,10桁に埋められたものから生成されたものですよね.

    それを,スペース埋めなくてもいいようにしたってことは,もしかして例の生パスワードを保存してるんですってやつ?

    と思ったけど,手動でスペースを入力してたのを,あっちで勝手にスペースを埋めるようにしただけかな.

    • by Anonymous Coward on 2015年03月05日 18時36分 (#2772547)

      新システム発注時にパスワード長10文字は有っても、「半角スペースで埋めて」という仕様が要求仕様書に無くてやっちまった感がありますね。
      で、テスト環境だと誤った仕様のみだから問題なかったと。
      受け入れ試験時に旧システムのテスト環境を構築してパスワードのMin/Mid/Maxの境界チェックしなかった代償は高い。

      流れを見る限り生パス保存だったのでアカウントロック解除と同時にDBを変換した。
      もしくはハッシュ仕様なら
      3/2:障害でスペース埋め仕様発覚
      3/3:スペース埋めへ仕様変更(ただし、新システムで生成したハッシュへの対応出来ず)
      3/4:スペース埋めないでハッシュ生成して比較、失敗したらスペース埋めてハッシュ生成して比較みたいなロジックに変更
      といった感じでしょうか?

      ログイン画面のお知らせ [iwaicosmo.co.jp]が修羅場を妄想させられて他人ごとながら胃が痛い。
      (以下抜粋)

      【本日以降のログインパスワードの取扱いについて】
      ※すべてのお客様において、スペースキーの追加入力は不要となりました。

      3月4日(水)の夜間処理において、従来からのログインパスワードをご利用いただけますようシステム対応を実施し完了しました。
      お客様のログインパスワードの状況により、次の2通りのお取り扱いとなります。

      1 ・システム変更前のログインパスワードをご利用のお客様
      ・3月2日(月)以降にパスワードの再設定を行ったお客様
        ログインパスワードをそのままご使用下さい

      2 ・スペースを加えログインパスワードを10桁にしてログイン
        されているお客様
        スペース無しの従来のログインパスワードをご使用下さい

      この度は、お客様に大変ご迷惑をお掛けしましたことを深くお詫び申し上げます。

      【3月4日のログインパスワードの取扱いについて】
      3月4日(水)においても、引き続き、従来からのログインパスワードとパスワードが10桁となるようスペースを入力して頂く方法のいずれかでログインが可能となります。
      ログインパスワードが正しくありませんと表示された場合は、両方の入力方法をお試し頂きますようお願いいたします。
      この度は、お客様に大変ご迷惑をお掛けし誠に申し訳ございません。重ねてお詫び申し上げます。

      【3月3日のログイン時のご注意事項について】
      3月2日の夜間処理にて、従来のログインパスワードでログイン可能となるようシステム対応を実施しましたが、全て対応が完了しておりません、一部のお客様におきましては昨日と同様にログインパスワードの桁数が10桁となるようスペースを追加入力いただきますようお願い致します。
      ログインパスワードが正しくありませんと表示された場合は、両方の入力方法をお試しいただきますようお願い致します。
      この度はお客様に大変ご迷惑をお掛けいたしましたことを深くお詫び申し上げます。

      【3月3日のログイン時のご注意事項について】
      3月2日の夜間処理にて、全てのお客様が従来のログインパスワードでログイン可能となるようシステム対応いたします。
      なお、3月2日にパスワードの再設定を行ったお客様を除きます。
      この度はお客様に大変ご迷惑をお掛けいたしましたことを深くお詫び申し上げます。
      ※3月2日にログインパスワードの桁数を10桁となるよう、スペースの入力により対応いただきましたお客様は、エラーとなりログイン出来なくなりますので、従来のログインパスワードのみでログインいただきますようご注意下さい。

      ※システム対応に伴い、3月3日のサービス開始時間を午前7時(通常は5時30分)とさせていただきますのでご了承下さい。

      【3月2日 ログイン出来ないお客様へ】
      ログインパスワードの桁数が10桁となるよう、ご利用いただいておりましたログインパスワードの後ろにスペースの入力をお願いします。
      ※順次ロック解除の作業をおこなっておりますので、暫くたってから再度ログインしていただきますようお願いします。

      親コメント
    • by minet (45149) on 2015年03月05日 18時13分 (#2772526) 日記

      > あっちが持ってるデータは,10桁に埋められたものから生成されたもの

      平文じゃなくても、ハッシュ化処理を10文字固定でやってるとか?

      親コメント
      • by s-wakaba (47029) on 2015年03月05日 18時25分 (#2772537)

        10文字より長いパスワードを使っていると、11文字目以降は実はデタラメでもOK、とかだと笑える。

        親コメント
        • by sunow (19805) on 2015年03月05日 20時30分 (#2772623)

          10文字より長いパスワードを登録すると、勝手に10文字に切ってから登録するシステムがあったことを思い出した。

          親コメント
          • by Anonymous Coward on 2015年03月05日 20時41分 (#2772630)

            Jetstarが今まさにそれだよ...いくら言ってもなおしてくれない

            親コメント
            • by Anonymous Coward

              そもそもパスワードの文字数の上限って、なんのためにあるんだろう。
              異常なほど長いパスワードで通信量を逼迫させる馬鹿対策としても、1024文字くらいはOKにすればいいのに。

              どうせ俺はパスワード覚える気は無いので、システムが受け入れる最長文字数のパスワードをランダムに生成して使ってるが。

              • by epheal (32955) on 2015年03月06日 11時49分 (#2772905)

                ネットで送信されてサーバーが解釈するデータである以上、上限値は必要でしょう。
                仮に10億文字(1GB)のパスワードとか送られたらって考えればわかります。
                ネットワークのリソースもhash化のための負荷も相当になります。
                要するに正規のパスワード認証を繰り返すだけで攻撃が成立してしまいます。

                親コメント
              • by Anonymous Coward

                「なんで上限が必用?」なんて言ってる奴は、たぶんプログラミングしたこと無い人。
                パスワードに限らず、何を作る場合でも上限は必用。

                無限長なんてものを認めた時点で、プログラムもデバッグも必用とするリソースも、
                そしてかかる工数と費用も桁違いに増える。動作保証も出来なくなる。
                だからよほどのバカじゃ無きゃそんなことはしない
                #自動車の乗員しかり、トラックの積載量しかり。無限大などありえない。

              • by Anonymous Coward

                んー…

                ・ハッシュ関数の知識のない人が外部仕様を決めた
                ・ハッシュ関数の知識のない人に説明するのが面倒なので目立ちそうな仕様は避けた
                ・上限を増やすとそんなに長いパスワードを使わなければいけないのかと不安がって問い合わせるユーザーが増えるかもしれないので避けた
                ・長く設定できるようにすると律儀に手入力するユーザーの誤入力を誘引してクレーマーに進化する恐れがあるのでトラブルの芽は予め摘んでおいた

                どうなんでしょうね実際。

              • by Anonymous Coward

                えっ、ハッシュ化して記録してあるパスワードと、入力パスワードを同様にハッシュ化して比較しないの?
                どうせハッシュ化するんだし、パスワード長なんて関係ないと思ってたけど?
                無限長とか言ってるトコ見ると、平文パスワードで保存してるの?もしかして?

              • by Anonymous Coward

                とりあえず、#2772663は1行以上コメントが読めない人だという事はわかった。

              • by Anonymous Coward

                平文か暗号化したものを持ってるとこもあるんじゃない?
                ハッシュ化は衝突がないことが保証できないので、
                例えそれが2の512乗分の1という宇宙が滅びるよりあり得ない確率でも
                承認しない役員がいてもおかしくない。

              • by Anonymous Coward

                ダウト

                (ソルトが無い糞設計の場合は)野球とかドラゴンとかサッカーとかみんな大好きだからガリガリ君が当たる確率くらいにはぶつかっているに決まっている

                #ハッシュすれば良いんでしょ?とか言ってソルトとストレッチングしてないところも多そうだ

              • by nim (10479) on 2015年03月06日 14時24分 (#2773002)

                >「なんで上限が必用?」なんて言ってる奴は、たぶんプログラミングしたこと無い人。

                なんていう人は、多分ウェブサーバ書いたことがない人。
                RFCに最大長なんて規定されてないんだぜ。
                なんで、ウェブサーバ(Apacheはデフォルト8,190)とブラウザ(IEは2,083)がそれぞれ勝手に制限をもってる。

                パスワードについては例えば、LimitRequestBody とか、下のレイヤで制限されてれば特になにもしなくても問題にはならない。

                親コメント
              • by nim (10479) on 2015年03月06日 14時27分 (#2773005)

                今、(IDじゃなく)パスワードの話ししてるんだよね。
                衝突してなにが困るのさ。
                普通、パスワードなんて平文の状態でもいくらでも衝突するんじゃないの。「1234」とか。
                まあ、SALT付HASHなら、衝突の確率が格段に下がるな。

                親コメント
              • > なんで、ウェブサーバ(Apacheはデフォルト8,190)とブラウザ(IEは2,083)がそれぞれ勝手に制限をもってる。

                だっ、誰です?
                パスワード認証を GET メソッドで実装しようとしてるのは!

                親コメント
          • by Anonymous Coward

            何文字までOKかとか、どの記号まで使えるのかとか明記されてないのが世の中多すぎる。

            中には、登録・パスワードの変更時には通る記号が、ログインしようとすると蹴られるというのまであった。

            以来、記号トラブルを避けるため、パスワードマネージャーに覚えさせるつもりのパスワードは、
            できる限り長いランダムなアルファベットと数字の羅列にするようにしたら、今度は文字数の方のトラブルがちらほら…

            • by haginov (32812) on 2015年03月06日 18時50分 (#2773173) 日記
              ワカル。

              パスワード最大文字数を明示しない上に、入力したパスワードが長すぎるとパスワードの末尾を勝手に切り詰めて登録し、その上何も言わない腐れシステムもある。こういう場合、もうログインできなくなっちゃうんだよね。

              たしかpixivがパスワード文字列の条件がわからなかったので、問合せをしたけれどなしのつぶてだったな。
              せめて、どういう文字列なら正常に受け付ける(つもり)なのか、表示してほしいよな。"今"どういう条件なのか、後で変わったっていいから教えて欲しい。
              親コメント
        • by Anonymous Coward

          パスワードの17文字以降を無視する、マイクロソフトの悪口はそこまでだ。

          Microsoft アカウントのパスワードを 17 文字以上にできないのはどうしてですか? [microsoft.com]

    • by Anonymous Coward on 2015年03月05日 18時20分 (#2772530)

      解決できたという事は平文がどっかに保存されていたということで。

      スペースで比較が成功/失敗ってのは Oracle の CHAR/VARCHAR2 あたりの問題だろうか・・・?

      親コメント
      • 私も「解決できた」ってあたりからして、平文パスワードでCHAR/VARCHARの違いが問題になったんだろうと想像しましたが、これは別にOracleに限った話じゃないですよね。

        ・元のシステムではVARCHAR(10)のカラムに可変長のパスワードを平文保存していた。
        ・新システムも可変長で格納されるのを前提として設計開発。
        ・ところが新システムのDBカラムをCHAR(10)になっていた。データ移行の際、10文字未満のパスワードはスペースが付加されて10桁固定になってしまう
        ・結果、認証時にも、後ろにスペースを付加しないとログインできなくなる
        って感じで。
        で、新DBをVARCHAR(10)に直してから、改めてデータ移行し直すことで、復旧、っと。

        新システムが開発段階に入ってから、COBOL流れの「固定長信者」な設計者が、影響を深く考えずに横やりを入れて、データ型をCHAR(10)に変えちゃった、というのを想像しました。

        親コメント
        • by Anonymous Coward

          たしかに、ありそう。

          だとしても、性根がCOBOLerかどうかよりも、ザルなテストしかしていなさそうな性根の方がよっぽど罪。

      • by Anonymous Coward on 2015年03月05日 18時24分 (#2772534)

        受け取った入力にサーバー側でスペースくっつけて処理するようになったのなら(つうか最初からそうしとけ)、平文を保存しておく必要は無いだろ。

        親コメント
        • by lcc (46023) on 2015年03月06日 1時25分 (#2772733) 日記

          それだったら今度は末尾のスペースが無視される不具合が発生だな

          親コメント
        • by Anonymous Coward

          たったそれだけのために、まさかの2日がかりw

          • Re:なぜ解決できた? (スコア:2, すばらしい洞察)

            by Anonymous Coward on 2015年03月05日 18時41分 (#2772550)

            ①問題の原因と修正箇所の特定
            ②修正案作成
            ③修正案の承認
            ④修正作業
            ⑤単体試験
            ⑥結合試験
            ⑦リリース判定会議
            ⑧リリース

            これだけ手順踏むんだぜ?

            親コメント
          • by Anonymous Coward on 2015年03月05日 18時46分 (#2772555)

            この会社は知らないけど、少しの変更をするのにもシステム全体をテストをして問題が発生しない事を確認したり、稟議書を回して全役員の承認を貰ったりしなければいけない場合があります。(特に金融系の場合は)
            直す以外の作業が圧倒的に多い場合が有るので、一瞬で直せる事が2日かかっても何の不思議もありませんよ?

            親コメント
            • by Anonymous Coward

              >>システム全体をテストをして問題が発生しない事を確認
              これに必要な時間は仕方ないとしても

              >>稟議書を回して全役員の承認を貰ったりしなければいけない
              これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。

              • by Anonymous Coward

                >>稟議書を回して全役員の承認を貰ったりしなければいけない
                >これが時間がかかることの理由になって当然ってのは、大切なことを見失ってしまっているんじゃないでしょうか。

                たとえばどんなことを見失ってんの?
                顧客サービス優先とか?
                たとえ見失っていなくても手順は必要で、
                緊急だから省略していいなんてことは無い。

              • by Anonymous Coward

                軽く煽ったら思いのほか反論されて
                漠然とモラル方面に逃走してるだけでしょう。
                深い意味はないと思いますよ。

              • by nim (10479) on 2015年03月05日 21時09分 (#2772640)

                >たとえ見失っていなくても手順は必要で、
                >緊急だから省略していいなんてことは無い。

                顧客が主要サービスにログインできないレベルの大トラブルなら、稟議に必要な役員みんなあつめて迅速に承認できるようにしたりするだろ。
                少なくとも私の知ってるとある金融サービス会社はそうだった。社長からみんな会議室に勢揃い。

                親コメント
              • by Anonymous Coward

                会社の一大事に稟議を回すのに時間をかける役員なんてものを認めることが間違いって話です。

                そもそも稟議なんてのは会議で集まってやるほどのことでもない程度のことを書類回して会議で承認したことにしましょう的なもんです。

                この状況でそんなもんでいいの?って言いたかったのです。

                役員たるもの、何かコトがあったときには即座に会議に出席できる状態にしておくべきです。
                リモート会議でもなんでもいいから。

                役員の承認を省略していいなんて言ってないです。
                何か問題あったときに現場に責任取らされちゃたまりませんから。

              • by Anonymous Coward

                × 私の知ってるとある金融サービス会社
                ○ 私の想像上の金融サービス会社

              • by Anonymous Coward on 2015年03月06日 1時59分 (#2772741)

                回避方法も早々に確立してたし、元々そんな緊急性ないでしょ。
                #2772546のきまぐれな結果論を無理筋で擁護してるうちに
                「役員たるもの」なんてどんどん大仰になった雪ダルマ。

                親コメント
          • by Anonymous Coward on 2015年03月05日 23時12分 (#2772696)

            SIerでコードを組まないプログラマは幸せである

            親コメント
      • by Anonymous Coward

        パスワードにスペースを含んではいけないとかいう謎慣習がパスワードのエントロピーを劇的に低下させる

    • by Anonymous Coward on 2015年03月05日 18時24分 (#2772535)

      完全に想像だけど……。

      ・パスワード制限を強化して、10文字以上にしないといけなくした
      ・併せてログイン画面で、10文字未満だとエラーを出すようにした
      ・既存のユーザが10文字未満で登録していることをすっかり忘れてた
      ・スペースも一文字とカウントされるので、末尾にスペースを足すと文字数チェックをパスできた
      ・内部のログイン処理は末尾のスペースを切り捨ててから行っていたので、影響がなかった
      ・結局ログイン時の文字数チェックを廃止した

      とか、どうだろう。

      親コメント
      • by Anonymous Coward

        ・最低10文字という仕様で作った
        ・ほとんど完成後、「短いパスワードが使えないのは不便だ」と騒ぎ出したエラい人
        ・できる限り変更を少なく修正すべく、「自動でスペースを足す」というのを加えた
        ・それを忘れて何らかの改修をしちゃった

        とか…無理があるか

    • by Anonymous Coward

      生パスワードを保存してる

      いや、新システムに移行する時の変換プログラムでミスっただけで、パスワード自体は暗号化されてるだろw

      ハッシュ化して非可逆で保存されて無いのは、金融系としてはどうよと思わなくもないけど・・・
      可逆保存するのって未だに一般的だったりするのかな?

      • by Anonymous Coward

        可逆とは限らないと思う。ハッシュを生成するときにクライアントでスペースを追加していたかも…しれないw

      • by Anonymous Coward

        認証システムに入れるかは別として、どこかには生パスワード保管してるとは思うけど。

        じゃないと例えばハッシュ関数が脆弱化した時とかに
        全ユーザーのパスワード再発行でしかハッシュ方式を変更する事ができなくなる。

    • by Anonymous Coward

      10文字のバッファの初期値がnull埋めじゃなくスペース10文字だったんじゃ。
      誰かがnull埋めしたら動かなくなって元に戻したとか。

      • by Anonymous Coward

        拡張を繰り返した仕様だとフィールドによってNull文字(0x00)で埋めるのと半角スペース(0x20)で埋めるのが混在しててサンプルのASCII記載がどっちも同じ空白という嫌な仕様書を見たことが有ります。

        しかもどっちか明示してないのが1個あったけど、質問票の返答が何時まで経っても来ないでのでページの改版履歴を元に推測して2種類のロジック実装。
        モジュールごと切り替え可能にして結合試験通すしかなかったという笑えない話が。
        試験時に相手側の実装にも詳しい人に聞いたらどっちでもOKにしているというオチだったけど、仕様書の版を上げてもらってクローズにしました。

    • by Anonymous Coward

      フォームも満タンに
      コスモ証券

  • by Anonymous Coward on 2015年03月05日 21時04分 (#2772638)

    うっかり前方一致検索にしていた不具合を修正した。

  • by Anonymous Coward on 2015年03月06日 1時31分 (#2772734)

    このバグを見つけるテストを作るのって、そんなに難しいことだったのでしょうか。

    普通にこのレベルのバグを見つけられない、あるいはテストをしていないとしたら、
    他にどんな酷いバグが潜んでいるのか分かったもんじゃない。

    難しい気はしないのですが、この単純なことに誰も突っ込まないということは、
    コードレビューで見つけるより、テストで見つける方がずっと難しいと
    考えているからなんでしょうかね。

typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...