アカウント名:
パスワード:
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
の3通りが考えられそうです。 2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので 平文でなくても変更を呼びかける可能性はあるでしょう。
2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ) それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
パスワードは平文で保存してたのでしょうか (スコア:4, すばらしい洞察)
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。
ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、
ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。
専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
Re: (スコア:2, 参考になる)
の3通りが考えられそうです。
2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
平文でなくても変更を呼びかける可能性はあるでしょう。
ハッシュ値で保存していてもパスワードは変更させるべき (スコア:3, すばらしい洞察)
2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで
Re: (スコア:3, 参考になる)
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
Re: (スコア:0)
SHA1やSHA256などなど、衝突困難性は数学で証明されてるだろう。
(現時点で衝突を見つける効率的なアルゴリズムは発見されていないという意味)
>> 例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
>>
>> abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'
>> def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874645a183565'
>>
>>と別のハッシュ値になるよう実装すべきです。
ここに関してはある程度同意で
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:2)
安易なパスワードを使うユーザは他のサイトでも同じパスワードを使っている場合が多いので、該当ユーザのユーザ名やメールアドレスを使って他のサイトでパスワードを試されれば一度に数千ユーザのパスワードを知られてしまいます。
この場合複数のサイトで複数のアカウントでパスワードを試されるので検出は難しくなります。
攻撃者が他サイト(攻撃者が作ったサイトを含む)でのユーザ名とパスワードの対応表を持っていればより少ない試行でパスワードを知られてしまいます。
この攻撃はサーバのプログラムや秘密鍵が流出していなくてもデータベースの情報のみで成立してしまいますし、ハッシュ関数が暗号学的に強固でも受けてしまいます。
一方でパスワードが同じでもユーザごとにハッシュ値を変えれば、安易なパスワードを使っているユーザを攻撃者に知られないので各ユーザに対する攻撃の成功率はずっと下がりますし、1ユーザのパスワードを知られてしまっても他ユーザのパスワードは守れます。
また、プログラムと秘密鍵を知られてしまった場合でも、総当たり的な攻撃に強くなります。
ハッシュ関数が暗号学的に強固で一般的な攻撃に強かったとしても、プログラムと秘密鍵を知られている場合、パスワードの総当たりである程度のユーザのパスワードを知られてしまいます。
しかしこのときハッシュ値をユーザごとに変えない場合、1回の攻撃で全ユーザ分攻撃されてしまいますが、ユーザごとに変えた場合、攻撃者は1ユーザごとに攻撃しないといけないので時間はずっとかかるようになります。
このようにハッシュ値をユーザごとに変えるようにすると漏洩してしまったときの耐久性を大幅に上げられます。
一方で実装する手間はパスワードをハッシュ値にかける前にユーザIDを連結しておくだけなのでほとんどかかりません。
わずかな手間でデメリットも少なく、得られるものは多いのでぜひ「するべき」ではないでしょうか。