アカウント名:
パスワード:
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
の3通りが考えられそうです。 2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので 平文でなくても変更を呼びかける可能性はあるでしょう。
2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ) それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874
ちょっと誤解されすぎなので全部はレスしませんが、前述のハッシュ値はSHA256で求めたものですよ…。 ハッシュ関数自体を独自に作るのではなく、ハッシュ関数の利用方法の話です。>ソルト&ストレッチング
PHPだとこんなコードです。(わざとダサく書いてます)
$salt = $id . 'himitunomojiretsu'; //(ユーザー毎に違う)ソルト$hash='';for ($i = 0; $i<1090; $i++) { //ストレッチング $hash = hash('sha256', $hash . $pwd . $salt);}
こう「するべき」である理由は、貴方も仰ってる↓の点などです。
ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。
実装コードが漏れた場合、同じコードで元パスワードを推測
故意にコードを簡略化したのかもしれませんが、流石にそのコードだとSHA256と仮定して元の値を1度見つけるだけで
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXpasswordabchimitunomojiretsu
『65文字目からユーザーIDが見つかるまでの間か、ユーザーID直後の文字が多分パスワード』と推測可能ですよ。
ストレッチングした意味があるようで無いような…w まあ65文字オーバー対応のレインボーテーブル等が実用化しない限り気にしなくてもいいかもしれませんけど。
ストレッチングした意味があるようで無いような…w
ストレッチングの意味は、保存内容と適当なパスワードのハッシュ値の『比較に要する時間を延ばす』ことですね。 難読化の意味合いで使う物では無いと思います。
指摘されてる問題点については、原像計算困難性次第です。 保険的に単純結合以外を使っても良いですが、ソルトを含めて(ハッシュ前の値が)長い文字列になる事をまず優先してください。
より多くのコメントがこの議論にあるかもしれませんが、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: (スコア:1)
ちょっと誤解されすぎなので全部はレスしませんが、前述のハッシュ値はSHA256で求めたものですよ…。
ハッシュ関数自体を独自に作るのではなく、ハッシュ関数の利用方法の話です。>ソルト&ストレッチング
PHPだとこんなコードです。(わざとダサく書いてます)
こう「するべき」である理由は、貴方も仰ってる↓の点などです。
ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。
実装コードが漏れた場合、同じコードで元パスワードを推測
Re: (スコア:0)
故意にコードを簡略化したのかもしれませんが、流石にそのコードだとSHA256と仮定して元の値を1度見つけるだけで
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXpasswordabchimitunomojiretsu
『65文字目からユーザーIDが見つかるまでの間か、ユーザーID直後の文字が多分パスワード』と推測可能ですよ。
ストレッチングした意味があるようで無いような…w
まあ65文字オーバー対応のレインボーテーブル等が実用化しない限り気にしなくてもいいかもしれませんけど。
Re:ハッシュ値で保存していてもパスワードは変更させるべき (スコア:1)
ストレッチングした意味があるようで無いような…w
ストレッチングの意味は、保存内容と適当なパスワードのハッシュ値の『比較に要する時間を延ばす』ことですね。
難読化の意味合いで使う物では無いと思います。
指摘されてる問題点については、原像計算困難性次第です。
保険的に単純結合以外を使っても良いですが、ソルトを含めて(ハッシュ前の値が)長い文字列になる事をまず優先してください。