新井英樹「RIN」第1話プレビュー

ヤングマガジンのサイトで、新井英樹の「RIN」第1話が丸ごと読めるようになっています。

別の雑誌に連載されていた『SUGAR』の続編なんですが、移って1回目だと、いくぶん説明的になっちゃうのは仕方ないのかなー。持ち前のリズム感がうまく出ていないような気もします。でも最高。超天才。浦なんとかのプラなんとかの1おく倍くらい売れるべき。第1巻、5/2発売です。

はてなはパスワードを生データで管理してる?

WSSE認証は「安全」かつ「手軽に導入できる」認証として、当初Atom APIで採用されていました。Perl CGIしか動かせないようなホスティングサービスでも使えることが大切で、HTTPSが必須とかでは目的に合わないと考えられていたようです。

以下の記事では、冒頭で4つの選択肢が検討されています。

  1. HTTP Basic認証を使うBasic認証は、簡単に元のパスワードにデコードできてしまう。平文を直接送るのと変わらないので却下。
  2. パスワードをMD5ハッシュしてハッシュだけを送信。盗聴者が平文のパスワードを入手することは不可能。しかし、リプレイ攻撃に耐えられない。Bobのハッシュが通信中に盗まれるとBobに成りすますことができてしまう。
  3. SSLでHTTP Basic認証を使う。これならパスワード盗聴の問題は解決できる。しかし、Bobのブログは、安いホスティングサービスで動いていて、SSLなんか使えない。
  4. 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に合わなくなった感じですねー。

一応、元記事の言及記事にトラックバクー。

*1:一緒じゃないですね。WSSEはクライアントがnonceを生成するのに対して、Digest認証ではサーバがnonceを生成する。nonceを取得するリクエストが必要無い分、WSSEの方が負荷が低い、のかな?

*2:とかのんきに言ってますが、自分も仕事でWSSEの実装をしたので全然他人事じゃないです……

上の続き

# 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があった場合、

  1. サービスA 認証方式a
  2. サービスA 認証方式b
  3. サービスB 認証方式a
  4. サービス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データのどっちを守るべきか、という話で、通信経路の方を守るのが正しい選択ということかなー。

以下の記事が参考になります。

ハッシュ関数を使って、通信経路とDBデータのどちらか一方しか守れないのはなぜ?

サーバがクライアントに尋ねる質問が、

  • このハッシュの中身を当てなさい。
  • この値を中身に含むハッシュを作りなさい。

の2つのうち、どちから1つだから、でしょうか。

  • Basic認証: 「このハッシュの中身を当てなさい。」
    • 入力は生 → 入力(生)からハッシュを計算
    • 盗聴に弱い。
    • DBデータはハッシュなので、漏洩しても入力(生)は得られない。
  • Digest認証: 「この値を中身に含むハッシュを作りなさい。」
    • 入力はハッシュ → DBデータ(生)からハッシュを計算
    • 漏洩に弱い。
    • 1回使った入力を無効にできるので、リプレイ攻撃に耐えられる。

ということなのかなー。