はてなはパスワードを生データで管理してる?
WSSE認証は「安全」かつ「手軽に導入できる」認証として、当初Atom APIで採用されていました。Perl CGIしか動かせないようなホスティングサービスでも使えることが大切で、HTTPSが必須とかでは目的に合わないと考えられていたようです。
以下の記事では、冒頭で4つの選択肢が検討されています。
- HTTP Basic認証を使う。Basic認証は、簡単に元のパスワードにデコードできてしまう。平文を直接送るのと変わらないので却下。
- パスワードをMD5ハッシュしてハッシュだけを送信。盗聴者が平文のパスワードを入手することは不可能。しかし、リプレイ攻撃に耐えられない。Bobのハッシュが通信中に盗まれるとBobに成りすますことができてしまう。
- SSLでHTTP Basic認証を使う。これならパスワード盗聴の問題は解決できる。しかし、Bobのブログは、安いホスティングサービスで動いていて、SSLなんか使えない。
- HTTP Digest認証を使う。これもパスワード盗聴の問題を解決でき、リプレイ攻撃の問題も解決できる。しかし、Bobのホスティングサービスは.htaccessを編集する権限を与えていない。ApacheがDigest認証に必要なヘッダーを剥ぎ取ってしまうので、CGIが自前でDigest認証を実装することも出来ない。
まあ2年以上前の記事なので、実情にどのくらい合ってるのかわかりませんが……。ただMTはローエンドの環境で動作することを非常に重視していて、それが成功の一因になっていた印象はあります。
さて、今の話。Atom Publishing Protocolの仕様では、WSSEへの言及は全て取り除かれています。
draft-ietf-atompub-protocol-01 - (...) Elided all mentions of WSSE.
代わりに、
Atom Protocol servers and clients MUST support one of the following authentication mechanisms, and SHOULD support both.
o HTTP Digest Authentication [RFC2617]
o CGI Authentication
Digest認証か、CGI認証のどちらか、あるいは両方をサポートすることになっています。
CGI認証というのは、CGIで実装できる認証という程度の意味でしかないみたいです(13.1)。WSSEはこれに含まれるのでしょう。
HTTP Digest認証の仕組みは(よく知らなかったので調べたら)、
PasswordDigest = MD5( MD5( Password ) + Nonce )
だそうです。(追記) 上のはだいたいのフィーリングです。というか正直に言うと間違いです。すみません……。sheepmanさんのコメントを参照してください。
Nonceはサーバから送られてきたランダムな(あるいは改変されていないことをサーバ側で確認可能な何らかの)文字列。
WSSEと基本は一緒ですが*1、Digest認証の場合、サーバにパスワードを平文で保存する必要がないんですね。MD5(Password)を持っとけばOK。
というわけで、はてなのAtom APIはHTTP Digest認証に移行するのがいいのかもしれません。でも、クライアントのサポート状況との兼ね合いもあって、難しかったりするのかも*2。(追記) id:sshiさんのコメントと、下の続きをご覧下さい。
ちなみに、Bloggerは、去年の早い段階でWSSEを捨てて、HTTPS + Basic認証に移行しています。これはでも今のAtom PPに合わなくなった感じですねー。
- http://code.blogger.com/archives/atom-docs.html#authentication
- http://www.witha.jp/blog/archives/2005/03/blogger_atomapi.html
一応、元記事の言及記事にトラックバクー。
上の続き
# id:sshi 『ども。トラックバック先のsshiです。一点だけ。
>PasswordDigest = MD5( MD5( Password ) + Nonce )
>Digest認証の場合、サーバにパスワードを平文で保存する必要がないんですね。MD5(Password)を持っとけばOK。|
(これは少しおかしい気もしますが)そうだとしても、MD5(password)が結局生パスワードと同じことになりますよね。クライアントはMD5(password)だけ持ってれば認証できちゃうわけだし。』 (2006/03/31 04:14)
その通りですよね。。何言ってるんだろう自分。
# id:sshi 『すこし訂正します。
(MD5値を使って)ダイジェスト認証するものと、SSL+Basic認証するものを使いわけておけば、MD5値が漏れてもアクセスされるのは前者だけで後者へのアクセスは防げるかもしれませんね。気がついてませんでした。(また適当なこといってるかも)』
データを流出させたサービスAと、サービスAのユーザが同じパスワードを使っているサービスBがあった場合、
- サービスA 認証方式a
- サービスA 認証方式b
- サービスB 認証方式a
- サービスB 認証方式b
生のパスワードがDBに書いてある場合、DBデータが流出すると、1,2,3,4全てで認証が通ってしまう。
認証方式aがDigest認証で、DBにハッシュが書かれている場合、DBデータが流出すると、1,3は認証が通ってしまう。認証方式が異なる2,4は通らないかもしれない。 (追記) 3も普通は認証が通らないそうです。sheepmanさんのコメントをご覧下さい。
認証方式aがBasic認証で、DBにハッシュが書かれている場合、DBデータが流出しても、1,3は認証が通らない。2,4は流出したハッシュを送信するような認証方式でなければ大丈夫。
これとは別に、盗聴への対策が必要。なのでやっぱり、HTTPS+Basic認証(生で送信)が安全ということになる。
逆に言うと、DBデータに(認証されるのを防ぐ目的で)ハッシュを格納する場合、SSLを使わざるを得ない。
SSLが使えない場合に、通信経路とDBデータのどっちを守るべきか、という話で、通信経路の方を守るのが正しい選択ということかなー。
以下の記事が参考になります。