koshianの日記： APOPにパスワード漏洩の脆弱性 65
日記 by
koshian
読売新聞の記事でも報じられていますが、APOPにプロトコル上の欠陥が見つかったようです。
CVE-2007-1558によりますと、POPサーバ側が提示するmessage id(チャレンジ文字列)に仕込みを入れることで、クライアントが送信するMD5文字列からパスワードの先頭3文字を複合することが可能なようです。
これはSHA-256にでもすればすぐ対応可能ですし、サーバ側も送られてきた文字列長でMD5かSHA-256かはすぐ判別できるので、おそらくすぐにでも対処されるのではないでしょうか。
むしろこのようなニュースが読売新聞のような一般紙に掲載されるようになったことに、驚きを覚えますね。
そもそもAPOPって (スコア:3, すばらしい洞察)
POP over SSL なら
平文パスワードを（SSLで暗号化して）送って
サーバでハッシュ値に変換して
サーバが持っているハッシュ値と比較
だから サーバはパスワードのハッシュ値しか持ってないわけだけど
APOP の場合は
（サーバから種をもらって）
平文パスワード＋種をクライアントでハッシュ値に変換して送って
サーバも平文パスワード＋同じ種をハッシュ値に変換して比較
という方法をとるわけだから
サーバに「復号可能な形式のパスワード」が置いてあるわけで
本質的に平文パスワード漏洩の可能性は高いよなぁ と思います
PPP の CHAP とか http の digest 認証とかもそう?
Re:そもそもAPOPって (スコア:0)
そうだ、そこをパスワードのハッシュ値(以下、ハッシュドパスワード)にすればいいんだ。
(サーバから種をもらって)
ハッシュドパスワード+種をクライアントでさらにハッシュ値に変換して送って
サーバもハッシュドパスワード+同じ種をさらにハッシュ値に変換して比較
これでハッシュドパスワード自体漏れても大丈夫…あれえ?
Re:そもそもAPOPって (スコア:0)
あれえ？はともかく、案外使いでがあるかも知れません。
サービス別の「ハッシュドパスワード」を使っておけば、万一それが漏洩しても、同じパスワードで提供される別のサービス(プロバイダであればウェブ、ブログ、最近ではなんたらポイントとかなんたらキャッシュとかもあるでしょうか？)までが一挙に脅威にさらされるということがなくなります。
通信プロトコルは標準技術であり、また機能的制約(携帯電話からの利用であるとか)や普及度などの問題から必ずしも思い通りのものを採用できるとは限りません。そのため、個別の認証に本物パスワードを使い回すと「プロバイダ
Re:そもそもAPOPって (スコア:0, 余計なもの)
APOPはパスワードをサーバ側で平文でしか管理できないのが嫌なところですよね。
なのでそもそも個人的にAPOPを提供しようと思ったこと自体が無いです。
それ(パスの平文管理)だけを理由にしてでも POP/IMAP/WebMail over TLS を使う方が良い。
更にAPOPってパスワードこそハッシュ化されて盗聴から保護されてますが、
その後のメール本文が平文でだだ漏れなんだし片手落ちにも程があります(^^;
TLSにすれば解決というわけでもないと思うけど... (スコア:3, 参考になる)
http://www.onlinessl.jp/product/rapidssl.html [onlinessl.jp]
Re:そもそもAPOPって (スコア:2, すばらしい洞察)
> 更にAPOPってパスワードこそハッシュ化されて盗聴から保護されてますが、
> その後のメール本文が平文でだだ漏れなんだし片手落ちにも程があります(^^;
あのねぇ、over TLSがよい、とかわざわざ言わんでも・・・
歴史的経緯を考えたらわかると思うけど、昔はCPUパワーが充分じゃなく通信路全ての暗号化にまでパワーを使っていい状況じゃなかったです。そういう状況で、サーバー側に平文を置くデメリットもあれども、暗号化されていない通信路でパスワードだけを秘匿する技術がAPOPだったわけです。
これって時代の中で「これは我慢するからせめてこれを実現して」という要求の中でできたものであるわけで、その前提条件が崩れた（容易にTLS化できる）なかで、「こっちのほうが良い」とか「片手落ち」なんだって、すき放題いうなぁとあきれてます。
当時POP3がパスワード平文で困る、という問題に対して「（コストかかり過ぎなのに）通信路暗号化で全て解決だよ」、「APOPはサーバにパスワード平文で置くから嫌」なんていってるよりも、導入して受けたメリットも大きかったはずで、今になってウダウダ欠点を責め立てるより「ご苦労さん」といえる度量をもつほうがいいんじゃないの？ 今あがってる「欠点」全て当初からわかっていたものであることですし。
Re:そもそもAPOPって (スコア:0)
31文字を31時間 (スコア:3, 参考になる)
>クライアントが送信するMD5文字列からパスワードの先頭3文字(FSE2007でのスライドによると31文字?)
電通大チームの発表1 [fse2007.uni.lu]，およびそれと独立に行われた高等師範学校(仏) [wikipedia.org]の発表 [fse2007.uni.lu]における手法ではパスワードの先頭3文字が復元可能．
電通大チームの発表2 [fse2007.uni.lu]では，それを改良した方法で61文字が解読可能．実機検証では31文字のパスワード解読に成功．仏チームの仮定を使った試算では31時間で必要なデータが集められる，といったところでしょうか．
そもそもMD5自体がもはや安全ではない (スコア:2, 興味深い)
これはコンピュータの計算力向上に桁が追い付いてないだけなので、いつまでたってもいたちごっこでしょうね。
すでにPerlのDigest::SHAではSHA-1/224/256/384/512をサポートしています。
定期的に桁数をあげるようにしていかないといけませんね。
# タレコミいっぱいなおしていただいて、ありがとうございます >編集者さま
Re:そもそもMD5自体がもはや安全ではない (スコア:2, 参考になる)
数学的に計算できる方法が見つかったというものです。
H=MD5(X)
のXとHがわかっているとき、
H=MD5(Y)
のYを簡単に計算できる、というもの。
今回の脆弱性は、
H=MD5(M,P)
のMを攻撃者から与えることができ、かつ攻撃者がHを知ることができた場合、
Pを31文字までなら知ることができる、というもの。
チャレンジ＆レスポンス方式でMD5はもう使えないということですね。
でも、チャレンジをコントロールできないといけないので、
横からのぞき見るだけではわからないようですね。
メッセージ認証としてのHMAC_MD5はどうなんでしょう？
本文はコントロールできないし、鍵はわからないし、まだ大丈夫そう？
Re:そもそもMD5自体がもはや安全ではない (スコア:4, 参考になる)
>のXとHがわかっているとき、
>H=MD5(Y)
>のYを簡単に計算できる、というもの。
それは(second) preimage attack．MD5で問題になってるのはcollision attack．
Re:そもそもMD5自体がもはや安全ではない (スコア:0)
「SSLによる暗号化通信を利用する」のが対策になるというのは、ちょっと違うような。
SSLによって認証されたサーバを使用する「POP over SSL」を使えという話ではないかと。
Re:そもそもMD5自体がもはや安全ではない (スコア:1, 参考になる)
あのう。アドバイザリをちゃんと読めばわかりますが、そもそもMD5が安全でないとわかったからこそ可能になった攻撃です。
……ってタレこんだご本人さんですか。自分でタレ込んだ内容の関連文書くらい、ちゃんと読んでくださいよ。さも理解したかのようなタレ込み文になっているのに。
読売の記事は誤解を招かないか？ (スコア:0)
暗号化のカギとなる「ＭＤ５」を逆にさかのぼり、暗号化する前のパスワードに戻す手法を見つけた。
と書かれているが、朝刊で読んだときにはMD5を可逆変換？そんなバカな！と思った。
ハッシュのコリジョンを一般人に説明するとしたらこういう表現になるのだろうか…
Re:読売の記事は誤解を招かないか？ (スコア:0)
単に同じハッシュを導き出せる元ネタを計算する方法があるって解釈でいいのですよね？
てことは、そのネタを使って他のサイトにアタックしても必ず入れるわけじゃないってことでいいんですよね？
# パスワード個別に設定するに越したことはな。それは理解できるけど、忘れちゃうんだよね。
Re:そもそもMD5自体がもはや安全ではない (スコア:0)
最初(0.01)からサポートしてたと思うけど。
(なんでPerlが出てくるのか知らんが)
APOP? (スコア:2, おもしろおかしい)
Re:APOP? (スコア:0)
なんてあるのか？
あっても珍しいのでは？
Webメール (スコア:1)
今改めて見てみると
Yahoo→SSL（SSL無し選択可能）
Hotmail→少なくともログイン時はSSL?
でした。
自分が使っていたサーバのように、Horde/impのWebメールを使用している所では
SSL無しの通信となるとようですが、これはさほど多数とは言えませんね。
失礼しました。
Re:Webメール (スコア:1)
URLでログインしたときはログインだけがSSLで処理されたり、
Google ツールバーでアクセスするとSSLが解除されたりと、
あまり積極的じゃないみたいです。
Re:APOP? (スコア:0)
レンタルサーバ使っている場合も多いかも
Re:APOP? (スコア:0)
> レンタルサーバ使っている場合も多いかも
やっぱ珍しいという範囲なんじゃないのかな？
Re:APOP? (スコア:0)
SSLでWebメールが安全か？ (スコア:1)
POP over SSLならば判らなくも無いけど、SSL経由でWebメールの場合、
なりすましたWebサーバーもありえるわけで、根本的には安全とは言えない
気がしますが・・実際の所どうなんでしょうか？
Re:SSLでWebメールが安全か？ (スコア:1, すばらしい洞察)
なりすましは回避できると思いますが、いかがでしょうか？
Re:SSLでWebメールが安全か？ (スコア:0)
>なりすましは回避できる
聞きかじり程度の知識しかありませんが、ちょっと簡単に捕捉してみます。
SSLが「正しく運用できて」いる場合、
・サーバ証明書には信頼できるルート認証局（注１）の署名がなされているはず
・サーバ証明書の複製は（きちんと管理されていれば）不可能
→ 怪しい組織は“怪しくない”サーバ証明書（注２）は持てない
ので、基本的になりすます事は出来ないはず。
注１：信頼できるルート認証局が怪しい組織に証明書を発行しちゃったり、ユーザが信頼できないルート認証局の証明書をインストールしてたりしたらアウトだけど。
注２：“怪しい”サーバ証明書（オレオレ証明書とか）だったら持てる。でも、オレオレ証明書を信用するのは「正しい運用」ではない（そうさせてるサイトはとっても多いけど）。
※ CN とかの説明は不要ですよねぇ…。＞ 詳しい人
Re:SSLでWebメールが安全か？ (スコア:1)
「サーバ証明書の複製」っていう言葉はちょっとおかしいかも。
証明書は公開鍵に相当し、ダウンロードされて検証される物だし。
・サーバ証明書に対応する秘密鍵の複製は（きちんと管理されていれば）不可能
の方が正しい記述かも。
Re:SSLでWebメールが安全か？ (スコア:1)
単純に「秘密鍵の推測が（今のところ）不可能」でいい話。
Re:SSLでWebメールが安全か？ (スコア:0)
ご指摘ありがとうございます。
>>・サーバ証明書に対応する秘密鍵の複製は（きちんと管理されていれば）不可能
>>の方が正しい記述かも。
>単純に「秘密鍵の推測が（今のところ）不可能」でいい話。
お二方のご指摘とも、まったくもってその通りなんですが、この方面に詳しくないかたにもおわかりいただけるように簡略化して説明したつもりでした。
※ 嘘は避けつつ、あまり詳細に踏み込まない方針で…。
とは言え、「サーバ証明書の複製」のくだりはやっぱり不適切なので、
・サーバ証明書の流用は（サーバの秘密鍵がきちんと管理されていれば）不可能
あたりでいかがでしょうか？
※ と、ひっぱるほどの話ではありませんが…。
Re:SSLでWebメールが安全か？ (スコア:0)
WebサーバーがSSL対応(要はURLだとhttps://)の場合なりすましは出来ません
Webサーバーとメールサーバー間もPOP Over SSL/IMAP Over SSLとかの場合なりすましはできません
どちらか一方がSSLを使わず、平文な場合なりすましは出来るかもしれません
Webメーラーはhttp Over SSL/TLSで立ち上げる事が多いと思うけどそう言う話ではなくて???
メールサーバになりすませるなら (スコア:1)
s/複合/復号/ (スコア:0, オフトピック)
いや (スコア:0)
> 驚きを覚えますね。
たびたび登場してませんかね？こういうネタって。
ただ、ターゲットが一般人のためなのか、どうしてもわかりにくい漠然としない説明が並びますね。社会ネタ記者ができる範囲で書いているためなのか、間違っていたり意味不明な説明もありますね。
読売新聞 [yomiuri.co.jp]のこれは
という説明はわかりやすくしたつもりで実はわかりにくいという問題を起こしているような気がする。
間違ってはいないが、間違って読みやすい。
Re:いや (スコア:1, 興味深い)
こういう報道見るたびに (スコア:0)
# 報道する方も、見てる方もね
Re:こういう報道見るたびに (スコア:0)
彼らなりにがんばっているのだが、低い知識の中で自分の知っている範囲で無理に話をするので、変な話になってしまうんだと思いますよ。
Re:こういう報道見るたびに (スコア:0)
いちいち思考コストかけてらんないのは確かだと思います
Re:こういう報道見るたびに (スコア:0)
Re:こういう報道見るたびに (スコア:0)
# 具体例あげてないので推測だけど、…ですよね？
HMAC (スコア:0)
代わりに使うべきなのは、ハッシュ関数そのままじゃなくてHMACとかじゃないの?
Re:HMAC (スコア:2, すばらしい洞察)
記事中にもPOP over SSLが例示されているけど。 僕は、POP over SSHを使ってます。某駅前のホテルサンルートのLANサービスではではSSHポートが閉められていて、泣きました。
Re:HMAC (スコア:2, すばらしい洞察)
私もそう思ったのですが、メールボックスから自分のクライアントマシンの間だけメールコンテンツを暗号化しても、そのメールボックスに届くまでの間は暗号化されてないですよね。
そう考えると、APOPのようにパスワードのみ暗号化するというアプローチは、パスワードを守るという点において、十分な解決方法だったと思います。もちろんPOP over SSLでもPOP over SSHでも十分でしょう。
ただ、メールコンテンツを守りたい場合は、メールそのものをS/MIMEやPGPで暗号化する必要があって、SMTP over SSLやPOP over SSLでは限られた範囲でしか効果がないです。
Re:HMAC (スコア:1)
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 なりの対処は必要ですが、ヘッダはそのままですしねぇ……。
泣くな:) (スコア:0)
#さらに極悪なportでSSHd上げているのでAC
Re:泣くな:) (スコア:2, 参考になる)
次に行くことがあったらは、443番ポートを試してみます。
Re:泣くな:) (スコア:1)
Re:泣くな:) (スコア:1)
CONNECTメソッドが使えないように設定してあったら無理でしょうけど。
UTF-8 TeraTermとかputtyは対応しているみたいですし
OpenSSHやPortForwarderの場合はconnect.c [taiyo.co.jp]を使うといいと思います。
単なる臆病者の Anonymous Cat です。略してACです。
Re:泣くな:) (スコア:0)
53か？
# #部にツッコミは野暮
次世代標準ハッシュ関数は5年後の予定 (スコア:0)
読売新聞の記事って風説の流布同然のような記事じゃないか？ (スコア:0)