パスワードを忘れた? アカウント作成
6214 story

Windowsログインパスワードを高速クラック 51

ストーリー by Oliver
求むパスフレーズ文化 部門より

downburst 曰く、 "スイスの科学者が、英字と数字の組み合わせで構成される暗号化されたパスワードの解析の高速化手法を用いて、Windowsのログインパスワードを高速に解析する方法を発表したとCnet Newsが伝えています(日本語訳はとりあえずYahoo!)。大規模ルックアップテーブルを使って2分近くかかっていた解析時間を十数秒まで縮めることに成功したそうです。
もともとWindowsのパスワードの暗号化アルゴリズムは「出来がよくない」そうで、研究者は「新たな脆弱性が見つかったわけというわけではない」「Microsoftのパスワードは、理論的な結果をデモするための格好の例だったにすぎない」と主張しておられますが・・・・・
ちなみに、Web上から簡単に試すことが出来ます。私もWindowsのGuestアカウントを使って試してみたんですが、「a1u30ka」という文字列を1秒でさくっと解析したそうです(結果はメールで送付されます)。ただし、\マークなどの記号を含むパスワードはまだ解析できないそうです。
まあ、すぐにどうこうという訳じゃなさそうなんですが、念のために変えておこうかなぁ、ログインパスワード・・・・"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 参考記事 (スコア:3, 参考になる)

    by oddmake (1445) on 2003年07月26日 20時16分 (#366146) 日記
    本家にも投稿されております。
    Swiss Researchers Exploit Windows Password Flaw [slashdot.org]
    本家Geekもいろいろと意見を述べられておりますので、参考にすると良いと思われます。
    --
    /.configure;oddmake;oddmake install
  • by Anonymous Coward on 2003年07月26日 18時45分 (#366100)

    エンコード(暗号化)前の文字列とエンコード後の文字列をそれぞれ何らかの形式で巨大な対照表として持たせ、エンコード後の文字列からエンコード前の文字列を辞書のように引いてパスワードを解決するというやり方で、古来から行なわれてきたごくありふれた手法だと思うのですが。。
    現に私自身も何年か前、4文字以内のパスワードという限定付きでPC上にて試したことがあります。

    Windowsに限らずUNIX系OSでも少々の程度の差こそあれ同じことが言えます。特にWindowsだけが設計上脆弱だとか言うものではないと思います。ただ、NT時代からの伝統を頑なに守ってしまった(暗号化にパスワード以外の種を利用していないなど)が故に古い設計になっているのはその通りですけど。

    • by Anonymous Coward on 2003年07月27日 14時18分 (#366320)
      >Windowsに限らずUNIX系OSでも少々の程度の差こそあれ同じことが言えます。

      たれ込みではリンクされてませんが、ZDNetによると [zdnet.co.jp]、Windowsで使われているLANManスキームでは以下のような問題があるそうです。
      「すべての文字を大文字に変換する」「パスワードを7バイトに分割する」「SALTと呼ばれる、暗号化のための無作為の文字列を使わない」


      少なくとも「少々」の差ではないことは確かだと思います。
      親コメント
      • >少なくとも「少々」の差ではないことは確かだと思います。

        「確か」ですかね。
        OSは何であれ、既存のシステムでは管理者が頑張り、ユーザも協力するしかない点においては変わりはありませんね。
        この類の不勉強からくる難癖には辟易しているところ。

        簡単に説明すると、ZDNetの記事はLM認証のみです。
        記事に付け加えるならば、7バイトで区切り、7バイト未満は0x00でパディングされます。さらにDES処理で使用する鍵は有名な"KGS!@#$%"です。
        LM認証の最大の問題は、オリジナルのパスワードが7バイト以下であった場合、キャプチャしたLMレスポンスから「7バイト以下であることが第三者に知れてしまう」ことで
        • >「確か」ですかね。

          任意の値を持たない LMハッシュと SALT+MD5 ハッシュを比較すれば「少々の差ではないことは確か」でしょう。LM 認証のヘボさはご自身も認めてますよね。

          >OSは何であれ、既存のシステムでは管理者が頑張り、ユーザも協力するしかない点においては変わりはありませんね。

          ずいぶんと次元が飛躍しますね。そういうことなら、指紋認証とか虹彩認証でも使えばよろしいのでは。何か勘違いされているようです
          • >LM 認証のヘボさはご自身も認めてますよね。
            そう、LM認証がヘボいことは今更な話。もちろん知らない人も多いわけですが、機能だけを論じて何の意味があるのか...

            > 何か勘違いされているようですが、Follow 元の方も「Windows はダメ、UNIX ならカンペキ!」と言ってるわけではないでしょう?

            そう言われているのだと解釈しております。:p
    • 最近の UNIX 系の認証では PAM などの機構により、パスワードのエンコード方法などが
      任意に変更できるので、この手法が常に有効ではありえないのでは?

      WINDOWS の認証機構は詳しくないので、もしかしたら pluggable なのかもしれませんが・・・。
      • by Anonymous Coward on 2003年07月26日 20時51分 (#366154)

        #366100のACです。

        pamやshadowで様々なエンコード(暗号化、ダイジェスト化)をしたところで対照表が1個からn個になるだけなので、解読できる時間には何ら変わりがないと思います。ましてやエンコードされたパスワードからエンコード方法が一発で判断できてしまいますから、時間稼ぎにすらなりえません(対照表を作るための時間は今回の計測対象ではありませんし)。

        今回の肝は「Windowsのパスワード保存方法が脆弱」ということではなく、「今あるちょっと良い程度のスペックのPCをもってすれば暗号化されたパスワードを容易に解読できるので、パスワードの暗号化はあくまでも気休め(何もしていないよりはマシ)程度に思っておくべきだ」ということだと思います。
        どのようなシステムでも同じですが、万が一にでもパスワードファイルやパスワードデータベースにアクセスさせない環境作り(パーミッション、セキュリティ設定他)をするべきでしょう。

        ちなみに今回の件への対策としては、LANMANハッシュを作成しないという手法を取ることができます。詳しいことは しかP氏 [rim.or.jp] のページ内にある "Top twenty security hole from SANS.org" [rim.or.jp] という箇所 (W6.4 対処方法) にありますので参考にどうぞ。

        親コメント
        • #366116 な AC です。
          ストーリーをよく読んでいなかったので前提を勘違いしていました。
          ターゲットとなるシステムのアカウントとエンコードされたパスワードが
          既に入手されていて、その上での解析ですね。
          その時点では PAM は関係ないので、おっしゃる通りです。
        • >pamやshadowで様々なエンコード(暗号化、ダイジェスト化)をしたところで対照表が1個からn個になるだけなので、解読できる時間には何ら変わりがないと思います。

          対照表が n 個になれば検索時間も n 倍かかるような気がするの ですが違うのでしょうか? というか、一般的に UNIX の cyrpt関 数で使われている SALT=n に思えるのですが...
          • > 対照表が n 個になれば検索時間も n 倍かかるような気がするのですが違うのでしょうか?

            n倍が、13.6秒のn倍なら意味無いですね。
          • >対照表が n 個になれば検索時間も n 倍かかるような気がするのですが違うのでしょうか?

            本質を見誤ってるよ。
            何秒で解けるか、はさして問題ではなくて、
            「簡単に解けてしまうのか?」が重要だと思う。

            解読に1秒でもその前にユーザが気がついてシャットアウトできれば問題ないし、
            3日かかってもユーザが放置していれば乗っ取られるわけで。
            • by Anonymous Coward on 2003年07月27日 14時44分 (#366327)
              >本質を見誤ってるよ。 何秒で解けるか、はさして問題ではなくて、 「簡単に解けてしまうのか?」が重要だと思う。

              「本質」ってなんですか? 今回の解読手法(というほどでもないが) を使えば、あらゆる暗号は「簡単に解けてしまう」と思いますけ ど。もちろん無限のメモリと超高速の CPU があれば、という条件付きですが :-)

              >解読に1秒でもその前にユーザが気がついてシャットアウトできれば問題ないし、3日かかってもユーザが放置していれば乗っ取られるわけで。

              3 日ならばそうでしょうけど、それが 1000年だったら意味があると思いませんか? それこそ暗号化の本質だと思いますけど...?
              親コメント
    • つまり、何もしなかったということです。
  • (スコア:2, 興味深い)

    by take0m (4948) on 2003年07月27日 2時53分 (#366255) 日記
    SunOSだったころ、なんと管理者の人がrootのパスワードを忘れてしまい、アルファベットのみ(記号と数字は含まず)ってことは覚えていたので、辞書作って、コード書いて、解析初めて数時間で見つかりました。今じゃアルファベットだけなんてパスワードは使えない所が多いですから、こんな楽な訳ないですけどね。
    ちなみに見つかったパスワードは、ちょっとここでは書けないものでした・・・

    それ以来、私も、ばれた時の事も考えてパスワードを決めるようにしました。
    • Re:昔 (スコア:2, すばらしい洞察)

      by sotanaka (9676) on 2003年07月27日 10時09分 (#366278)
      そんなーーー
      L1+A で落として single user mode でリブートすれば パスワード変更できるじゃん。
      親コメント
      • by take0m (4948) on 2003年07月27日 21時05分 (#366615) 日記
        あれ、リモートからでもできましたっけ?
        マシンから遠く離れたところでのできごとでしたので・・・
        親コメント
        • by Anonymous Coward
          おちつきましょう。

          single user modeでリモートはありえませんよ。
          #interfaceのupさせるトコまでやっちゃったrcスクリプト書いたら
          #別でしょうけど。
        • by Anonymous Coward
          シリアルコンソールにしてあり、そのシリアル線にリモートから
          アクセスできるようにしてあれば、リモートからでもできます。
          (L1+A じゃなくて、BREAK信号になりますが。)

          遠隔管理する場合、そうする方がある意味普通のような。
          もちろん、コスト等の問題で、できないこともままありますが。
      • by Anonymous Coward
        あれ・・・

        System Maintenance Mode でパスワード要求されたような気が・・
    • by Sakura Avalon (12557) on 2003年07月27日 4時54分 (#366276)
      パスワードを探して [zdnet.co.jp]」のような事件は今後も必ず起こってくる事でしょうしねぇ。これの場合は研究者のラストネームのスペルを逆綴りにした単純なパスワードだったそうで、Webで公開する前に近場でアレゲな人を引っ張ってきていれば騒ぎにならずに済んでいたような気もしますが。

      >ちなみに見つかったパスワードは、ちょっとここでは書けないものでした・・・

      いやいや、「まさかこんなフレーズはパスワードにしないだろう」と思わせるための高尚な考えで決めたに違いありません(笑)
      親コメント
  • by Anonymous Coward on 2003年07月26日 18時30分 (#366098)
    Windows では変えても気休めにしかならないのでは。
  • by baffclan (9449) on 2003年07月26日 18時53分 (#366105) ホームページ
    と照合して解析が行えるということは、パスワードの一文字を変えてもハッシュ値には少ししか
    変化していない文字列が出てくるということでしょうか?

    なお、セキュリティホール memo [ryukoku.ac.jp]の24日にも出ており、こちら [zdnet.co.jp]の記事を
    参照しています。
    • by Anonymous Coward
      これって単に
      昔: 52^7 x 52^2 個分のパスワード対照表 => ディスクもメモリも足りなかった
      今: 96^128 個分のパスワード対照表 => ディスクもメモリもあるのでハッシングすれば素早い検索も可能
      てな意味のような気がします。

      昔はアルファベットのみ 7

      • by oltio (3848) on 2003年07月26日 22時01分 (#366172) 日記
        96^128なんて巨大なテーブルをどこのディスクに収める事ができる
        のでしょうか???いわんやメモリ上に展開するなんて無理でしょう。

        もし適当に間引くとしたら、やっぱりエンコード後文字列間の
        距離と、対応するエンコード前文字列間の距離に、何らかの
        相関性がないとつらいだろう、という意味で、baffclan氏の
        コメントが危惧している通りなのではないかと思いますが。
        親コメント
        • by Anonymous Coward
          部分的な圧縮展開の繰り返しで対応。
          • by Anonymous Coward
            圧縮展開ってサイズのことですか?
            この手の表ってそういうのが可能?
            というか、そういうことができるんだったらそもそもメモリ上に
            展開するメリットも無いはずだと思うのですけど。
    • by Anonymous Coward
      ここ [zdnet.co.jp]の
      > パスワードを7バイトに分割する
      がミソなんじゃない?
      これだとパスワードの文字数が増えても表を大きくする必要ないし。
    • by Anonymous Coward
      Windowsのパスワードは、7byte毎に別々にエンコードされてたとおもわれ
  •  学生だったころ……いまから10年前か……、電算室の
    Administratorパスワードを解析しようと電算室の
    マシン
    を使って ぶん回して計算した覚えがあります。
    たしか3日くらいかかったなぁ。
     l0phtかなんかからソースを拾ってきて当時のマシン
    2~3台で分散させてやったような。たしかPC98にNT4が
    入ってたマシンだったけどえらく遅かったよなぁ。
    #まぁIDでいいか(W
    --
    やなぎ
    字面じゃなく論旨を読もう。モデレートはそれからだ
  • 削除できるツール [agtech.co.jp]も販売されてます。 パスワードなんか設定しようが、複雑にしようが、頻繁に変えようが、全くの気休めですね。
    • >削除できるツール [agtech.co.jp]も販売されてます。

      これってローカル専用ですよね(苦笑)
      PCの目の前に物理的に侵入できる時点で、そのPCのセキュリティは
      ぼろぼろです。
  • by Anonymous Coward on 2003年07月27日 2時37分 (#366252)
    レジストリ書き換えない限りポートも決まってるし、、

    ガクガク(((゚Д゚)))ブルブル
  • by Anonymous Coward on 2003年07月27日 12時53分 (#366304)
    ああ。「あいうえおか」。
typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...