OpenIDはこれほど簡単にハッキングできますか、それとも何かが足りませんか？
ユーザーがOpenIDプロバイダー（OP）を指定できるようにする証明書利用者（RP）の場合、OpenIDを知っている、または推測できる人よりも私には思えます。
- 独自のOPアドレスを入力します。
- OpenIDを所有していることを検証してもらいます。
- RPでアカウントにアクセスします。
RPは、OpenIDを元のOPでのみ検証できるようにすることで、これを防ぐための対策を講じることができますが、...
- 彼らがそうしていることをどうやって知っていますか？
- OpenIDも変更せずにOPを変更することはできません。
OpenIDは、エンドポイントを信頼する必要があるシステムの1つです。 RPが信頼できない場合、この種の アソシエーションポイズニング は完全に可能です。 RPが実際に信頼できる場合、この種の攻撃ははるかに困難です。この攻撃に対して脆弱ではないための「回避策」は、ローカルセキュリティの原則（ServerFaultでは、これはバックエンドデータベースでのユーザー名の表現になります）を外部のOpenIDエンドポイント（OpenID URL、ServerFaultでは複数を関連付けることができます）でキーイングすることです。これらの）。
RP側でDNSポイズニング攻撃を介して攻撃することもできます。たとえば、*。livejournal.comは、攻撃用に特別に作成したOPにリダイレクトされます。しかし、これはDNSポイズニング攻撃であり、OpenID自体の障害ではありません。 OpenIDは、DNSポイズニングに対して脆弱です。
OpenIDとユーザーセキュリティの他の部分を混同していると思います。 OPは認証メカニズムであり、アカウントではありません。ここServerFaultには、アカウントがあります。そのアカウントには、それ自体で認証の手段がありません。ただし、1つ以上のOPをポイントします。
ここでSFとしてアカウントにログインしようとすると、OPに認証を処理するように要求されます。 SFアカウントの目的で認証できるのは、その1つのOP（または複数のOP、ただしセットアップ済み）のみです。
一般的なログインシステムには3つの部分があります（トリプル「A」または単に「AAA」と呼ばれます）。
- 経理-あなたの名前とサイトに固有の情報（投稿、メッセージなど）を追跡します
- 認証-本人であることを確認する方法（通常はパスワード）を追跡します
- 承認-あなたの許可を追跡します（さまざまなものへの読み取りまたは書き込みアクセス）
AAAシステム について詳しくはウィキペディアをご覧ください。
デビッド、あなたの仮定は間違っています。 OpenIDは次のように機能します：1）サイトrelyingparty.comにログインしたい2）relyingparty.comにOpenIDを指定します。 david.com 3）relyingparty.comは、david.comで見つけることができるいわゆるOpenIDエンドポイントについてdavid.com（ねえ、それはURLです）をチェックしますが、委任によって他の場所にもあります。 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は、あなたが本人であるとrelyingparty.comに保証するだけです。パスワードは送信されません。
したがって、「消費者として、any-site.comでアカウントを作成するとき、開発者/サイト管理者の知性についての概念はありません。」 OpenIDに関してはfalseです。弱点がある場合、それはプロバイダーですが、any-site.comではありません。これが、従来のユーザー名/パスワードログインの問題です。 OpenIDプロバイダーだけでなく、その方法でログインを提供する各サイトを信頼する必要があります。
これがOpenIDの理解に役立つことを願っています。
OpenIDはプロバイダーです。 pwnguin.netは私のopenIDです。これは推測の対象ではなく、単に既知の事実です。私のopenIDを保護するのは、pwnguin.netで実行されているソフトウェアです。このソフトウェアは、問題の訪問者が認証Cookieを持っている場合にのみ肯定的に応答します。
OpenIDが安全だとは言いません。進行する可能性のあるあらゆる種類のクロスサイトスクリプティング、または私が無視したり間違えたりする傾向のあるありふれた詳細があります。
彼らがそうしていることをどうやって知っていますか？
古いサイトがあなたのパスワードを他の誰かに渡していることをあなたが知っているのと同じ方法-あなたはそうしません。だからこそ、評判の良い会社になりそうな会社を利用するのです。
OpenIDも変更せずにOPを変更することはできません。
もちろんできます。 OpenID委任を調べます。
私のOpenIDは http://ceejayoz.com/ ですが、私のOPはWordPress.comです。 http://ceejayoz.com/ の先頭にある2つのMETAタグを使用すると、これを実行できます。いつでも変更できます。
これは私がここでの返信から得たものです...
OpenIDは関係者と同じくらい安全であり、それはどの認証方法にも当てはまります。私はこの議論を始める前に気づきました。
私が思うに、OpenIDの問題は2つあります...
LoginIDは、あなたとそれを使用するサイトの間でのみ共有される秘密ではなくなりました。これはOpenIDであり、使用するすべてのサイトで認識されており、電子メールアドレスや電子メールアドレスから派生したものなど、簡単に推測できるものです。
RPは、広く受け入れられている「プロトコル」を使用しているため、安全であると想定して、デューデリジェンスを行わずにサイトにOpenIPを実装できます。確かに、ほとんどの一般的なWebサイト開発者は、サイトを保護する方法について真の概念を持っていませんが、独自のセキュリティを実装している場合、少なくとも問題1は発生しません。
消費者として、any-site.comでアカウントを作成するとき、開発者/サイト管理者の知性についての概念はありません。簡単に推測できないIDを使用しています。 Etrade.comへのログインに使用するIDをserverfault.comに知らせたくありません。また、サイトごとに異なるパスワードを使用し、独自のスキームでそれらのパスワードを管理しています。サイト運営者が完全な馬鹿でない限り、私のアカウントが構成される可能性はほとんどありません。
OpenIDを使用すると、RPに適切な対策が講じられていない場合に、WEBの全員がそれがどのように機能し、どのように攻撃するかを知っています。
私はオープンソースソフトウェアが大好きですが、OpenIDの場合、疑いを持たない採用者が利用できる劣った実装がある可能性が開かれると思います。
これは、サイトが監査に合格し、ハッキングに対して脆弱ではないことを消費者に保証する署名済みの承認シールによってすべて解決できると思います。
多分私はただの妄想です。