中間者攻撃とSSL

　アソシエーションにおいて、これまで説明したきたような方法を使うことで、メッセージの改ざんなどのいわゆる中間者攻撃を防ぐことができそうですが、まだ十分ではありません。実はDNSサーバーやトランスポート層を操ることができれば、OPを装うことができるので、MACキーで署名したとしても防御が十分ではなくなってしまいます。

　また、OPに対するリクエストの必要情報を得るディスカバリープロセスにおいて、例えばXRDSドキュメントを改ざんされる場合も考えられます。

　こうした攻撃を防ぐためにもSSLを利用するべきでしょう。SSLについては、ここであらためて解説する必要はないかもしれませんが、暗号化された通信を提供するもので、なりすましや盗聴などを防ぎます。

　通常はOPが信頼に足るかどうかを知らせるために、信頼できる認証局が発行したサーバー証明書を提示して、PRがそれが正しいことを確認した上でやりとりが行われますが、クライアント側の確認過程において、認証局自体の正当性を証明するためのルート証明書に行きつきます。

　以前筆者がPHPのcurlを使ってmixiにSSL接続しようとしてうまくいかずに困ったことがありましたが、それはcurlが利用しているルート証明書が古いためのようでした。

　curlのオプションでルート証明書の検証を行わないようにすることもできますし、そのように解説しているサイトもあります。しかし、mixiのサイト（http://developer.mixi.co.jp/openid/faq）にも説明されているように、この方法はなりすましの危険性があるため問題があると言えるでしょう。同じコードを流用する場合などもあると思いますので、避けた方がよいでしょう。

セキュリティーに対するスタンス

　第2回、第3回とOpenIDに関連するセキュリティーについて簡単に説明してきましたが、攻撃手法などの危険性を中心に解説してきたので、なんとなくOpenIDに対する恐れのようなものが出てきてしまったかもしれません。

　しかし、説明した攻撃手法の1つ1つは、それほど新しいものではないですし、すでに対応方法やコツなども確立しています。ですから、それぞれの立場での対処の仕方を理解し、それをきちんと行っていれば、実際それほど恐れるものではないと思います。

　Webでいろいろなサイトを見ていると、「IDが1つだとそれを盗まれたらおしまいだ」という意見や、OpenIDのセキュリティー面での危険性を強調してあおるような意見などがあります。しかし、もともとWeb自体がそういった悪人と善人が混在するようなオープンな環境です。オープンであるからこそ危険性もある反面、いろいろな新しいサービスが花開いているわけですから、悪い面だけを見過ぎないで、適切に対処していく方がいいのではないかと思います。

　さて、最終回となる次回は、実際にOpenIDを実装していく場合のステップやTipsについて具体的に解説したいと思います。