パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

PlayStation Networkの情報漏洩事件、Sonyが状況を説明」記事へのコメント

  • パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。
    ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、
    ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。
    専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。

    • Re: (スコア:2, 参考になる)

      今の所平文かどうかははっきりしませんね。ただ変更を勧める理由としては
      1. 平文で保存していた
      2. 単純なハッシュ化だけだった
      3. ハッシュ化されたパスワードに加え、ハッシュ方法(プログラムのソース)が漏洩した

      の3通りが考えられそうです。
      2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
      平文でなくても変更を呼びかける可能性はあるでしょう。

      • 2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。

        辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。

        ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
        完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。

        システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで

        • ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。

          それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。

          完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。

          ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
          それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。

          例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも

          abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'
          def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874645a183565'

          と別のハッシュ値になるよう実装すべきです。
          ##それでも実装コードが漏れると駄目です。

          この考え方やサンプルコードは徳丸さんの書籍 [hash-c.co.jp]のp327-328に詳しく載ってますので是非読んでみてください。
          ##というかまんま受け売りです。(^_^;)

          親コメント
          • by Anonymous Coward
            > ##それでも実装コードが漏れると駄目です。

            サーバに不正に侵入された時点で、実装もバレていると考えるべきです。
            そのサーバ上には実装のバイナリがあるでしょうから、バイナリを逆アセンブルorコンパイルすることで、どのような実装なのかもバレてしまうでしょう。
          • 車輪の再発明をしなくても正しいやりかたが標準規格として公開されているわけだから
            • HMACを使っても脆弱ではないのですが、異なる目的のためのHMACをパスワードの保存に使う意味はあるのでしょうか。

              HMACは受信したメッセージについてそれが秘密鍵を持った相手が書いたメッセージであり、内容が改竄されていないと保障するものです。
              アルゴリズムとしては秘密鍵とメッセージを合わせてハッシュを計算し、それをさらに秘密鍵と合わせてハッシュを取ります(実際にはもう少し細かく規格化されています)。

              なぜハッシュを1回ではなく2回取るのかというと、ある種のハッシュ関数には、メッセージの後ろに工夫したデータを付けると秘密鍵が漏れていなくてもハッシュ値を変えずにメッセージを変えられてしまう脆弱性があります。
              これを防ぐために鍵付きハッシュを2回かけて1回目のハッシュ値を隠しています。

              この1回だけハッシュを取る方法に対する攻撃は、攻撃者に平文メッセージが知られている場合に起きます。
              しかし、パスワードを保存する用途では平文メッセージにあたるのは平文パスワードです。
              当然攻撃者は平文パスワードを知りません。

              そのため2回ハッシュをかける意味はないのではないでしょうか。
              親コメント
          • by Anonymous Coward
            ハッシュってそんなものじゃないだろう。
            SHA1やSHA256などなど、衝突困難性は数学で証明されてるだろう。
            (現時点で衝突を見つける効率的なアルゴリズムは発見されていないという意味)

            >> 例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
            >>
            >> abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'
            >> def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874645a183565'
            >>
            >>と別のハッシュ値になるよう実装すべきです。

            ここに関してはある程度同意で
            • ハッシュ値をパスワードと固定の秘密鍵のみで決定してしまう場合、攻撃者にハッシュ値ごとに出現回数を数えられると、頻出するハッシュ値は"password"や"111"などの安易なパスワードだと推測されてしまいます。
              安易なパスワードを使うユーザは他のサイトでも同じパスワードを使っている場合が多いので、該当ユーザのユーザ名やメールアドレスを使って他のサイトでパスワードを試されれば一度に数千ユーザのパスワードを知られてしまいます。
              この場合複数のサイトで複数のアカウントでパスワードを試されるので検出は難しくなります。
              攻撃者が他サイト(攻撃者が作ったサイトを含む)でのユーザ名とパスワードの対応表を持っていればより少ない試行でパスワードを知られてしまいます。
              この攻撃はサーバのプログラムや秘密鍵が流出していなくてもデータベースの情報のみで成立してしまいますし、ハッシュ関数が暗号学的に強固でも受けてしまいます。

              一方でパスワードが同じでもユーザごとにハッシュ値を変えれば、安易なパスワードを使っているユーザを攻撃者に知られないので各ユーザに対する攻撃の成功率はずっと下がりますし、1ユーザのパスワードを知られてしまっても他ユーザのパスワードは守れます。

              また、プログラムと秘密鍵を知られてしまった場合でも、総当たり的な攻撃に強くなります。
              ハッシュ関数が暗号学的に強固で一般的な攻撃に強かったとしても、プログラムと秘密鍵を知られている場合、パスワードの総当たりである程度のユーザのパスワードを知られてしまいます。
              しかしこのときハッシュ値をユーザごとに変えない場合、1回の攻撃で全ユーザ分攻撃されてしまいますが、ユーザごとに変えた場合、攻撃者は1ユーザごとに攻撃しないといけないので時間はずっとかかるようになります。

              このようにハッシュ値をユーザごとに変えるようにすると漏洩してしまったときの耐久性を大幅に上げられます。
              一方で実装する手間はパスワードをハッシュ値にかける前にユーザIDを連結しておくだけなのでほとんどかかりません。
              わずかな手間でデメリットも少なく、得られるものは多いのでぜひ「するべき」ではないでしょうか。
              親コメント
            • ちょっと誤解されすぎなので全部はレスしませんが、前述のハッシュ値はSHA256で求めたものですよ…。
              ハッシュ関数自体を独自に作るのではなく、ハッシュ関数の利用方法の話です。>ソルト&ストレッチング

              PHPだとこんなコードです。(わざとダサく書いてます)

              $salt = $id . 'himitunomojiretsu'; //(ユーザー毎に違う)ソルト
              $hash='';
              for ($i = 0; $i<1090; $i++) { //ストレッチング
                  $hash = hash('sha256', $hash . $pwd . $salt);
              }

              こう「するべき」である理由は、貴方も仰ってる↓の点などです。

              ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。

              実装コードが漏れた場合、同じコードで元パスワードを推測可能です。
              ハッシュ値から元の値を直接求めるのが難しいのであり、適当なパスワードのハッシュ値を求めて保存内容と比較するだけなら難しくはありません。
              あとは適当なパスワードを辞書攻撃や総当りで選ぶだけです。

              解説は省きます。是非紹介した書籍 [amazon.co.jp]を手にとってみてください。(^_^;)
              衝突困難性に加えて、原像計算困難性とかも網羅した解説、綺麗なサンプルコードが載っています。

              ##他の方の言うHMACについては詳しく知りません。PHPのリファレンス見る限りはストレッチングとソルトを内包した考えなのかな…?

              親コメント
              • by Anonymous Coward

                #1944956 [srad.jp] の AC です。

                $salt = $id . 'himitunomojiretsu'; //(ユーザー毎に違う)ソルト
                $hash='';
                for ($i = 0; $i<1090; $i++) { //ストレッチング
                    $hash = hash('sha256', $hash . $pwd . $salt);
                }

                これは,私が
                > 秘密鍵を使うようなハッシュ方法
                と呼んだものなので,こうしたハッシュ方法の推定が比較的困難で
                あることには同意いたします。("himitunomojiretsu" や "1090"
                が「秘密鍵」。)

                私の前のコメントで「オリジナルのハッシュ『関数』」と書いちゃったのが,
                誤解を招いてしまったかもしれません…。
                ハッシュ関数そのものか,それを使ってソルト

              • by Anonymous Coward

                故意にコードを簡略化したのかもしれませんが、流石にそのコードだとSHA256と仮定して元の値を1度見つけるだけで

                XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXpasswordabchimitunomojiretsu

                『65文字目からユーザーIDが見つかるまでの間か、ユーザーID直後の文字が多分パスワード』と推測可能ですよ。

                ストレッチングした意味があるようで無いような…w
                まあ65文字オーバー対応のレインボーテーブル等が実用化しない限り気にしなくてもいいかもしれませんけど。

              • ストレッチングした意味があるようで無いような…w

                ストレッチングの意味は、保存内容と適当なパスワードのハッシュ値の『比較に要する時間を延ばす』ことですね。
                難読化の意味合いで使う物では無いと思います。

                指摘されてる問題点については、原像計算困難性次第です。
                保険的に単純結合以外を使っても良いですが、ソルトを含めて(ハッシュ前の値が)長い文字列になる事をまず優先してください。

                親コメント
            • by Anonymous Coward
              なにこのAC
              生兵法にも程がある
              • by Anonymous Coward
                どういったところが生兵法なのか指摘しないと、あんたが間抜けACになる。

                少なくとも僕には、どこが間違っているのかよくわからん。
              • by Anonymous Coward
                おれならこうする・・・っていう発想をする時点で、生兵法です。
                自分の知識や技術が一流ではないことを知り、自分には手に負えないので専門のコンサルを使うべきです。
                コンサルとの契約には法務部がしっかりチェックを入れ、何かあったときにはコンサルが損害賠償する、そういう契約にしてください。
              • 少なくとも僕には、どこが間違っているのかよくわからん。

                もとの人が誤解されすぎ(#1945118)と書いているけど、その通りで、セキュリティの話をする上で暗黙の前提としているところを理解してないか、難癖つけるためにわざと曲解しているようにしか思えないっす。

                SHA1やSHA256などなど、衝突困難性は数学で証明されてるだろう。

                以下、ハッシュ関数についてのあれこれが書かれているけど、元のコメントはそんなことは当然であり、その前提での話をしている。それらを使った上での暗号化の実装の話をしている。最後の捨て台詞みたいな、

                ハッシュのアルゴリズムを自分で考えて実装するほうがめちゃくちゃ開発工数かかる。 そしてその独自ハッシュの安全性は誰が担保するんだろうね?

                も、話があさっての方向を向きすぎてるというか、ハッシュ単体の話などしてないのになにを言ってるんだという感じです。「ハッシュ使えば安心」→「使った上でこういう実装にしないと [srad.jp]」→「ハッシュはそういうもんじゃないだろう」→「えっ?」って感じ。

                生兵法ACの話を間違ってないと思ってしまうのは、pochi-pさんが何を言ってるのかを理解してなくて、同じ誤解をしているからじゃないでしょうか?

                --
                LIVE-GON(リベゴン)
                親コメント

犯人はmoriwaka -- Anonymous Coward

処理中...