アカウント名:
パスワード:
エンコード(暗号化)前の文字列とエンコード後の文字列をそれぞれ何らかの形式で巨大な対照表として持たせ、エンコード後の文字列からエンコード前の文字列を辞書のように引いてパスワードを解決するというやり方で、古来から行なわれてきたごくありふれた手法だと思うのですが。。 現に私自身も何年か前、4文字以内のパスワードという限定付きでPC上にて試したことが
#366100のACです。
pamやshadowで様々なエンコード(暗号化、ダイジェスト化)をしたところで対照表が1個からn個になるだけなので、解読できる時間には何ら変わりがないと思います。ましてやエンコードされたパスワードからエンコード方法が一発で判断できてしまいますから、時間稼ぎにすらなりえません(対照表を作るための時間は今回の計測対象ではありませんし)。
今回の肝は「Windowsのパスワード保存方法が脆弱」ということではなく、「今あるちょっと良い程度のスペックのPCをもってすれば暗号化されたパスワードを容易に解読できるので、パスワードの暗号化はあくまでも気休め(何もしていないよりはマシ)程度に思っておくべきだ」ということだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
別に真新しいことは何もないのでは。。 (スコア:2, すばらしい洞察)
エンコード(暗号化)前の文字列とエンコード後の文字列をそれぞれ何らかの形式で巨大な対照表として持たせ、エンコード後の文字列からエンコード前の文字列を辞書のように引いてパスワードを解決するというやり方で、古来から行なわれてきたごくありふれた手法だと思うのですが。。
現に私自身も何年か前、4文字以内のパスワードという限定付きでPC上にて試したことが
Re:別に真新しいことは何もないのでは。。 (スコア:0)
任意に変更できるので、この手法が常に有効ではありえないのでは?
WINDOWS の認証機構は詳しくないので、もしかしたら pluggable なのかもしれませんが・・・。
Re:別に真新しいことは何もないのでは。。 (スコア:1, 興味深い)
#366100のACです。
pamやshadowで様々なエンコード(暗号化、ダイジェスト化)をしたところで対照表が1個からn個になるだけなので、解読できる時間には何ら変わりがないと思います。ましてやエンコードされたパスワードからエンコード方法が一発で判断できてしまいますから、時間稼ぎにすらなりえません(対照表を作るための時間は今回の計測対象ではありませんし)。
今回の肝は「Windowsのパスワード保存方法が脆弱」ということではなく、「今あるちょっと良い程度のスペックのPCをもってすれば暗号化されたパスワードを容易に解読できるので、パスワードの暗号化はあくまでも気休め(何もしていないよりはマシ)程度に思っておくべきだ」ということだと思います。
Re:別に真新しいことは何もないのでは。。 (スコア:0)
対照表が n 個になれば検索時間も n 倍かかるような気がするの ですが違うのでしょうか? というか、一般的に UNIX の cyrpt関 数で使われている SALT=n に思えるのですが...
Re:別に真新しいことは何もないのでは。。 (スコア:0)
本質を見誤ってるよ。
何秒で解けるか、はさして問題ではなくて、
「簡単に解けてしまうのか?」が重要だと思う。
解読に1秒でもその前にユーザが気がついてシャットアウトできれば問題ないし、
3日かかってもユーザが放置していれば乗っ取られるわけで。
Re:別に真新しいことは何もないのでは。。 (スコア:1, すばらしい洞察)
「本質」ってなんですか? 今回の解読手法(というほどでもないが) を使えば、あらゆる暗号は「簡単に解けてしまう」と思いますけ ど。もちろん無限のメモリと超高速の CPU があれば、という条件付きですが :-)
>解読に1秒でもその前にユーザが気がついてシャットアウトできれば問題ないし、3日かかってもユーザが放置していれば乗っ取られるわけで。
3 日ならばそうでしょうけど、それが 1000年だったら意味があると思いませんか? それこそ暗号化の本質だと思いますけど...?