PlayStation Networkの情報漏洩事件、Sonyが状況を説明 77
ストーリー by headless
説明 部門より
説明 部門より
あるAnonymous Coward 曰く、
ソニー・コンピューターエンターテインメントは4月27日、PlayStation Network/Qriocityの障害と情報漏洩に関する報告を「重要なお知らせ」として発表した。また、PlayStation Blogでは、Q&A形式で状況を説明する記事が掲載されている (重要なお知らせ、 PlayStation Blogの記事)。
報告によると、クレジットカード情報は暗号化されており、攻撃者がデータを入手した形跡は見つかっていないとのこと。ただし、攻撃者がクレジットカード情報を入手した可能性は完全には否定できないともしている。クレジットカード裏のセキュリティーコードについてはサービス入会時に入力を求めないため、システム側にも保存されていない。
攻撃者が入手したとみられるデータは、クレジットカード情報と別に暗号化なしで保存されていたアカウント情報だ。攻撃者が入手したデータを悪用する可能性もある。電子メールや電話、郵便などでクレジットカード情報や個人情報を入手しようとする手口には十分注意してほしいとのことだ。また、アカウント情報にはパスワードも含まれるので、サービスが再開されたらパスワードをすぐに変更する必要がある。他のWebサービスなどで同じパスワードを使用している場合、すぐに変更することが推奨される。
サービスは4月26日から数えて1週間以内(5月2日頃まで)に再開したいとのことだが、ネットワークの安全性に確信が持てるようになるまでは再開しないともしている。
パスワードは平文で保存してたのでしょうか (スコア:4, すばらしい洞察)
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。
ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、
ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。
専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
Re:パスワードは平文で保存してたのでしょうか (スコア:2, 参考になる)
の３通りが考えられそうです。
２番と３番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
平文でなくても変更を呼びかける可能性はあるでしょう。
ハッシュ値で保存していてもパスワードは変更させるべき (スコア:3, すばらしい洞察)
２，３ の前提がなくても，ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては，ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら，それこそがズサンな対応ではないでしょうか。
しかも，「再開後にユーザ各自で変更することを推奨」なんて方法ではなく，「すべてのアカウントをいったん無効化し，再開後にユーザに再アクティベートしてもらう」といった方法をとるべきです。（たぶん，他のコメントで「パスワード初期化」を言われているのはこのことだと思っています。）
すでにパスワード情報が漏洩してから時間が経っていますので，サービス再開直後に不正使用される可能性は高いでしょう。パスワード変更をユーザ任せにするのは，「瑕疵責任の一部をユーザに転嫁できる」ということ以外に意義はないように思います。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:3, 参考になる)
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
と別のハッシュ値になるよう実装すべきです。
##それでも実装コードが漏れると駄目です。
この考え方やサンプルコードは徳丸さんの書籍 [hash-c.co.jp]のp327-328に詳しく載ってますので是非読んでみてください。
##というかまんま受け売りです。(^_^;)
Re: (スコア:0)
サーバに不正に侵入された時点で、実装もバレていると考えるべきです。
そのサーバ上には実装のバイナリがあるでしょうから、バイナリを逆アセンブルorコンパイルすることで、どのような実装なのかもバレてしまうでしょう。
HMACを使えとアドバイスすべきでは？ (スコア:0)
Re:HMACを使えとアドバイスすべきでは？ (スコア:2)
HMACは受信したメッセージについてそれが秘密鍵を持った相手が書いたメッセージであり、内容が改竄されていないと保障するものです。
アルゴリズムとしては秘密鍵とメッセージを合わせてハッシュを計算し、それをさらに秘密鍵と合わせてハッシュを取ります(実際にはもう少し細かく規格化されています)。
なぜハッシュを1回ではなく2回取るのかというと、ある種のハッシュ関数には、メッセージの後ろに工夫したデータを付けると秘密鍵が漏れていなくてもハッシュ値を変えずにメッセージを変えられてしまう脆弱性があります。
これを防ぐために鍵付きハッシュを2回かけて1回目のハッシュ値を隠しています。
この1回だけハッシュを取る方法に対する攻撃は、攻撃者に平文メッセージが知られている場合に起きます。
しかし、パスワードを保存する用途では平文メッセージにあたるのは平文パスワードです。
当然攻撃者は平文パスワードを知りません。
そのため2回ハッシュをかける意味はないのではないでしょうか。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:2)
安易なパスワードを使うユーザは他のサイトでも同じパスワードを使っている場合が多いので、該当ユーザのユーザ名やメールアドレスを使って他のサイトでパスワードを試されれば一度に数千ユーザのパスワードを知られてしまいます。
この場合複数のサイトで複数のアカウントでパスワードを試されるので検出は難しくなります。
攻撃者が他サイト(攻撃者が作ったサイトを含む)でのユーザ名とパスワードの対応表を持っていればより少ない試行でパスワードを知られてしまいます。
この攻撃はサーバのプログラムや秘密鍵が流出していなくてもデータベースの情報のみで成立してしまいますし、ハッシュ関数が暗号学的に強固でも受けてしまいます。
一方でパスワードが同じでもユーザごとにハッシュ値を変えれば、安易なパスワードを使っているユーザを攻撃者に知られないので各ユーザに対する攻撃の成功率はずっと下がりますし、1ユーザのパスワードを知られてしまっても他ユーザのパスワードは守れます。
また、プログラムと秘密鍵を知られてしまった場合でも、総当たり的な攻撃に強くなります。
ハッシュ関数が暗号学的に強固で一般的な攻撃に強かったとしても、プログラムと秘密鍵を知られている場合、パスワードの総当たりである程度のユーザのパスワードを知られてしまいます。
しかしこのときハッシュ値をユーザごとに変えない場合、1回の攻撃で全ユーザ分攻撃されてしまいますが、ユーザごとに変えた場合、攻撃者は1ユーザごとに攻撃しないといけないので時間はずっとかかるようになります。
このようにハッシュ値をユーザごとに変えるようにすると漏洩してしまったときの耐久性を大幅に上げられます。
一方で実装する手間はパスワードをハッシュ値にかける前にユーザIDを連結しておくだけなのでほとんどかかりません。
わずかな手間でデメリットも少なく、得られるものは多いのでぜひ「するべき」ではないでしょうか。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:1)
ちょっと誤解されすぎなので全部はレスしませんが、前述のハッシュ値はSHA256で求めたものですよ…。
ハッシュ関数自体を独自に作るのではなく、ハッシュ関数の利用方法の話です。＞ソルト＆ストレッチング
PHPだとこんなコードです。（わざとダサく書いてます）
こう「するべき」である理由は、貴方も仰ってる↓の点などです。
ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。
実装コードが漏れた場合、同じコードで元パスワードを推測可能です。
ハッシュ値から元の値を直接求めるのが難しいのであり、適当なパスワードのハッシュ値を求めて保存内容と比較するだけなら難しくはありません。
あとは適当なパスワードを辞書攻撃や総当りで選ぶだけです。
解説は省きます。是非紹介した書籍 [amazon.co.jp]を手にとってみてください。(^_^;)
衝突困難性に加えて、原像計算困難性とかも網羅した解説、綺麗なサンプルコードが載っています。
##他の方の言うHMACについては詳しく知りません。PHPのリファレンス見る限りはストレッチングとソルトを内包した考えなのかな…？
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:1)
ストレッチングした意味があるようで無いような…ｗ
ストレッチングの意味は、保存内容と適当なパスワードのハッシュ値の『比較に要する時間を延ばす』ことですね。
難読化の意味合いで使う物では無いと思います。
指摘されてる問題点については、原像計算困難性次第です。
保険的に単純結合以外を使っても良いですが、ソルトを含めて(ハッシュ前の値が)長い文字列になる事をまず優先してください。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:1)
もとの人が誤解されすぎ(#1945118)と書いているけど、その通りで、セキュリティの話をする上で暗黙の前提としているところを理解してないか、難癖つけるためにわざと曲解しているようにしか思えないっす。
以下、ハッシュ関数についてのあれこれが書かれているけど、元のコメントはそんなことは当然であり、その前提での話をしている。それらを使った上での暗号化の実装の話をしている。最後の捨て台詞みたいな、
も、話があさっての方向を向きすぎてるというか、ハッシュ単体の話などしてないのになにを言ってるんだという感じです。「ハッシュ使えば安心」→「使った上でこういう実装にしないと [srad.jp]」→「ハッシュはそういうもんじゃないだろう」→「えっ？」って感じ。
生兵法ACの話を間違ってないと思ってしまうのは、pochi-pさんが何を言ってるのかを理解してなくて、同じ誤解をしているからじゃないでしょうか？
LIVE-GON(リベゴン)
Re:パスワードは平文で保存してたのでしょうか (スコア:1, 参考になる)
Re: (スコア:0)
Re: (スコア:0)
soltつけて通信するケースでもハッシュ保存でいけるんでしたっけ?
Re: (スコア:0)
Dovecot が保存する CRAM-MD5 認証用パスワード [fc2.com]
こういうお話?
Re: (スコア:0)
ハッシュ化して保持は少なくとも「常識」ではあると思うのだけど、
氏名住所メアドも同様に漏出不可な情報である以上、パスワードだけ別枠で強度を高める事に
意味はあるのだろうか、という疑念が少し頭をよぎる。
今回のような事故が起きるとすれば、被害を縮小する効果は確かにあるのだけれど、
「情報の漏洩を予め想定して」という対応は何か割り切れない思いがある。
パスワードは漏洩が認識さえ出来ればリセットで対応する事ができるし、
そのサービス内のみで有効なユーザ権限を奪われるだけなので被害は限定的。
使い回しをするユーザは、そもそも漏洩事故よりも大きいリスクを抱えている。
ユーザパスワードって、個人情報に比べれば大した情報じゃないのでは、という気もしてくる。
まあ仮に理屈がそうであっても、平文で保持するのは中々度胸がいると思うけど、
別のメリットや必要性があれば平文保持もあり得る事なのかな、と。
Re:パスワードは平文で保存してたのでしょうか (スコア:1)
Re:パスワードは平文で保存してたのでしょうか (スコア:2, すばらしい洞察)
＞要するに想定外という言い訳が通用するわけですね、わかります。
いや「想定内だけど、トータルのリスクを最小化する上で必ずしも重要では無い」ってことじゃ。
「喫煙や過労の方が健康被害が大きいのに、微量の放射線被爆なんか気にしてもしょうがないよね」的な。
この手のサービスは何らかの形のパスワードリセットの仕組みを持ってるのが普通だし、
パスワードリセットができる情報を取得されたらパスワードの暗号化なんて意味が無くなる。
むしろ重要なのは、#1944963 にも書いてあるけどパスワードの使い回しをしないことの方だな。
PSNとTwitterとネットバンクで同じパスワードを使い回してる人がいるとすれば、
まずすべきことはPSNに保存されたパスワードの暗号化ではなく、それぞれに
別個のパスワードを設定すること。
しばらくムリでそ？ (スコア:1, 興味深い)
クレジットカードのお漏らしが確定していないけど、
仮におねしょがバレたので親にこっぴどく叱られる………いや、カード情報の漏洩事故を起こすと、クレジットカード利用の再開をするためにはPCIDSSの監査を受けないとダメなんで時間がかかるでしょう(ただ、逆転ウルトラC技があるみたい)。それまでの間はプリペイドカードだけとか、無料のサービスの範囲だけと言われてもなぁって気がします。
最悪の事態を想定すると「住所や生年月日＋クレジットカード情報」のセットなんで、不正利用しても使える可能性大ですね。闇のマーケットとやらに売ってもいい金になるでしょう。
Re:しばらくムリでそ？ (スコア:1, 参考になる)
クレジットカード会社が注意書き掲載してます(おそらく一番早く掲載した三井住友カード [smbc-card.com])。
が、各社似たりよったりで「ひな形でもあるのかよ！」って感じ。
セゾン/UCカードは「現在、本件に関するお問い合わせが大変多くなっており、当社インフォメーションセンターの電話が大変繋がりにくくなっております。何卒ご容赦くださいますようお願い申しあげます。」という一文が追加されていますが、この辺のコールセンター増強対応費用も請求できるんですかねぇ？(単にGW対応で混んでるんじゃないの？)
※今日セゾンに電話したら、比較的短時間でオペレーター出たよ
パスワードをすぐに変更できるのか？ (スコア:1, すばらしい洞察)
一刻も早く対処しようとして必死にログインしようとするユーザに対して、不正ユーザと見なした処置が施されて、さらに酷い状態になり、それに対してクレームを言うと「不正にログインされて困った事が起こるよりいいでしょ。」という対応をしてしまったために、混乱が混乱を呼ぶ状態になり、・・・
なんか別の方法を考えておいた方がよさそうですよ、粗煮飯さん。
Re:パスワードをすぐに変更できるのか？ (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
Re: (スコア:0)
ファームウェアをアップデートして、再起動すると、PSNのパスワード変更を強要されるという感じみたい。
賠償費用は2兆円以上？ (スコア:1, 興味深い)
ソニー、賠償２兆円超える可能性も 次期トップ争いに大きな影響 [msn.com]
さよならPS4・・・ソニーはこの先生きのこれるのだろうか？
もう想定外の天災ということで免責してもらうか、政府に立て替えてもらう、または国有化しかないかもしれない。
＃ お詫びとしてPSNポイント配布・・・とかでお茶を濁すのが（会社的に）ベストっぽいけど、ここまで話題になるとたぶんそれだけじゃ無理だよね？
Re:賠償費用は2兆円以上？ (スコア:2)
本当に必要なら支払えばいいけど、欧米のバッシングの対象になりそうで怖い。トヨタのプリウスしかり。今回はプリウスと違って、完全に流出しているが。
2兆円の算出とかは、それから来ているのかな？とも。素人判断なら、4桁億円が妥当でしょう、と思いましたが。
-- gonta --
"May Macintosh be with you"
タイミングが悪すぎる… (スコア:1, すばらしい洞察)
このタイミングじゃ、
タブレットPCの発表まで公表しなかった＝ユーザ軽視企業
と思われてもしかたない。
＃しかし「わたしはXboxでよかった」はないだろ＞某新聞記事
Re:賠償費用は2兆円以上？ (スコア:1)
>もう想定外の天災ということで免責してもらうか、
その理屈が通るなら、頭悪い奴が最強だな。
PlayStationNetwork(PSN)のセキュリティは低かった?? (スコア:1, 参考になる)
PSNのフロントサーバはApacheとPHPで、
セキュリティパッチが当たっていなかったようです。
（真偽の程は分かりませんが）
Re:PlayStationNetwork(PSN)のセキュリティは低かった?? (スコア:1)
仮にここで書かれてることが本当だとして、（まあ日本企業ではありそうな話なんだが、）
PHPと聞いた時点で、セキュリティ対策する気があったのか疑問だったりする。
＃実際に使っていて、最も悲しくなる言語がＰＨＰだった。
どうせプログラマに払う金をケチるためのPHP採用なんだろうし、そういう
「鉄筋減らしてコストダウン」を狙う組織が、品質やセキュリティ対策のために
追加の金を払うとは、あまり期待できないのである。
説明の途中ですが、ここでCMです (スコア:0)
Re:説明の途中ですが、ここでCMです (スコア:1)
Re:説明の途中ですが、ここでCMです (スコア:1)
同志newspeak、新言法 [wikipedia.org]においてもはや"sorry"は動詞もしくは名詞なのです。
形容詞として使う場合には"sorryful"としなければなりません。
どうやら君は新言法に対する理解が不足しているようですね。愛情省へご同行願えますか？
Re: (スコア:0)
「目指してる 未来が違う」 コレジャナイ
＃最初、マジに間違えそうになったのでＡＣ
＃「目の付け所がシャープでしょ」なら間違えることはなかったのに。。。
パスワードリセットはしないの？ (スコア:0)
＞サービスが再開されたらパスワードをすぐに変更する必要がある。
パスワードのリセットをしたらいいんじゃないかと思うんだけど
連絡先がクラックされてたら更に傷口広げるからしないのがこういう場合の定石なのかな？
Re:パスワードリセットはしないの？ (スコア:1)
全情報が漏れた場合、どうやって本人確認すんのか、本物からの通知を確認するのかとかの問題も。
リセットだけならできるけど、ユーザーだけに再設定してもらう方法が難しいと。
Re: (スコア:0)
タレコミにあるPlayStation Blogの方には、ネットワークが復旧した時点で全ユーザにパスワードを変更させる予定とありますね。（英文なので全部読んでないのと正確な訳じゃないのはごめん）
急にspamが来だしました (スコア:0)
急にマルウェア添付系の英語spamが来だしたけどやっぱりそういう事か…
潰れて欲しいわ。
Re:急にspamが来だしました (スコア:2)
Re: (スコア:0)
高級レストラン印の高級スパムでござ～い。
個別ユーザーへの告知はどうなっているんだろう (スコア:0)
Important information regarding PlayStation Network and Qriocity services
というサブジェクトのメールが来たけど、日本のアカウントの方には来ないなあ。
というかPlayStation_Network@playstation-email.comは信頼できるメールアドレスなんだろうか。
Re:個別ユーザーへの告知はどうなっているんだろう (スコア:4, 参考になる)
info@psn.jp.playstation.com
からメールがきてました。
正規メールはplaystation.comドメインになる様です。
私のUSアカウントには
PlayStation_Network@playstation.innovyx.net
PlayStation_Network@playstation-email.com
からメールがきてましたが、内容的にもPSNのパスワードを要求したりと、フィッシングっぽいです。
というかUSアカウント用メールは、PSN専用で、今までSPAMが来たことが
なかったので、もう既にSPAM業者の手元に渡ってしまったということでしょうか。
Re:個別ユーザーへの告知はどうなっているんだろう (スコア:1, 参考になる)
メールのFromアドレスなんて、偽装し放題で何のあてにもならないと思うんですが…。
ドメインが何であっても。
メールから、EV-SSLに対応したplaystation.comのwebサイトに飛ばす
ぐらいの事をしないと、信頼性は確保できないかも。
Re: (スコア:0)
いまなら偽サイト作って、パスワードの修正させる振りしてアカウント盗むのが簡単に成功しそうだ。
Re:個別ユーザーへの告知はどうなっているんだろう (スコア:1, 参考になる)
個人情報漏れましたので、賠償金のお支払いをします。つきましては…
ってメールがもう届いている（英文だったけど)
何も信じたくない 信じられない
過去の例 (スコア:0)
昨年11月にPSNのアカウントがハッキングされたという方の話。
http://d.hatena.ne.jp/Nachbar/20110428/p2 [hatena.ne.jp]
私が思う疑問は、本当にここ最近だけの被害なの？というところ。
他のサービスでアカウントハッキング被害が発生したら、たとえ被害が限定的であっても
ユーザーにアナウンスはすると思うんですが、PSNについては全然そんなの見かけなかったです。
実は散々被害が出てたのにひた隠しにしていたのでは、と疑問が…。
どうも今回の後手後手なアナウンス状況を見ているとそう思わざるをえないわけですよ。
Re: (スコア:0)
そのハック事件ではツイッターやはちま奇稿、俺的ゲーム速報jinなどのブログを使って
信者達が被害者をボコボコに炎上させてましたね
そういう周りを取り囲む人間も含めた体質が今の事件に繋がっているんでしょう
暗号化されてても・・・ (スコア:0)
以前からマスターキーが解読されたり、様々なセキュリティ問題があったのに今さら信用したくてもできない・・・。
その暗号化を複合するキーもサーバーから一緒に流出していそうな気がする。
Re: (スコア:0)
そしてさらにメールで問い合わせようとすると
住所、電話番号全て必須入力のフォームが現れるのです！
復旧予定 (スコア:0)
Re:皆さん嬉しそうですねえ (スコア:1)
むしろ「自己責任」というマジックワードが飛び出すのではないですか。