アカウント名:
パスワード:
Firefox では Bug 147777 [mozilla.org] で対応済みのはずの問題ですが、今更話題になるということは、何か抜け道があったということでしょうか。時間計測攻撃は最初から、 SVG filter を使う話はたぶん 2008 年に出ています。どっちも 2010 年の時点で対応済みのはずなのですが。
それはCSSの色設定を取得する手法で、今回のは、描画時間を計測する手法とのことで、異なる手法を用いていることになりますが、CSS問題のときに、今回の問題も対応されているはずだということでしょうか。
リンク色についても(描画時間に違いが出る可能性のある)透明度の変更は認めないなど、タイミング攻撃対策は行なっていないわけではないのですが、履歴へのアクセス時間の差異はかなりどうしようもない感じがしますね。
ってか当のバグに「タイミング攻撃問題は未解決だよ」って書いてあった。https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c294 [mozilla.org]関連してそうなバグが未解決なことからも解決の困難さがうかがえる。https://bugzilla.mozilla.org/show_bug.cgi?id=557579 [mozilla.org]https://bugzilla.mozilla.org/show_bug.cgi?id=557655 [mozilla.org]
知りませんでした。情報ありがとうございます。
ランダムに遅延入れても人間相手なので問題無いとおもいますが、そんな単純な事じゃないっていうことでしょうか？
> 人間相手JavaScriptで機械的に計測してるんじゃないの?コンマ数秒リンクの反応が遅れただけで○○$の収入の減少に直結するとかamazonもGoogleも研究結果出してるし、ブラウザはものすごいスピード競争してるってのに人間相手でも現実的な対策とは思えない。
Javascriptで取得できる時間の方を（秒未満だけ）ランダムに進むようにすればいいんじゃないか？
アホか、悪影響の方が大きすぎるわ。むしろ最近ナノ秒単位で取得できるようになったってのに、時間をナメすぎ。
単純にランダムな遅延を入れただけでは、多数のデータの統計を取ると、結局ノイズから信号が浮かび上がってきますよ。もちろん困難さは増加するので、ちょっとした緩和策としてはいいのですが。
パスワードクラックの古典的手法で同じ（反応時間の差で正解の文字を求める）のがあったけど、それの対策するのにアセンブラレベルで処理数同じにする必要とかあったからなあ。
SSLでもあった。https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0169 [mitre.org]
近年の CPU では高速化のためのテクノロジのせいでステップ数が同じでも実行時間に差がでたりしそうですね…
BCASのカードがクラックされる原因になったのもこれ。東芝か松下かどっちかのカードについて、パスワードに対する応答時間が入力文字列依存で変わってしまう事象があったことを応用して解析した模様.....。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
抜け道? (スコア:2)
Firefox では Bug 147777 [mozilla.org] で対応済みのはずの問題ですが、今更話題になるということは、何か抜け道があったということでしょうか。時間計測攻撃は最初から、 SVG filter を使う話はたぶん 2008 年に出ています。どっちも 2010 年の時点で対応済みのはずなのですが。
Re: (スコア:0)
それはCSSの色設定を取得する手法で、今回のは、描画時間を計測する手法とのことで、異なる手法を用いていることになりますが、CSS問題のときに、今回の問題も対応されているはずだということでしょうか。
Re: (スコア:0)
リンク色についても(描画時間に違いが出る可能性のある)透明度の変更は認めないなど、タイミング攻撃対策は行なっていないわけではないのですが、履歴へのアクセス時間の差異はかなりどうしようもない感じがしますね。
Re:抜け道? (スコア:4, 参考になる)
ってか当のバグに「タイミング攻撃問題は未解決だよ」って書いてあった。
https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c294 [mozilla.org]
関連してそうなバグが未解決なことからも解決の困難さがうかがえる。
https://bugzilla.mozilla.org/show_bug.cgi?id=557579 [mozilla.org]
https://bugzilla.mozilla.org/show_bug.cgi?id=557655 [mozilla.org]
Re:抜け道? (スコア:2)
知りませんでした。情報ありがとうございます。
Re: (スコア:0)
ランダムに遅延入れても人間相手なので問題無いとおもいますが、そんな単純な事じゃないっていうことでしょうか？
Re: (スコア:0)
> 人間相手
JavaScriptで機械的に計測してるんじゃないの?
コンマ数秒リンクの反応が遅れただけで○○$の収入の減少に直結するとかamazonもGoogleも研究結果出してるし、ブラウザはものすごいスピード競争してるってのに人間相手でも現実的な対策とは思えない。
速度が変えられないなら、時間の方を変えればいい (スコア:0)
Javascriptで取得できる時間の方を（秒未満だけ）
ランダムに進むようにすればいいんじゃないか？
Re: (スコア:0)
アホか、悪影響の方が大きすぎるわ。
むしろ最近ナノ秒単位で取得できるようになったってのに、時間をナメすぎ。
Re: (スコア:0)
単純にランダムな遅延を入れただけでは、多数のデータの統計を取ると、結局ノイズから信号が浮かび上がってきますよ。
もちろん困難さは増加するので、ちょっとした緩和策としてはいいのですが。
Re: (スコア:0)
パスワードクラックの古典的手法で同じ（反応時間の差で正解の文字
を求める）のがあったけど、それの対策するのにアセンブラレベルで処理数
同じにする必要とかあったからなあ。
Re: (スコア:0)
SSLでもあった。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0169 [mitre.org]
Re: (スコア:0)
近年の CPU では高速化のためのテクノロジのせいでステップ数が同じでも実行時間に差がでたりしそうですね…
BCASも (スコア:0)
BCASのカードがクラックされる原因になったのもこれ。
東芝か松下かどっちかのカードについて、パスワードに対する応答時間が入力文字列依存で変わってしまう事象があったことを応用して解析した模様.....。