アカウント名:
パスワード:
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
の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);}
こう「するべき」である理由は、貴方も仰ってる↓の点などです。
ただ辞書攻撃に引っかかるパスワードであればそのハッシュ値の対応リストも同様にあるので弱い・・・・ということになります。
実装コードが漏れた場合、同じコードで元パスワードを推測
#1944956 [srad.jp] の AC です。
これは,私が> 秘密鍵を使うようなハッシュ方法と呼んだものなので,こうしたハッシュ方法の推定が比較的困難であることには同意いたします。("himitunomojiretsu" や "1090"が「秘密鍵」。)
私の前のコメントで「オリジナルのハッシュ『関数』」と書いちゃったのが,誤解を招いてしまったかもしれません…。ハッシュ関数そのものか,それを使ってソルト&ストレッチングのような工夫をするかに拘らず,独自のパラメータ(隠すべきもの)を増やせば,その分確かに推定は困難になります。しかし,攻撃者が平文とそれに対応する暗号文の両方を持っていれば,大抵の場合は実現不可能なほどには困難ではないと思います。
これがどれほど困難かということが,独自の手法では評価できないというのが#1945087 [srad.jp]の AC さんの主張だと思いますが,これは正しい指摘で,これが噛み合っていないように見えるのは私のせいだと思います。すみません。
より多くのコメントがこの議論にあるかもしれませんが、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)
#1944956 [srad.jp] の AC です。
これは,私が
> 秘密鍵を使うようなハッシュ方法
と呼んだものなので,こうしたハッシュ方法の推定が比較的困難で
あることには同意いたします。("himitunomojiretsu" や "1090"
が「秘密鍵」。)
私の前のコメントで「オリジナルのハッシュ『関数』」と書いちゃったのが,
誤解を招いてしまったかもしれません…。
ハッシュ関数そのものか,それを使ってソルト&ストレッチングのような
工夫をするかに拘らず,独自のパラメータ(隠すべきもの)を増やせば,
その分確かに推定は困難になります。しかし,攻撃者が平文とそれに対応
する暗号文の両方を持っていれば,大抵の場合は実現不可能なほどには
困難ではないと思います。
これがどれほど困難かということが,独自の手法では評価できないというのが
#1945087 [srad.jp]の AC さんの主張だと思いますが,これは正しい指摘で,
これが噛み合っていないように見えるのは私のせいだと思います。すみません。