回答:
OpenIDは、エンドポイントを信頼する必要があるシステムの1つです。RPが信頼できない場合、この種のアソシエーションポイズニングは完全に可能です。RPが実際に信頼できる場合、この種の攻撃は非常に難しくなります。この攻撃に対して脆弱ではないための「回避策」は、外部のOpenIDエンドポイント(OpenID URL、ServerFaultで複数を関連付けることができるようにすることで、ローカルセキュリティ原則(バックエンドデータベースでのユーザー名の表現になります)にキーを設定することですこれらの)。
たとえば、*。livejournal.comが攻撃用に特別に作成したOPにリダイレクトされるように、RPの部分に対するDNSポイズニング攻撃によって攻撃することもできます。しかし、それはDNS中毒攻撃であり、OpenID自体の障害ではありません。OpenIDは、DNSポイショニングに対して脆弱です。
OpenIDとUser Securityの他の部分を混同していると思います。OPは認証メカニズムであり、アカウントではありません。ここServerFaultには、アカウントがあります。そのアカウントには、それ自体では認証の手段がありません。1つ以上のOPを指すことを除きます。
ここでSFとしてアカウントにログインしようとすると、認証を処理するようにOPに要求されます。SFアカウントの目的のために認証できるのは、その1つのOP(または複数のOP、ただし設定している場合)だけです。
一般的なログインシステムには、3つの部分があります(トリプル「A」または単に「AAA」と呼ばれます)。
ウィキペディアでAAAシステムの詳細を読むことができます。
デビッド、あなたの仮定は間違っています。OpenIDは次のように機能します。1)にサイトにログインしたいdavid.comで見つけることができるOpenIDエンドポイントと呼ばれますが、委任の手段を使用して、yahoo.comやgoogle.comなどの別の場所でも見つけることができます。davidsopenidprovider.comと呼びましょう。4)davidsopenidprovider.comにリダイレクトされました。davidsopenidprovider.comの仕事はあなたを認証することです。davidsopenidprovider.comにログインする必要があります。このログインがどのように機能するかは、davidsopenidprovider.com次第です。ユーザー名/パスワード、情報カード、ブラウザ証明書、指紋、スマートカード、コール検証などの帯域外メカニズムなどがあります... davidsopenidprovider次第です。comが認証を処理する方法。次に、relyingparty.comに本当にログインするかどうかを尋ねられます。5)davidsopenidprovider.comに正常にログインすると、relyingparty.comにリダイレクトされ、そこに自動的にログインします。6)davidsopenidprovider.comは、reliingparty.comがあなたが本人であることを保証するだけです。パスワードは送信されません。
あなたの仮定は、「消費者として、any-site.comでアカウントを作成するとき、開発者/サイト管理者の知性という概念がありません。」OpenIDに関してはfalseです。弱点がある場合、それはプロバイダーですが、any-site.comではありません。これが従来のユーザー名/パスワードによるログインの問題です。OpenIDプロバイダーだけでなく、そのようにログインを提供する各サイトを信頼する必要があります。
これがOpenIDの理解に役立つことを願っています。
彼らがどうやって知っているのですか?
古いサイトが他の誰かにパスワードを渡すことを知っているのと同じように-あなたはそうではありません。だからこそ、評判の良い会社になる可能性の高いものを使用します。
OpenIDも変更しない限り、OPを変更することはできません。
もちろんできます。OpenIDの委任を調べてください。
私のOpenIDはhttp://ceejayoz.com/ですが、私のOPはWordPress.comです。http://ceejayoz.com/META
の先頭にある2つのタグにより、これを行うことができ、いつでも好きなときに変更できます。
これは私がここでの回答から獲得したものです...
OpenIDは、関係者と同じくらい安全であり、それはどの認証方法にも当てはまります。私はこの議論を始める前にそのことに気づきました。
OpenIDの問題は、私には2つの問題があるようです...
LoginIDは、ユーザーとユーザーが使用するサイト間でのみ共有される秘密ではなくなりました。これはOpenIDであり、それを使用するすべてのサイトで認識されており、電子メールアドレス、または電子メールアドレスなどから簡単に推測できるものです。
RPは、広く受け入れられている安全な「プロトコル」を使用しているため、デューデリジェンスを行わずにサイトにOpenIPを実装できます。確かに、ほとんどのすぐに使えるWebサイト開発者は、サイトをセキュリティで保護する方法についての真の概念を持ちませんが、独自のセキュリティを実装する場合、少なくとも問題#1は関係ありません。
消費者として、any-site.comでアカウントを作成するとき、開発者/サイトマネージャーの知性の概念はありません。簡単に推測できるとは思わないIDを使用しています。serverfault.comにEtrade.comへのログインに使用するIDを知らせたくありません。また、すべてのサイトで異なるパスワードを使用し、それらのパスワードを独自のスキームで管理しています。サイト運営者が完全にばかでない限り、私のアカウントが構成されることはほとんどありません。
OpenIDを使用すると、RPに適切な対策が講じられていない場合、WEBの全員がその仕組みと攻撃方法を把握できます。
私はオープンソースソフトウェアが大好きですが、OpenIDの場合、疑いを持たない採用者が利用できる劣った実装が存在する可能性が開かれると思います。
これは、サイトが監査に合格し、ハッキングに対して耐久性がないことを消費者に保証する承認された署名シールによってすべて解決できると思います。
たぶん私はただの妄想です。