OpenIDコミュのITメディアの記事「DNSの脆弱性が影響： OpenIDにフィッシングの危険発覚」について

http://www.itmedia.co.jp/enterprise/articles/0808/18/news014.html

「対応は難しい」で閉じてしまっていますが...。

実際の対応策は先日のOpenID Tech Night vol.3 でも解説したのですが、
OpenIDを安全に使うには、HTTPSベースのOpenIDを「正しく」使う必要があります。
（ないしは、XRIベースにする。）

HTTPSベースのOpenIDを正しく使うというのは、

(1) RPは、HTTPS（ないしはXRI）OpenID「のみ」を受け入れる。
(2) RPは、OPに対してコネクションを張るときに、かならずTLS/SSL証明書の確認をする。
　　（注：この確認には、OCSP (RFC 2560) を使った証明書の確認も含みます。）
　　↑これは、Association を張り直すときです。
(3) RPは、OPのX.509のキーが弱い鍵によって生成されていないことを確認する。

ということです。ホワイトリストなんかで相手を限るよりも、こちらの方がずっと重要です。

残念ながら、世の多くのRPは、こういうことをやっていません。

ちなみに、ついでに知っておいていただきたいのですが、世の中に転がっているX.509証明書のうちの５％程度は偽物を作ることができるといわれています。この記事のアタックは、このことを利用したものです。したがって、OpenIDに特有の問題というわけでもありません。

コメント(7)

最初
全て
最新の40件

[1] mixiユーザー 08月18日 21:39

spec通りにクライアントライブラリがHTTPSより先にplain なHTTPで接続してしまう実装が多そうなのが悩ましいですね。「検査不能なプロトコルでのOP接続を試みない」オプションを指定できるだけでいいので、そーいう方向に持って行けたらいいなぁ。　

[2] mixiユーザー 08月21日 01:11

他にも、ネゴシエーションで許容するアルゴリズムも制限する必要がありますよね。3DESはまだしも、DESなんか使おうものなら問題だと思います。NSAでもDES->AESへの置き換え始まってたりしますので。

他にも、SSLハンドシェイク中の不正なリクエストにより、暗号化アルゴリズムの強度が最小なものを選択させることができてしまったりするようなので、SSL v3 / TLS1.0↑を使うようにするとか。

正しく使うのは難しいですね・・・

[3] mixiユーザー 08月23日 23:31

しょせん、HTTPSベースにしても、ID Recycle やら、ドメイン蒸発問題は本質的には解けないので、抽象化レイヤーを一枚入れる必要がありますよね。XRIをHTTPS or SAMLバインディングのResolutionだけで使う、というのが、技術的には一番妥当かもしれませんね。

ところで、OSISな人と木曜に電話で話していて、OPとしてまともに、http:// を https:// に転送しているのは Yahoo! しかないという話になって、僕が「Mixiもちゃんとやってるよ」と言ったら、ぜひOSISに参加してほしいといわれたんですが、OSIS@DIDW、参加しませんか？つなぎますよ。＞中の人

[6] mixiユーザー 08月25日 18:39

使い手にもロバストなOPを選んでもらったり、XRIやdelegateとか「代表ID」を選んでもらったりと、なにかとステップが増えてしまいそうでイヤンですね。それをきれいにラッピングして提供するのが僕らサービス提供者の仕事って言えばそのとおりなのですが :-)
あぁ「安全な実装のRP」を監査する仕組みが欲しくなってきた。

OSISって何やるんですか？　←ちょっ....

[7] mixiユーザー 08月28日 21:03

OSISは、OP/RPの機能とコンパチビリティチェックです。

ここのOPは、何をサポートしている、とか、RPは何をサポートしているとか、どことどこはつながる、などです。

アナウンスを別スレに乗せておきます。

ログインすると、みんなのコメントがもっと見れるよ