アカウント名:
パスワード:
同意。
復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。 ロックアウトでもいいし、1秒に1回しかログインできないとかにしてしまえばCPUでもGPUでも一緒です
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、>>ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。
そんなことはない。通信をキャプチャされれば暗号化された通信が復号される可能性はある。
ログインされることだけが損害ではない。
SSLの暗号に使われている鍵は人間様が覚えておける長さという制約のあるパスワードよりずっと長いから、破るのもはるかに困難。今のところGPUを使う程度のことではとても現実的な時間では解けない。まあ>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、これも対策はすでに考えられてて、ストレッチングと呼ばれているけど。
>通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
その共通鍵は使い捨てだから、セッションが有効なうちに解読に成功しなきゃいけない。よほど共通鍵の暗号強度が低くないかぎり、有効期限10年があたりまえなルート証明書の解析を頑張った方がマシだね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
総当たりチェックなど・・・・ (スコア:3, 興味深い)
パスワードの総当たりなど、3回試行して失敗したら30分ロックアウトするだけで、この手の物は簡単に防げるという認識は甘いでしょうか。
Re: (スコア:0)
同意。
復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。 ロックアウトでもいいし、1秒に1回しかログインできないとかにしてしまえばCPUでもGPUでも一緒です
Re: (スコア:3, 興味深い)
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、
>>ネットワーク越しの話なら、律速になるのはクラッカー側の演算能力ではないと思います。
そんなことはない。通信をキャプチャされれば
暗号化された通信が復号される可能性はある。
ログインされることだけが損害ではない。
Re: (スコア:0)
SSLの暗号に使われている鍵は人間様が覚えておける長さという制約のあるパスワードよりずっと長いから、破るのもはるかに困難。今のところGPUを使う程度のことではとても現実的な時間では解けない。
まあ
>>復号すべきデータがクラッカー側にあるのならそれ自体がすでに敗北だし、
これも対策はすでに考えられてて、ストレッチングと呼ばれているけど。
Re: (スコア:0)
SSLで鍵が長い公開鍵暗号方式が使われるのは、鍵が短い共通鍵暗号方式の鍵の授受だよ。
通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
Re: (スコア:0)
>通信内容を傍受するなら、共通鍵暗号方式で暗号化されたデータストリームに対する総当たりで済む。
その共通鍵は使い捨てだから、セッションが有効なうちに解読に成功しなきゃいけない。
よほど共通鍵の暗号強度が低くないかぎり、有効期限10年があたりまえなルート証明書の解析を頑張った方がマシだね。
Re:総当たりチェックなど・・・・ (スコア:0)
データストリームを記録しておき、あとでゆっくり解読すりゃいいじゃん。