アカウント名:
パスワード:
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
の３通りが考えられそうです。 ２番と３番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので 平文でなくても変更を呼びかける可能性はあるでしょう。
２，３ の前提がなくても，ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては，ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら，それこそがズサンな対応ではないで
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ) それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874
少なくとも僕には、どこが間違っているのかよくわからん。
もとの人が誤解されすぎ(#1945118)と書いているけど、その通りで、セキュリティの話をする上で暗黙の前提としているところを理解してないか、難癖つけるためにわざと曲解しているようにしか思えないっす。
SHA1やSHA256などなど、衝突困難性は数学で証明されてるだろう。
以下、ハッシュ関数についてのあれこれが書かれているけど、元のコメントはそんなことは当然であり、その前提での話をしている。それらを使った上での暗号化の実装の話をしている。最後の捨て台詞みたいな、
ハッシュのアルゴリズムを自分で考えて実装するほうがめちゃくちゃ開発工数かかる。 そしてその独自ハッシュの安全性は誰が担保するんだろうね？
も、話があさっての方向を向きすぎてるというか、ハッシュ単体の話などしてないのになにを言ってるんだという感じです。「ハッシュ使えば安心」→「使った上でこういう実装にしないと [srad.jp]」→「ハッシュはそういうもんじゃないだろう」→「えっ？」って感じ。
生兵法ACの話を間違ってないと思ってしまうのは、pochi-pさんが何を言ってるのかを理解してなくて、同じ誤解をしているからじゃないでしょうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
パスワードは平文で保存してたのでしょうか (スコア:4, すばらしい洞察)
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。
ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、
ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。
専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
Re: (スコア:2, 参考になる)
の３通りが考えられそうです。
２番と３番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
平文でなくても変更を呼びかける可能性はあるでしょう。
ハッシュ値で保存していてもパスワードは変更させるべき (スコア:3, すばらしい洞察)
２，３ の前提がなくても，ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては，ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら，それこそがズサンな対応ではないで
Re: (スコア:3, 参考になる)
ハッシュ方法については，パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば，推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
Re: (スコア:0)
SHA1やSHA256などなど、衝突困難性は数学で証明されてるだろう。
（現時点で衝突を見つける効率的なアルゴリズムは発見されていないという意味）
>> 例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
>>
>> abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'
>> def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874645a183565'
>>
>>と別のハッシュ値になるよう実装すべきです。
ここに関してはある程度同意で
Re: (スコア:0)
生兵法にも程がある
Re: (スコア:0)
少なくとも僕には、どこが間違っているのかよくわからん。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:1)
もとの人が誤解されすぎ(#1945118)と書いているけど、その通りで、セキュリティの話をする上で暗黙の前提としているところを理解してないか、難癖つけるためにわざと曲解しているようにしか思えないっす。
以下、ハッシュ関数についてのあれこれが書かれているけど、元のコメントはそんなことは当然であり、その前提での話をしている。それらを使った上での暗号化の実装の話をしている。最後の捨て台詞みたいな、
も、話があさっての方向を向きすぎてるというか、ハッシュ単体の話などしてないのになにを言ってるんだという感じです。「ハッシュ使えば安心」→「使った上でこういう実装にしないと [srad.jp]」→「ハッシュはそういうもんじゃないだろう」→「えっ？」って感じ。
生兵法ACの話を間違ってないと思ってしまうのは、pochi-pさんが何を言ってるのかを理解してなくて、同じ誤解をしているからじゃないでしょうか？
LIVE-GON(リベゴン)