「iモードが契約者IDを非公式サイトに対してもデフォルトで自動送信へ」記事へのコメント

サイトごとに異なるものにすればいいのに

[Livingdead (18685)]

たれ込みにもあるけど、サイトごとに異なるものにすればいいのに。
今まで使っているIDとサイトのIPアドレスを適当に連接して
ハッシュ取るだけでいいと思うんだが。
DNSラウンドロビンしてるサイトだとこまる？
でもそんなの普通サイト側で紐付けるとか工夫するでしょ。

--
屍体メモ [windy.cx]

Re:サイトごとに異なるものにすればいいのに

[Anonymous Coward]

ハッシュを使うと、ハッシュがやぶられたときに、他のサイトに渡している id が全部わかってしまうという危険があるのではないでしょうか。

uid 方式にこだわらず、単純に openid を使って、利用者が自発的に id を使い分ければいいのではないかと思うんだが、それだと何かまずいことがあるんだろうか？

Re:

[Anonymous Coward]

そんなふうにハッシュが破られることはないよ。

「全部わかってしまう」が起きるとすれば、ハッシュ関数の引数に付ける鍵が漏れたときだね。
たとえば、キャリア内で、
　　SHA1(userid + domainname + key)
で生成していたとしたら、もしkeyが漏洩しどうなるかって話かな。
その場合だって、
　　SHA1(userid + "attacker.com" + key)
の値から
　　SHA1(userid + "example.com" + key)
の値を計算することはできないよね。
この場合、もしuseridが連番だったら、全部あらかじめ計算しておけるからアウトか。
だから、userid がスパース（例えば百

Re:

[Anonymous Coward]

そんなふうにハッシュが破られることはないよ。

「そんなふうに」でどういう状況を想定しているのか知りませんが、実際に MD5 の脆弱性を利用して APOP で元のパスワードを復元するアタックが知られています。ハッシュに脆弱性が見つかって、適切に選んだ複数のドメイン名に対する結果から key や userid を復元できるようになる可能性はあるんです。

現在ハッシュが安全だとしても、将来脆弱性が発見されないという保証はありません。ハッシュを使う目的が認証や署名であれば、その部分を新しいアルゴリズムで置き換えればすみます。しかし、ユーザーIDのように、継続的に使うことが前提とされているものにハッシュを使うのは、脆弱性が発見されたときに置き換えるのが難しいですから、あまりいいアイデアとは言えないでしょう。

Re:

[Anonymous Coward]

実際に MD5 の脆弱性を利用して APOP で元のパスワードを復元するアタックが知られています。ハッシュに脆弱性が見つかって、適切に選んだ複数のドメイン名に対する結果から key や userid を復元できるようになる可能性はあるんです。

key と userid を復元するのにいったいどれだけの数のドメイン名を用意しないといけないのだか。

Re:

[Anonymous Coward]

key と userid を復元するのにいったいどれだけの数のドメイン名を用意しないといけないのだか。

MD5 の脆弱性による APOP のパスワード解析の場合、チャレンジレスポンス60回でパスワードが１文字判明します。必要なチャレンジ文字列（ドメイン名に相当）の数は、10文字なら600個、100文字で6千個ですね（APOP のパスワード解析は最大61文字とされてますが）。DNS クラックや国レベルのアタック、架空口座によるドメイン作成のような不正は考えず、正式な手続きで用意したとしても、企業なら楽勝、その辺のスパマーでも可能なレベルです。