Ist OpenID so einfach zu hacken oder fehlt mir etwas?

Für diejenigen Relying Parties (RP), die es dem Benutzer ermöglichen, den OpenID-Provider (OP) anzugeben, scheint es mir, als wenn jemand Ihre OpenID kennt oder errät

1. Geben Sie ihre eigene OP-Adresse ein.
2. Lassen Sie sie als Eigentümer Ihrer OpenID validieren.
3. Greifen Sie auf Ihr Konto im RP zu.

Der RP "könnte" Maßnahmen ergreifen, um dies zu verhindern, indem er nur zulässt, dass die OpenID vom ursprünglichen OP validiert wird, aber ...

1. Woher weißt du, dass sie es tun?
2. Sie könnten Ihr OP niemals ändern, ohne auch Ihre OpenID zu ändern.

OpenID ist eines jener Systeme, auf denen Sie den Endpunkten vertrauen müssen. Wenn die RP nicht vertrauenswürdig ist, ist diese Art der Assoziationsvergiftung durchaus möglich. Wenn der RP tatsächlich vertrauenswürdig ist, ist diese Art von Angriff VIEL schwerer. Um dieses Problem zu umgehen, müssen Sie das lokale Sicherheitsprinzip (bei ServerFault ist dies die Darstellung Ihres Benutzernamens in der Back-End-Datenbank) mit dem fremden OpenID-Endpunkt (die OpenID-URL, mit ServerFault können Sie mehrere verknüpfen) festlegen von diesen).

Sie können weiterhin über einen DNS-Vergiftungsangriff des RP angreifen, sodass beispielsweise "* .livejournal.com" an ein OP weitergeleitet wird, das Sie speziell für den Angriff erstellt haben. Aber das ist ein DNS-Vergiftungsangriff, kein Fehler in OpenID. OpenID ist nur für DNS-Poisioning anfällig.

Ich denke, Sie verwechseln OpenID und die anderen Teile von User Security. Ihr OP ist der Authentifizierungsmechanismus, nicht Ihr Konto. Hier bei ServerFault haben Sie ein Konto. Dieses Konto hat keine Möglichkeit, sich selbst zu authentifizieren. außer Sie zeigen es auf einen oder mehrere OPs.

Wenn Sie versuchen, sich hier als SF in Ihrem Konto anzumelden, wird Ihr OP aufgefordert, die Authentifizierung durchzuführen. Nur dieses eine OP (oder die mehreren OPs, wie auch immer Sie es eingerichtet haben) können Sie für die Zwecke Ihres SF-Kontos authentifizieren.

Ein typisches Anmeldesystem (Triple "A" oder einfach "AAA") besteht aus drei Teilen:

• Buchhaltung - Verfolgt Ihren Namen und die für die Site spezifischen Informationen (wie Posts, Nachrichten usw.)
• Authentifizierung - Verfolgt, wie Sie sicherstellen können, dass Sie es wirklich sind (normalerweise ein Kennwort)
• Autorisierung - Behalten Sie die Übersicht über Ihre Berechtigungen (Lese- oder Schreibzugriff auf verschiedene Dinge)

Weitere Informationen zu AAA-Systemen finden Sie auf Wikipedia.

David, deine Annahme ist falsch. OpenID funktioniert wie folgt: 1) Sie möchten sich auf der Website "reliingparty.com" anmelden. 2) Sie geben "reliingparty.com" Ihre OpenID an, z OpenID-Endpunkt genannt, der bei david.com zu finden ist, aber über Delegation auch an einer anderen Stelle, z. B. yahoo.com oder google.com. Nennen wir es davidsopenidprovider.com. 4) Sie werden jetzt zu davidsopenidprovider.com umgeleitet. davidsopenidprovider.com hat die Aufgabe, Sie zu authentifizieren. Sie müssen sich bei davidsopenidprovider.com anmelden. Es liegt an davidsopenidprovider.com, wie dieses Login funktioniert. Es kann sich um einen Benutzernamen / ein Passwort handeln, es können Informationskarten, Browser-Zertifikate, Fingerabdrücke, Smartcards, Out-of-Band-Mechanismen wie Anrufüberprüfung usw. sein. Es liegt an davidsopenidprovider. com wie es mit Authentifizierung umgeht. Dann werden Sie gefragt, ob Sie sich wirklich bei trustingparty.com anmelden möchten. 5) Wenn Sie sich erfolgreich bei davidsopenidprovider.com angemeldet haben, werden Sie zurück zu dependingparty.com geleitet und dort automatisch angemeldet. 6) davidsopenidprovider.com versichert lediglich, dass Sie derjenige sind, für den Sie sich ausgeben. Es wird kein Passwort gesendet.

