« Re: 攻撃してください→はてな認証の仮想セッション | メイン | 目指せバイナリアン (C-0.06) »

2006年05月11日

はてな認証 API の改善案

 だんだん自分の中でも認証 API の問題が整理できてきたように思うので、改善案を書こうと思います。
 
 まず、そもそも認証 API に何を期待するのか、という点について。

 従来の各サイト毎にパスワードを入力する方式は、

・パスワード管理が面倒
・HTTPS じゃないので、パスワードがネットワーク上を平文で流れる
・メールアドレスが漏洩するかも (スパム襲来)

といった不便さや懸念がありました。しかし、外部の認証 API を使用するウェブアプリケーションについては、これらの問題が解消できるはずです。具体的には、cookie がもれない限り安全な認証 API注1があればベストでしょう。

 で、はてな認証 API は、以下の各点を修正すれば、そのような完全な API になるんじゃないかと思っています。

1) ちゃんとした MAC を使う注2
 1.1) HMAC_SHA1 を使うべき
 1.2) パラメータの結合方法を修正すべき注3
 1.3) 実行している機能の識別子も MAC に含める
2) コールバック URL の cert を暗号化する
 F(cert, 秘密鍵) を auth.json の引数にする、ということ注4
3) callback URL にも MAC をつける
4) サードパーティアプリケーションに、認証リンクのパラメータとしてユーザーのセッション情報を特定する情報を入れるよう要請する (ライブラリレベルで対応?)

 以上でいいと思っています。まだ確信を持って言えるわけではないですが、だいたいあってるような気がします。そこまでやるべきか、という議論はあるかもしれませんが。

11:34 追記: 3, 4 が満たされれば、サードパーティアプリケーション側でセッションのトレースができるので 2 は不要でしょうか。



注1: URL がもれたり、あるいは、HTML がもれたとしても、です
注2: 任意のパラメータを許可する方式だと依存するハッシュ関数の強衝突耐性が破られた場合に脆弱になる可能性があるので、サードパーティアプリケーションが指定できるパラメータは1つだけにするほうがベターです
注3: 現在のやりかただと、 answer=CAcert1234 と answer=CA&cert=1234 の区別がつきません
注4: 共通鍵暗号はこの目的に使える (F が復号化関数) として、ハッシュ系を使う際に注意すべきことはありましたっけ?

投稿者 kazuho : 2006年05月11日 10:59 このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

トラックバック

このエントリーのトラックバックURL:
http://labs.cybozu.co.jp/cgi-bin/mt-admin/mt-tbp.cgi/591

このリストは、次のエントリーを参照しています: はてな認証 API の改善案:

» RE: はてな認証 API の改善案 from ナンセンス不定記
Kazuho@Cybozu Labs: はてな認証 API の改善案 1) ちゃんとした MAC を使う注2  1.1) HMAC_SHA1 を使うべき... [続きを読む]

トラックバック時刻: 2006年05月16日 07:20

コメント

分かったようで分からないような・・でして、いくつか質問を。
1)3つとも理解しました。
2)これはサードパーティアプリがauth.jsonへアクセスする際に暗号化でしょうか? それとも認証サーバーからブラウザ経由でサードパティアプリにリダイレクトする際のcertを暗号化でしょうか?
3)(どこからどこの)「callback URL」にどのようにMACを付けるのかが理解できませんでした。
4)サードパーティアプリがcookieを使用する代わりに、自前でセッションIDをパラメータとして付加するということでしょうか?

一番よく分からなかったのが、前エントリ『Re: 攻撃してください→はてな認証の仮想セッション』の対策が何番でできるのか?ということです。

投稿者 もとむら : 2006年05月14日 23:42

> 2)

後者です。サードパーティアプリケーション (TPA) の認証ハンドラの URL です。

> 3)

TPA の認証ハンドラの URL です。

> 4)

前のエントリのように、TPA 側でセッションを開始し、そのセッションを特定するような情報を認証リンクに埋め込む、ということです。

前のエントリについてですが、TPA の防衛手法は、あれで正しいと思っています (POST に絡めて外部サイトとやりとりする際の汎用性のある手法だと思います)
ただ、攻撃が成立してしまうのは、TPA 側で、 cert がどのセッションに対して発行されたのか、判別する手法がないからです。
判別するためには、セッションを特定する情報 (前のエントリにおける mycert) と cert を攻撃者が切り果たして使用することを防げば良い、つまり、3) を行えばよい、ということです。

投稿者 kazuho : 2006年05月15日 11:34

コメントありがとうございます。最終的には1と3と4が必要なのかな?(1と3や1と4では不十分)という結論に達しました。
コメントで書くには長くなると思ったので、↓のリンクを参照してください。
http://d.hatena.ne.jp/hiuchida/20060516/1147731249

投稿者 もとむら : 2006年05月16日 07:19

もとむらさん、ありがとうございます。異論ありません。

投稿者 kazuho : 2006年05月18日 16:52