アカウント名:
パスワード:
saltをつかったハッシュで暗号してたってことだからリセットするって事はsaltとその計算式まで漏れたって事かねぇ?
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。というかパスワードが漏れたのにその他の秘密情報だけ都合よくもれないなんてことありうるの?
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。
その通りです。
なので、ソルトの値とハッシュ値から元のパスワードに戻すためにはブルートフォースしか無いです。
ハッシュ値の計算に関して、具体的な記述を見つけていませんが、ブルートフォースによる解析の最短記録は、パスワード長が 8 文字までの NTLM ハッシュ(パスワードの Unicode 表記に対して MD4)を、GPU 25 個を使うクラスタで 5 時間半、という記録はあります。 8文字の全パスワードを5時間半で解析するコンピュータクラスタが登場 - CNET [cnet.com]
仮に、Evernote が使っていたハッシュ値の計算が MD4 だったと
5000万ユーザのハッシュされた状態のパスワードが盗まれた。メールアドレスとかの個人情報も。
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ?って探せば短時間で見つけられると思う。
辞書を元にして、大量の単語をsaltを元にハッシュ化して、それらを5000万のリストから探してもいい。全員ではないにしろ、少なくないパスワードが漏えいしたと考えていいと思う。
だから、全ユーザのパスワードをリセットする必要が出てしまった。
問題はこれで収まらない。メールアドレスも漏れていることから、パスワードを使いまわしている人の他のサービスのアカウントも盗まれたかもしれない。
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ? って探せば短時間で見つけられると思う。
それなら、ハッシュ値すら要らない。アカウント情報だけあれば、正面切って「password」というパスワードを試せば良いだけ。さすがに、同じクライアントから試せば、サーバサイドでロックアウトも可能だから、Botnet を使わないとうまくいかない、とか、効率は悪いだろうけど、いくつか見つけられるでしょう。そんなパスワードを付けているユーザなら、パスワードリセットがあっても、放置するか、結局同じパスワードを設定するか(今回の件で、同じパスワードが設定できるかどうかは知りませんが、いくつかのパスワード変更を繰り返せば、以前のパスワードを設定するのは可能だろうし)。
ソルト付きのハッシュ値でパスワード情報を保存しているのであれば、たとえそれらが漏れても、エンドユーザが安全なパスワードを設定していれば、充分に時間稼ぎはできる。安易なパスワードを付けたユーザを守る方法なんて、無いと思うなぁ。100 回のストレッチングで、パスワード長を1文字長くしたのと同じ効果は得られるけど、それだって、辞書攻撃で破られるようなパスワードには焼け石に水。
#もう、パスワード長は最低 10 文字で良いと思う今日この頃。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
まいなびにゅーすによると (スコア:0)
saltをつかったハッシュで暗号してたってことだから
リセットするって事は
saltとその計算式まで漏れたって事かねぇ?
Re: (スコア:0)
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。
というかパスワードが漏れたのにその他の秘密情報だけ都合よくもれないなんてことありうるの?
Re: (スコア:1)
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。
その通りです。
なので、ソルトの値とハッシュ値から元のパスワードに戻すためにはブルートフォースしか無いです。
ハッシュ値の計算に関して、具体的な記述を見つけていませんが、ブルートフォースによる解析の最短記録は、パスワード長が 8 文字までの NTLM ハッシュ(パスワードの Unicode 表記に対して MD4)を、GPU 25 個を使うクラスタで 5 時間半、という記録はあります。
8文字の全パスワードを5時間半で解析するコンピュータクラスタが登場 - CNET [cnet.com]
仮に、Evernote が使っていたハッシュ値の計算が MD4 だったと
Re:まいなびにゅーすによると (スコア:0)
5000万ユーザのハッシュされた状態のパスワードが盗まれた。
メールアドレスとかの個人情報も。
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ?
って探せば短時間で見つけられると思う。
辞書を元にして、大量の単語をsaltを元にハッシュ化して、それらを5000万のリストから探してもいい。
全員ではないにしろ、少なくないパスワードが漏えいしたと考えていいと思う。
だから、全ユーザのパスワードをリセットする必要が出てしまった。
問題はこれで収まらない。
メールアドレスも漏れていることから、パスワードを使いまわしている人の他のサービスのアカウントも盗まれたかもしれない。
Re:まいなびにゅーすによると (スコア:2)
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ? って探せば短時間で見つけられると思う。
それなら、ハッシュ値すら要らない。アカウント情報だけあれば、正面切って「password」というパスワードを試せば良いだけ。さすがに、同じクライアントから試せば、サーバサイドでロックアウトも可能だから、Botnet を使わないとうまくいかない、とか、効率は悪いだろうけど、いくつか見つけられるでしょう。そんなパスワードを付けているユーザなら、パスワードリセットがあっても、放置するか、結局同じパスワードを設定するか(今回の件で、同じパスワードが設定できるかどうかは知りませんが、いくつかのパスワード変更を繰り返せば、以前のパスワードを設定するのは可能だろうし)。
ソルト付きのハッシュ値でパスワード情報を保存しているのであれば、たとえそれらが漏れても、エンドユーザが安全なパスワードを設定していれば、充分に時間稼ぎはできる。安易なパスワードを付けたユーザを守る方法なんて、無いと思うなぁ。100 回のストレッチングで、パスワード長を1文字長くしたのと同じ効果は得られるけど、それだって、辞書攻撃で破られるようなパスワードには焼け石に水。
#もう、パスワード長は最低 10 文字で良いと思う今日この頃。