Ihre Vermutung: "Als Verbraucher habe ich beim Erstellen eines Kontos auf any-site.com keine Ahnung von der Intelligenz der Entwickler / Site-Manager." ist falsch in Bezug auf OpenID. Wenn es eine Schwachstelle gibt, ist es der Anbieter, aber nicht any-site.com. Das ist das Problem bei herkömmlichen Benutzernamen- / Passwortanmeldungen. Sie müssen jeder Site vertrauen, die auf diese Weise Anmeldungen anbietet, und nicht nur einer, Ihrem OpenID-Anbieter.

Ich hoffe, dies hilft beim Verständnis von OpenID.

Woher weißt du, dass sie es tun?

Genauso wie Sie wissen, dass eine alte Website Ihr Passwort an eine andere Person weitergibt - tun Sie das nicht. Deshalb verwenden Sie, was wahrscheinlich ein seriöses Unternehmen ist.

Sie könnten Ihr OP niemals ändern, ohne auch Ihre OpenID zu ändern.

Sicher kannst du. Sehen Sie sich die OpenID-Delegierung an.

Meine OpenID ist http://ceejayoz.com/ , aber mein OP ist WordPress.com. Zwei METATags im Kopf von http://ceejayoz.com/ ermöglichen es mir, dies zu tun, und ich kann es jederzeit ändern, wenn ich möchte.

Ihre openID ist Ihr Provider. pwnguin.netist meine openID. Dies unterliegt keiner Vermutung, es ist einfach eine bekannte Tatsache. Was meine openID schützt, ist die auf pwnguin.net ausgeführte Software, die nur dann zustimmt, wenn der betreffende Besucher ein Authentifizierungscookie hat.

Ich sage nicht, dass openID sicher ist. Es gibt alle Arten von Cross-Site-Skripten, die weitergehen könnten, oder einige profane Details, die ich normalerweise ignoriere oder falsch verstehe.

Dies ist, was ich aus den Antworten hier gesammelt habe ...

OpenID ist nur so sicher wie die beteiligten Parteien, und das gilt für jede Authentifizierungsmethode. Das wurde mir klar, bevor ich mit dieser Diskussion anfing.

Das Problem mit OpenID ist meines Erachtens zweifach ...

1. Ihre LoginID ist kein Geheimnis mehr, das nur von Ihnen und der Site, auf der Sie sie verwenden, geteilt wird. Es ist Ihre OpenID, die von jeder Site bekannt ist, auf der Sie sie verwenden, und die leicht zu erraten ist, z. B. eine E-Mail-Adresse oder eine von Ihrer E-Mail-Adresse abgeleitete Adresse oder ähnliches.

2. RPs können OpenIP auf ihrer Site implementieren, ohne dass dies einer sorgfältigen Prüfung bedarf, sofern sie ein allgemein akzeptiertes, sicheres 'Protokoll verwenden. Zugegeben, die meisten gewöhnlichen Website-Entwickler haben keine wirkliche Vorstellung davon, wie eine Website geschützt werden soll, aber wenn sie ihre eigene Sicherheit implementieren, kommt zumindest das erste Problem nicht ins Spiel.

Als Verbraucher habe ich beim Erstellen eines Kontos auf any-site.com keine Ahnung von der Intelligenz der Entwickler / Site-Manager. Ich verwende einen Ausweis, von dem ich nicht glaube, dass er leicht zu erraten ist. Ich möchte nicht, dass serverfault.com die ID kennt, mit der ich mich bei Etrade.com anmelde. Ich verwende außerdem auf jeder Site ein anderes Kennwort und verwalte diese Kennwörter nach meinem eigenen Schema. Es ist sehr unwahrscheinlich, dass mein Konto enthalten sein wird, es sei denn, die Betreiber der Website sind absolute Idioten.

Mit OpenID weiß jeder im WEB, wie es funktioniert und wie man es angreift, sollte das RP nicht über geeignete Maßnahmen verfügen.

Ich liebe Open-Source-Software, aber im Fall von OpenID eröffnet sich meiner Meinung nach die Möglichkeit, dass ahnungslosen Anwendern minderwertige Implementierungen zur Verfügung stehen.

Ich denke, dies könnte alles durch ein unterschriebenes Gütesiegel gelöst werden, das dem Verbraucher versichert, dass die Website ein Audit bestanden hat und nicht gegen Hacks geschützt ist.

Vielleicht bin ich nur paranoid.