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

APOPにパスワード漏洩の脆弱性 65

ストーリー by yoosee
MD5の価値は下落していますね 部門より

koshian 曰く

読売新聞の記事 メールのパスワード暗号破った…APOP規格を解読 でも報じられていますが、APOPにプロトコル上の欠陥が見つかったようです。IPA でもAPOP方式におけるセキュリティ上の弱点(脆弱性)の注意喚起について と言う記事が掲載されています。これは MD5ハッシュコリジョンに基づく攻撃で、回避策としては POP over SSL やウェブメールなど SSL による暗号化を利用することが推奨されています。

CVE-2007-1558によりますと、悪意あるサーバがPOPサーバになりすまし、POPサーバ側が提示するmessage id(チャレンジ文字列)に仕込みを入れることで、クライアントが送信するMD5文字列からパスワードの先頭3文字(FSE2007でのスライド(pdf)によると31文字?)を復号することが可能なようです。 根本的な解決にはMD5の代わりにSHA-256を使うなどの方法があるのでは無いかと思います。
むしろこのようなニュースが読売新聞のような一般紙に掲載されるようになったことに、驚きを覚えますね。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • そもそもAPOPって (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2007年04月19日 12時03分 (#1144968)
    今回の件とは関係ないけど

    POP over SSL なら
     平文パスワードを(SSLで暗号化して)送って
     サーバでハッシュ値に変換して
     サーバが持っているハッシュ値と比較
    だから サーバはパスワードのハッシュ値しか持ってないわけだけど

    APOP の場合は
     (サーバから種をもらって)
     平文パスワード+種をクライアントでハッシュ値に変換して送って
     サーバも平文パスワード+同じ種をハッシュ値に変換して比較
    という方法をとるわけだから
    サーバに「復号可能な形式のパスワード」が置いてあるわけで

    本質的に平文パスワード漏洩の可能性は高いよなぁ と思います

    PPP の CHAP とか http の digest 認証とかもそう?
    • by Anonymous Coward
      > サーバに「復号可能な形式のパスワード」が置いてあるわけで

      そうだ、そこをパスワードのハッシュ値(以下、ハッシュドパスワード)にすればいいんだ。

      (サーバから種をもらって)
      ハッシュドパスワード+種をクライアントでさらにハッシュ値に変換して送って
      サーバもハッシュドパスワード+同じ種をさらにハッシュ値に変換して比較

      これでハッシュドパスワード自体漏れても大丈夫…あれえ?
      • by Anonymous Coward

        あれえ?はともかく、案外使いでがあるかも知れません。

        サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか?)までが一挙に脅威にさらされるということがなくなります。

        通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダ

    • 同意です。
      APOPはパスワードをサーバ側で平文でしか管理できないのが嫌なところですよね。

      なのでそもそも個人的にAPOPを提供しようと思ったこと自体が無いです。
      それ(パスの平文管理)だけを理由にしてでも POP/IMAP/WebMail over TLS を使う方が良い。

      更にAPOPってパスワードこそハッシュ化されて盗聴から保護されてますが、
      その後のメール本文が平文でだだ漏れなんだし片手落ちにも程があります(^^;
      • TLSを使って回避するというのでは、オレオレ証明書の普及に一役かうのが嫌ですね。APOPの時もMan In the Middle攻撃には脆弱だったわけですが、TLSにしてもオレオレ証明書では同じですね。CAに御布施をすれば良いのですが、最安値はこれですかね?
        http://www.onlinessl.jp/product/rapidssl.html [onlinessl.jp]

        親コメント
      • Re:そもそもAPOPって (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2007年04月19日 17時13分 (#1145181)
        > それ(パスの平文管理)だけを理由にしてでも POP/IMAP/WebMail over TLS を使う方が良い。
        > 更にAPOPってパスワードこそハッシュ化されて盗聴から保護されてますが、
        > その後のメール本文が平文でだだ漏れなんだし片手落ちにも程があります(^^;

        あのねぇ、over TLSがよい、とかわざわざ言わんでも・・・

        歴史的経緯を考えたらわかると思うけど、昔はCPUパワーが充分じゃなく通信路全ての暗号化にまでパワーを使っていい状況じゃなかったです。そういう状況で、サーバー側に平文を置くデメリットもあれども、暗号化されていない通信路でパスワードだけを秘匿する技術がAPOPだったわけです。

        これって時代の中で「これは我慢するからせめてこれを実現して」という要求の中でできたものであるわけで、その前提条件が崩れた(容易にTLS化できる)なかで、「こっちのほうが良い」とか「片手落ち」なんだって、すき放題いうなぁとあきれてます。

        当時POP3がパスワード平文で困る、という問題に対して「(コストかかり過ぎなのに)通信路暗号化で全て解決だよ」、「APOPはサーバにパスワード平文で置くから嫌」なんていってるよりも、導入して受けたメリットも大きかったはずで、今になってウダウダ欠点を責め立てるより「ご苦労さん」といえる度量をもつほうがいいんじゃないの? 今あがってる「欠点」全て当初からわかっていたものであることですし。
        親コメント
    • by Anonymous Coward
      POPなアキバ系じゃなかったんだ
  • 31文字を31時間 (スコア:3, 参考になる)

    by Vorspiel (2391) on 2007年04月19日 13時17分 (#1145041) ホームページ
    同じタレコミをしたけど負けて悔しいので ;-)

    >クライアントが送信するMD5文字列からパスワードの先頭3文字(FSE2007でのスライドによると31文字?)

    電通大チームの発表1 [fse2007.uni.lu],およびそれと独立に行われた高等師範学校(仏) [wikipedia.org]の発表 [fse2007.uni.lu]における手法ではパスワードの先頭3文字が復元可能.
    電通大チームの発表2 [fse2007.uni.lu]では,それを改良した方法で61文字が解読可能.実機検証では31文字のパスワード解読に成功.仏チームの仮定を使った試算では31時間で必要なデータが集められる,といったところでしょうか.

  • 過去のストーリーを探すとわかりますが、そもそももはやMD5自体が安全なハッシュでは無くなっています。
    これはコンピュータの計算力向上に桁が追い付いてないだけなので、いつまでたってもいたちごっこでしょうね。

    すでにPerlのDigest::SHAではSHA-1/224/256/384/512をサポートしています。
    定期的に桁数をあげるようにしていかないといけませんね。

    # タレコミいっぱいなおしていただいて、ありがとうございます >編集者さま
    • MD5脆弱性は、コンピュータの計算力が向上したから起こった問題ではなく、
      数学的に計算できる方法が見つかったというものです。

      H=MD5(X)
      のXとHがわかっているとき、
      H=MD5(Y)
      のYを簡単に計算できる、というもの。

      今回の脆弱性は、
      H=MD5(M,P)
      のMを攻撃者から与えることができ、かつ攻撃者がHを知ることができた場合、
      Pを31文字までなら知ることができる、というもの。

      チャレンジ&レスポンス方式でMD5はもう使えないということですね。
      でも、チャレンジをコントロールできないといけないので、
      横からのぞき見るだけではわからないようですね。

      メッセージ認証としてのHMAC_MD5はどうなんでしょう?
      本文はコントロールできないし、鍵はわからないし、まだ大丈夫そう?
      親コメント
    • by Anonymous Coward on 2007年04月19日 11時50分 (#1144960)

      あのう。アドバイザリをちゃんと読めばわかりますが、そもそもMD5が安全でないとわかったからこそ可能になった攻撃です。

      ……ってタレこんだご本人さんですか。自分でタレ込んだ内容の関連文書くらい、ちゃんと読んでくださいよ。さも理解したかのようなタレ込み文になっているのに。

      親コメント
    • 読売の記事 [yomiuri.co.jp]には

      暗号化のカギとなる「MD5」を逆にさかのぼり、暗号化する前のパスワードに戻す手法を見つけた。

      と書かれているが、朝刊で読んだときにはMD5を可逆変換?そんなバカな!と思った。
      ハッシュのコリジョンを一般人に説明するとしたらこういう表現になるのだろうか…
      • どこまでが正しく理解しているのか不明なのですが、記者レベルではすでに伝言ゲームに失敗してるかと。もっと直接的にパスワード同じにするなと書いてある記事もみたような。

        単に同じハッシュを導き出せる元ネタを計算する方法があるって解釈でいいのですよね?
        てことは、そのネタを使って他のサイトにアタックしても必ず入れるわけじゃないってことでいいんですよね?

        # パスワード個別に設定するに越したことはな。それは理解できるけど、忘れちゃうんだよね。
    • > すでにPerlのDigest::SHAではSHA-1/224/256/384/512をサポートしています。
      最初(0.01)からサポートしてたと思うけど。
      (なんでPerlが出てくるのか知らんが)
  • APOP? (スコア:2, おもしろおかしい)

    by imp (25825) on 2007年04月19日 12時28分 (#1144994) ホームページ
    殆どのユーザーはPOP3か、SSL無しのWebメールログインを使用してるので無害です。
    • by Anonymous Coward
      > SSL無しのWebメールログイン

      なんてあるのか?

      あっても珍しいのでは?
      • by imp (25825) on 2007年04月19日 13時35分 (#1145056) ホームページ
        うろ覚えの記憶で、yahooやhotmailがそうだったんじゃないかなーと思ったんですが、
        今改めて見てみると
        Yahoo→SSL(SSL無し選択可能)
        Hotmail→少なくともログイン時はSSL?
        でした。

        自分が使っていたサーバのように、Horde/impのWebメールを使用している所では
        SSL無しの通信となるとようですが、これはさほど多数とは言えませんね。
        失礼しました。
        親コメント
        • by kashiwagi.gf (33816) on 2007年04月19日 19時40分 (#1145268)
          まさにこの理由でGMailを選択していますが、https://mail.google.com/mail/ 以外の
          URLでログインしたときはログインだけがSSLで処理されたり、
          Google ツールバーでアクセスするとSSLが解除されたりと、
          あまり積極的じゃないみたいです。
          親コメント
      • by Anonymous Coward
        イントラネット内でサイボウズとかdesknet'sとか使っている場合は珍しくないかと。

        レンタルサーバ使っている場合も多いかも

        • by Anonymous Coward
          > イントラネット内でサイボウズとかdesknet'sとか使っている場合は珍しくないかと。
          > レンタルサーバ使っている場合も多いかも

          やっぱ珍しいという範囲なんじゃないのかな?
    • by Anonymous Coward
      マジレスすると、Outlook ExpressはAPOPに対応してないようですね(Mac版除く)。
  • 本件のポイントは「なりすましたサーバー」なわけでですよね。
    POP over SSLならば判らなくも無いけど、SSL経由でWebメールの場合、
    なりすましたWebサーバーもありえるわけで、根本的には安全とは言えない
    気がしますが・・実際の所どうなんでしょうか?

    • by Anonymous Coward on 2007年04月19日 11時35分 (#1144948)
      正しく運用できていれば、SSLによるWebメールでは
      なりすましは回避できると思いますが、いかがでしょうか?

      親コメント
      • >正しく運用できていれば、SSLによるWebメールでは
        >なりすましは回避できる

        聞きかじり程度の知識しかありませんが、ちょっと簡単に捕捉してみます。

        SSLが「正しく運用できて」いる場合、
        ・サーバ証明書には信頼できるルート認証局(注1)の署名がなされているはず
        ・サーバ証明書の複製は(きちんと管理されていれば)不可能
        → 怪しい組織は“怪しくない”サーバ証明書(注2)は持てない
        ので、基本的になりすます事は出来ないはず。

        注1:信頼できるルート認証局が怪しい組織に証明書を発行しちゃったり、ユーザが信頼できないルート認証局の証明書をインストールしてたりしたらアウトだけど。
        注2:“怪しい”サーバ証明書(オレオレ証明書とか)だったら持てる。でも、オレオレ証明書を信用するのは「正しい運用」ではない(そうさせてるサイトはとっても多いけど)。

        ※ CN とかの説明は不要ですよねぇ…。> 詳しい人
        • > ・サーバ証明書に対応する秘密鍵の複製は(きちんと管理されていれば)不可能

          「サーバ証明書の複製」っていう言葉はちょっとおかしいかも。
          証明書は公開鍵に相当し、ダウンロードされて検証される物だし。

          ・サーバ証明書に対応する秘密鍵の複製は(きちんと管理されていれば)不可能
          の方が正しい記述かも。

          親コメント
          • 「複製」とか「管理」とか言い出すとおかしくなるんで
            単純に「秘密鍵の推測が(今のところ)不可能」でいい話。
            親コメント
            • #1145020のACです。
              ご指摘ありがとうございます。

              >>・サーバ証明書に対応する秘密鍵の複製は(きちんと管理されていれば)不可能
              >>の方が正しい記述かも。

              >単純に「秘密鍵の推測が(今のところ)不可能」でいい話。

              お二方のご指摘とも、まったくもってその通りなんですが、この方面に詳しくないかたにもおわかりいただけるように簡略化して説明したつもりでした。
              ※ 嘘は避けつつ、あまり詳細に踏み込まない方針で…。

              とは言え、「サーバ証明書の複製」のくだりはやっぱり不適切なので、

              ・サーバ証明書の流用は(サーバの秘密鍵がきちんと管理されていれば)不可能

              あたりでいかがでしょうか?
              ※ と、ひっぱるほどの話ではありませんが…。
    • >SSL経由でWebメールの場合

      WebサーバーがSSL対応(要はURLだとhttps://)の場合なりすましは出来ません
      Webサーバーとメールサーバー間もPOP Over SSL/IMAP Over SSLとかの場合なりすましはできません

      どちらか一方がSSLを使わず、平文な場合なりすましは出来るかもしれません

      Webメーラーはhttp Over SSL/TLSで立ち上げる事が多いと思うけどそう言う話ではなくて???
  • 管理者からのメール偽造して、パスワードをメールで送らせるとかしたほうが手っ取り早い気が。
  • s/複合/復号/ (スコア:0, オフトピック)

    by Anonymous Coward on 2007年04月19日 11時09分 (#1144927)
    s/複合/復号/
  • by Anonymous Coward on 2007年04月19日 11時15分 (#1144932)
    > むしろこのようなニュースが読売新聞のような一般紙に掲載されるようになったことに、
    > 驚きを覚えますね。

    たびたび登場してませんかね?こういうネタって。
    ただ、ターゲットが一般人のためなのか、どうしてもわかりにくい漠然としない説明が並びますね。社会ネタ記者ができる範囲で書いているためなのか、間違っていたり意味不明な説明もありますね。

    読売新聞 [yomiuri.co.jp]のこれは
    電子メールのパスワードを暗号化して送信する規格「APOP」
    という説明はわかりやすくしたつもりで実はわかりにくいという問題を起こしているような気がする。
    間違ってはいないが、間違って読みやすい。

    • Re:いや (スコア:1, 興味深い)

      by Anonymous Coward on 2007年04月19日 11時21分 (#1144935)
      テレビでは「メール送受信のデータを暗号化しているAPOPの暗号が破られた!」なんて言っていたけど、暗号はパスワードだけだし、そもそもAPOPはそんなに使われてないでしょう?しかも「通信販売とかネット銀行とか使っているので気をつけなきゃ」ってゲストが言ってしまったり・・・。
      親コメント
      • ただ騒ぎたいだけで、事実なんぞに興味はないんだな、と思う。
        # 報道する方も、見てる方もね
        • > ただ騒ぎたいだけで、事実なんぞに興味はないんだな、と思う。

          彼らなりにがんばっているのだが、低い知識の中で自分の知っている範囲で無理に話をするので、変な話になってしまうんだと思いますよ。
  • by Anonymous Coward on 2007年04月19日 11時22分 (#1144938)
    > 根本的な解決にはMD5の代わりにSHA-256を使うなどの方法があるのでは無いかと思います。

    代わりに使うべきなのは、ハッシュ関数そのままじゃなくてHMACとかじゃないの?
    • Re:HMAC (スコア:2, すばらしい洞察)

      by saitoh (10803) on 2007年04月19日 11時34分 (#1144944)
      根本的な解決は、パスワードしか暗号化しないAPOPを使うことを止めることでは?

      記事中にもPOP over SSLが例示されているけど。 僕は、POP over SSHを使ってます。某駅前のホテルサンルートのLANサービスではではSSHポートが閉められていて、泣きました。

      親コメント
      • Re:HMAC (スコア:2, すばらしい洞察)

        by kayakiss (20105) on 2007年04月19日 12時42分 (#1145011)
        >根本的な解決は、パスワードしか暗号化しないAPOPを使うことを止めることでは?
        私もそう思ったのですが、メールボックスから自分のクライアントマシンの間だけメールコンテンツを暗号化しても、そのメールボックスに届くまでの間は暗号化されてないですよね。

        そう考えると、APOPのようにパスワードのみ暗号化するというアプローチは、パスワードを守るという点において、十分な解決方法だったと思います。もちろんPOP over SSLでもPOP over SSHでも十分でしょう。

        ただ、メールコンテンツを守りたい場合は、メールそのものをS/MIMEやPGPで暗号化する必要があって、SMTP over SSLやPOP over SSLでは限られた範囲でしか効果がないです。
        親コメント
        • by Stealth (5277) on 2007年04月19日 18時18分 (#1145219)

          SMTP over TLS にしたら、SMTP サーバの双方が対応していれば SMTP セッションは暗号化されますよ。

          SMTP over TLS で送信者 MUA →メールサーバ (Submission)、SMTP over TLS でメールサーバ→メールサーバ (SMTP)、POP3/IMAP4 over TLS でメールサーバ→受信者 MUA (POP3 or IMAP4) は可能です。

          もちろん非対応サーバ間ではダメなので、当然ながらコンテンツ自体をしっかり保護したい場合には S/MIME なり PGP なりの対処は必要ですが、ヘッダはそのままですしねぇ……。

          親コメント
      • by Anonymous Coward
        port 22が駄目ならport 80があるじゃない :)。

        #さらに極悪なportでSSHd上げているのでAC
        • Re:泣くな:) (スコア:2, 参考になる)

          by saitoh (10803) on 2007年04月19日 23時09分 (#1145378)
          インターネットカフェで一旦自宅マシンにログインして、80番ポートとか21番ポートにsshdを貼り付けて、でホテルに戻って試してみたのですが、それもダメでした。 80以外のポートは軒並み閉めていたみたい。443番は忘れていた。

          次に行くことがあったらは、443番ポートを試してみます。

          親コメント
        • by nox_dot (11614) on 2007年04月19日 16時49分 (#1145169) 日記
          443 だと、httpプロキシが間にいてもなんとかなったりするのでしょうか?

          親コメント
          • by Anonymous Cat (27860) on 2007年04月19日 20時15分 (#1145281)
            大抵は何とかなるんじゃないでしょうか。
            CONNECTメソッドが使えないように設定してあったら無理でしょうけど。

            UTF-8 TeraTermとかputtyは対応しているみたいですし
            OpenSSHやPortForwarderの場合はconnect.c [taiyo.co.jp]を使うといいと思います。

            --
            単なる臆病者の Anonymous Cat です。略してACです。
            親コメント
        • by Anonymous Coward
          > #さらに極悪なportでSSHd上げているのでAC

          53か?

          # #部にツッコミは野暮
  • by Anonymous Coward on 2007年04月19日 11時59分 (#1144965)
    NISTの予定表 [nist.gov]では、2012年になってますから、それまではSHA-2でしのげってことですかね
  • もうメチャクチャな世の中になってきたね
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...