アカウント名:
パスワード:
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
の3通りが考えられそうです。 2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので 平文でなくても変更を呼びかける可能性はあるでしょう。
2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ) それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
abc:'2f021051f8a440282f6ec79445404a683a121130b385c80f24826fdc32b28113'def:'db5b7038afdfee6227c52fd5d8d73f87d3ab3c3483120ea11aa874
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
パスワードは平文で保存してたのでしょうか (スコア:4, すばらしい洞察)
パスワードも流出して変更を呼びかけるというのは、平文か復元可能な状態で保存していたのでしょうか。
ユーザーパスワードはハッシュだけ保持するという古くから常識とされている鉄則さえ守っていれば、パスワード自体は流出しないと思うのですが、
ソニーともあろうものが世界展開するサービスでそんなズサンな実装をしていたということなのでしょうか。
専用端末からのみアクセスされるクローズドなオンラインサービスだから、クライアント側で防げば大丈夫と手を抜いてしまったという所かしら。
Re: (スコア:2, 参考になる)
の3通りが考えられそうです。
2番と3番は時間をかけて解析したり、辞書攻撃の範囲のパスワード(のハッシュ)を探したり出来ますので
平文でなくても変更を呼びかける可能性はあるでしょう。
ハッシュ値で保存していてもパスワードは変更させるべき (スコア:3, すばらしい洞察)
2,3 の前提がなくても,ハッシュ値が漏洩した時点でユーザにパスワードを変更させるべきだと思います。
辞書攻撃や総当たり攻撃に対しては,ハッシュ関数の強度よりも設定されたパスワード自体の強度の方が問題になるのではないでしょうか。
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
システム側から「パスワードはハッシュ化しているので大丈夫」なんて言ったら,それこそがズサンな対応ではないで
Re: (スコア:3, 参考になる)
ハッシュ方法については,パスワードとハッシュ値の組み合わせが一つでも分かっていれば推定可能です。
それが成り立つのが「2. 単純なハッシュ化だけだった」場合ですね。
完全オリジナルのハッシュ関数や秘密鍵を使うようなハッシュ方法ならば,推定は難しいかもしれませんが。
ハッシュ関数自体は既存のもので良いです。(弱すぎなければ)
それにソルトとストレッチング、そしてユーザーIDをうまく組み合わせて実装しましょう。
例えばユーザー"abc"とユーザー"def"が、ともに"password"というパスワードに設定していた場合でも
HMACを使えとアドバイスすべきでは? (スコア:0)
Re:HMACを使えとアドバイスすべきでは? (スコア:2)
HMACは受信したメッセージについてそれが秘密鍵を持った相手が書いたメッセージであり、内容が改竄されていないと保障するものです。
アルゴリズムとしては秘密鍵とメッセージを合わせてハッシュを計算し、それをさらに秘密鍵と合わせてハッシュを取ります(実際にはもう少し細かく規格化されています)。
なぜハッシュを1回ではなく2回取るのかというと、ある種のハッシュ関数には、メッセージの後ろに工夫したデータを付けると秘密鍵が漏れていなくてもハッシュ値を変えずにメッセージを変えられてしまう脆弱性があります。
これを防ぐために鍵付きハッシュを2回かけて1回目のハッシュ値を隠しています。
この1回だけハッシュを取る方法に対する攻撃は、攻撃者に平文メッセージが知られている場合に起きます。
しかし、パスワードを保存する用途では平文メッセージにあたるのは平文パスワードです。
当然攻撃者は平文パスワードを知りません。
そのため2回ハッシュをかける意味はないのではないでしょうか。