Kazuho@Cybozu Labs

3) パラメータ指定の手法について

　先にこちらから。

パラメータ指定は先日サポートしました。http://auth.hatena.ne.jp/help/api#p3 の最後の方。

　とのこと。ひとつ前のエントリを書いた段階では考えていなかったのですが、現在の署名生成手法と組み合わせて考えた場合に、あまりよろしくないように思います。

　というのは、サードパーティアプリケーション側で、未ログインだった場合にクエリパラメータをそのまま認証サーバへリダイレクトするようなコードを書いてしまうと、それを署名の偽造に利用される可能性が出てきてしまうからです。たとえば、

my $q = new CGI;
...
if (! $loggedin) {
    my $h = Hatena::API::Auth->new(...);
    redirect_and_exit($h->uri_to_login({ $q->Vars }));
}

のような認証コードを書いていると、このページに対して ?cert=52bc7c3bb92b6c22 のようなリクエストを投げることで、認証 API にアクセスするための署名を取得できてしまいます。現実には、

なお、certパラメータは一回使い切りの値になります。同じcertの値で再度ユーザー情報を取得することはできません。
(http://auth.hatena.ne.jp/help/api)

ということなので、タイミングの問題はあるのですが、少なくとも、署名が有効に機能していないことにはなってしまいます。

　とりあえず、現時点では、サードパーティアプリケーション側で汎用的なログイン処理を書く場合には、cert パラメータをログイン URL に含めないよう注意する必要があると思います。 (2006/05/07 修正: c=e&rt=... のような攻撃手法もありますね...)

　この問題については、今後の仕様改訂の際に、 URL Path も含めてハッシュ値を算出するようにすれば良いと思います。

1) MD5 の使用について

MD5 は Flickr のやつを真似たのと、パラメータをハッシュ化するのに MD5 が真っ先に思いついたからでそれ以上の理由はないかなあ。

　こういう場合は、HMAC を使うべきだと思います。現在のやり方だと、秘密鍵は被署名データの先頭にしか作用しないので、末尾を上手に構築することで攻撃が成立する可能性が (理論的には) あるような気がします(理論的には) 成立します。

　検算したわけではないですが、

[秘密鍵]api_key[API_KEY]appendDATA

のようなデータの MD5 値が既知の場合^注1に、

[秘密鍵]api_key[API_KEY]appendDATA\x80\0\0\0......\0\0\x02\x08cert[任意の cert 値]

の MD5 値は、秘密鍵を知らなくても算出できるように思いますすることができます。（この点については、奥の MD5 の理解が間違っている可能性があります）
(2006/05/07 追記: 詳しくは、次のエントリ をごらんください)

　現在の auth.json の実装は、未知のパラメータを無視して MD5 を計算するようになっているようなので、この点は実際には問題にならない^注2のですが、そもそも、このようなことが起こらないことを理論的に保証してくれるのが HMAC のすばらしいところだと思います。

注1: サードパーティアプリケーションの実装によっては、このような値を含むログイン URL を生成させることができる可能性があります
注2: クローン実装を作る場合とか、(僭越ですが) はてな内部でコードのバージョンアップをする場合には、注意が必要かも