アカウント名:
パスワード:
エンコード(暗号化)前の文字列とエンコード後の文字列をそれぞれ何らかの形式で巨大な対照表として持たせ、エンコード後の文字列からエンコード前の文字列を辞書のように引いてパスワードを解決するというやり方で、古来から行なわれてきたごくありふれた手法だと思うのですが。。 現に私自身も何年か前、4文字以内のパスワードという限定付きでPC上にて試したことが
「すべての文字を大文字に変換する」「
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
別に真新しいことは何もないのでは。。 (スコア:2, すばらしい洞察)
エンコード(暗号化)前の文字列とエンコード後の文字列をそれぞれ何らかの形式で巨大な対照表として持たせ、エンコード後の文字列からエンコード前の文字列を辞書のように引いてパスワードを解決するというやり方で、古来から行なわれてきたごくありふれた手法だと思うのですが。。
現に私自身も何年か前、4文字以内のパスワードという限定付きでPC上にて試したことが
Re:別に真新しいことは何もないのでは。。 (スコア:1, 参考になる)
たれ込みではリンクされてませんが、ZDNetによると [zdnet.co.jp]、Windowsで使われているLANManスキームでは以下のような問題があるそうです。
Re:別に真新しいことは何もないのでは。。 (スコア:0)
「確か」ですかね。
OSは何であれ、既存のシステムでは管理者が頑張り、ユーザも協力するしかない点においては変わりはありませんね。
この類の不勉強からくる難癖には辟易しているところ。
簡単に説明すると、ZDNetの記事はLM認証のみです。
記事に付け加えるならば、7バイトで区切り、7バイト未満は0x00でパディングされます。さらにDES処理で使用する鍵は有名な"KGS!@#$%"です。
LM認証の最大の問題は、オリジナルのパスワードが7バイト以下であった場合、キャプチャしたLMレスポンスから「7バイト以下であることが第三者に知れてしまう」ことで
Re:別に真新しいことは何もないのでは。。 (スコア:0)
任意の値を持たない LMハッシュと SALT+MD5 ハッシュを比較すれば「少々の差ではないことは確か」でしょう。LM 認証のヘボさはご自身も認めてますよね。
>OSは何であれ、既存のシステムでは管理者が頑張り、ユーザも協力するしかない点においては変わりはありませんね。
ずいぶんと次元が飛躍しますね。そういうことなら、指紋認証とか虹彩認証でも使えばよろしいのでは。何か勘違いされているようです
Re:別に真新しいことは何もないのでは。。 (スコア:0)
そう、LM認証がヘボいことは今更な話。もちろん知らない人も多いわけですが、機能だけを論じて何の意味があるのか...
> 何か勘違いされているようですが、Follow 元の方も「Windows はダメ、UNIX ならカンペキ!」と言ってるわけではないでしょう?
そう言われているのだと解釈しております。:p