なぞなぞ認証 - jkondoの日記
昨日からはてなダイアリーの閲覧許可設定に「なぞなぞ認証」を使うことができるようになった。 http://d.hatena.ne.jp/hatenadiary/20080124/1201172733 たとえば「僕の実家の町の名前は？」といった質問を設定しておくと、はてなアカウントをもっていなくても自分の実家を知っている人だけが読むことのできる日記を開設できる。今はダイアリーの閲覧許可だけだけど、これから編集許可やそのほかのサービスでも使えるようになっていく予定だ。 たとえばフォトライフなんかで、フォルダごとにイベントの写真を入れて、「結婚式会場の名前は？」みたいな質問を設定しておくとかも便利かも知れない。また、単に誰でも分かるような写真（たとえば「この山はなんでしょう？」「富士山」みたいな）、ロボットによるコメントスパムを排除することにも使えるだろう。 このなぞなぞ認証、実はパロアルトで増井
Kazuho@Cybozu Labs: はてな認証 API の改善案
« Re: 攻撃してください→はてな認証の仮想セッション | メイン | 目指せバイナリアン (C-0.06) » 2006年05月11日 はてな認証 API の改善案 だんだん自分の中でも認証 API の問題が整理できてきたように思うので、改善案を書こうと思います。 まず、そもそも認証 API に何を期待するのか、という点について。 従来の各サイト毎にパスワードを入力する方式は、 ・パスワード管理が面倒 ・HTTPS じゃないので、パスワードがネットワーク上を平文で流れる ・メールアドレスが漏洩するかも (スパム襲来) といった不便さや懸念がありました。しかし、外部の認証 API を使用するウェブアプリケーションについては、これらの問題が解消できるはずです。具体的には、cookie がもれない限り安全な認証 API注1があればベストでしょう。 で、はてな認証 API は、以下の各点を修正
Kazuho@Cybozu Labs: Re: 攻撃してください→はてな認証の仮想セッション
« はてな認証 API への攻撃シナリオ | メイン | はてな認証 API の改善案 » 2006年05月11日 Re: 攻撃してください→はてな認証の仮想セッション 先のエントリについて、tociyuki さんが、「セッションを開始しておけば、第三者にそのセッション ID が漏れない限りハイジャックするのは難しいのでは？」ということで、 セッションを作るときは下のようにするのが通常のやりかたです。これに対して「攻撃者がステップ 10 および 11 から cert のみを取得でき、被攻撃者のクッキーを読めない」という前提で、攻撃のシナリオはどうしたら良いのでしょうか？ 攻撃者と被攻撃者のクッキーのセッション ID は異なるとします。 (攻撃してください→はてな認証の仮想セッション) というエントリを書いていらっしゃいます。 そもそも、tociyuki さんが書いてらっしゃるような対策コー
Kazuho@Cybozu Labs: はてな認証 API への攻撃シナリオ
« 秘密鍵を後置している MAC の危険性 | メイン | Re: 攻撃してください→はてな認証の仮想セッション » 2006年05月09日 はてな認証 API への攻撃シナリオ 少し方向を変えて、 cert の漏洩に関する話です。 はてな認証 API における cert の使用法においては、 条件A) cert が第三者に漏洩しない 条件B) cert を最初に使うのがサードパーティアプリケーションである のいずれかが満たされれば良いです。 しかし、実際のところ cert が漏洩した場合に条件 B を破る (攻撃者の ?cert=... リクエストが、正規ユーザーのリクエストよりも先に処理されるようにする) ような攻撃を構築することは可能なので cert が漏洩する＝セッションハイジャックが可能注3になる、と考えなければなりません。 じゃあ、どういう場合に、cert が漏れるか、というこ
Kazuho@Cybozu Labs: 秘密鍵を後置している MAC の危険性
« Hash ≠ MAC | メイン | はてな認証 API への攻撃シナリオ » 2006年05月08日 秘密鍵を後置している MAC の危険性 先のエントリについて、結城さんが『「Hash ≠ MAC」の意味』に、まとめてくださっています。ありがとうございます。 16:37 追記: すいません。注1 の仮定が現実的でないように思います。よって、以下は成り立たないの攻撃は現時点では難しいかと。バイナリデータなら、TLV の L を、コリジョンデータの値が異なるところに着地させる可能なのかも。 ついでに、秘密鍵が後置されている場合のリスクについても考えていたのですが、 ハッシュ関数の衝突例が知られている 毎回選択平文攻撃が可能 ゴミデータの挿入が可能 (これは前置型と同等の条件) の３条件がすべて満たされている場合は、危険なんじゃないでしょうか。 というのは、同じハッシュ値をもつ "[ゴミ
Kazuho@Cybozu Labs: Hash ≠ MAC
« Re: はてな認証 API | メイン | 秘密鍵を後置している MAC の危険性 » 2006年05月07日 Hash ≠ MAC ハッシュ関数を MAC (メッセージ認証コード; いわゆる秘密鍵による署名) として使用していけません、という件について。 HMAC の論文を見たところ、様々な攻撃手法について述べてありました。ちなみに、今回のケースは、 Extension Attack です。引用すると、 Consider the "prepend-only" construction: MACk(x) = F(k, x) (i.e., the key k is prepended to the data x and the hash function - with the fixed IV - computed on the concatenated information). Be
Kazuho@Cybozu Labs: Re: はてな認証 API
« はてな認証 API | メイン | Hash ≠ MAC » 2006年05月06日 Re: はてな認証 API naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。 2006/5/7 追記: 1) で述べた MD5 による api_sig の偽装が可能であることを確認しました。この偽装を用いた攻撃は、auth.json および auth.xml については、1) に述べたとおり成功しません。認証リンクについては、仕様として任意のパラメータをハンドリングできる必要があるので、攻撃が成立してします (攻撃者がパラメータを追加することができる)。 よって、認証リンクの署名機能は壊れている、と言わざるを得ないように思います。 3) パラメータ指定の手法について 先にこちらから。 パラメータ指定は先日サポートしました。http://auth.ha
Kazuho@Cybozu Labs: はてな認証 API
« Lingua::JA::Summarize 0.03, 0.04 | メイン | Re: はてな認証 API » 2006年05月06日 はてな認証 API はてな認証 APIについて、気になったことを、忘れないうちにまとめておこうと思います。同様の指摘が既にあるかもしれませんが。 1) シンプルで美しい 安全性の評価は、一般的な Challenge-Response 型のプロトコル (cert の値が Challenge に相当) と考えればいいんでしょうか。でも、なぜ MD5 なの？ 2) ログイン用リンクに署名は不要 毎回同じ api_sig になるので、存在意義がないと思います。 3) コールバック URL が固定 パラメータを指定できたほうが良いと思います。固定のままでも、サードパーティアプリ側で Cookie を使えば、パラメータ指定と同等のことはできますが、処理が煩雑にな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
鰆缶 - はてなのアカウントでBasic認証より手軽にひそひそ話