OpenID

Allgemeine Informationen zu OpenID

OpenID ist eine Web-Technologie zur Authentifikation. Technisch gesprochen ist es ein offener Standard in Form eines Authentifikationsprotokoll zur Kommunikation zwischen Internetdiensten und Internet-Nutzern. Die Idee dabei ist, erstens, dem Internet-Nutzer den Umgang mit Internet-Diensten durch die Verwendung eines einzigen Kontos, und damit eines einzigen Kennworts, zu erleichtern. Zweitens sollte der Nutzer frei entscheiden können, welchem OpenID-Provider er vertrauen möchte. Eine weitere Annehmlichkeit ist die Tatsache, dass jedermann ein OpenID-Provider werden kann. Damit wird der Forderung eines dezentralisierten Systems Rechnung getragen.

Sicherheitstechnisch sieht das Protokoll zwei weitere allgemeine Aspekte vor: Zum einen, dass das Kennwort nicht an den Dienstanbieter übertragen wird und zum anderen, dass dem Nutzer zusätzlich die Möglichkeit gegeben wird, darüber zu entscheiden, welchem Dienstanbieter er welche persönlichen Daten zur Verfügung stellt (sharing).

Das Protokoll arbeitet im Kern mit einem sogenannten Identifikator, der einem Nutzer zugeordnet ist und pseudonymisierbar ist. Das oberste Ziel des Protokolls ist es, die Zugehörigkeit des Identifikator zum Nutzer zu prüfen. Als Netzwerkprotokoll dient HTTP(s). So ist sichergestellt, dass keine weiteren Spezialfunktionen beim User-Agent (Browser) erforderlich sind. Cookies und Ajax-Erweiterungen können die Interaktion vereinfachen. Im Folgenden beziehe ich mich auf die OpenID-Spezifikation in der Version 2.0 und speziell auf die Kommunikation mittels HTML-Dokumenten (Alternative: XRDS-Dokumente).

Akteure

OpenID: Ein Satz von Daten.

OpenID-Provider (OP): Verwahrt und administriert die OpenIDs.

Der Internet-Nutzer: Die OpenID ist seine digitale Identität, die er als Dienstleistung vom Provider in Anspruch nimmt.

Der Web-Dienst: Ein Dienst, der durch den Nutzer mittels einer OpenID in Anspruch genommen wird. Hierbei handelt es sich um eine OpenID-fähige Webseite.

Discovery-Server: Bevor die OpenID-Daten vom OpenID-Provider abgefragt werden, werden Metainformationen mit einem Discovery-Server ausgetauscht. Üblicherweise fällt dieser jedoch mit dem OpenID-Provider zusammen.

Struktur des Authentifikations-Protokolls

Vorbemerkung zur Datenstruktur Wie schon erwähnt, wird zur Kommunikation das HTTP(s)-Protokoll benutzt und insbesondere Web-Formulare eingesetzt. OpenID-Daten haben in der Regel die Form openid.<VARIABLE> = '<VALUE>' und sind in der Struktur von Formularfeldern kodiert. Beispiel: <input type=“text“ name=“openid.mode“ value=“associate“>

Die Authentifikation gliedert sich grob in drei Phase: der Initiierungs- und Feststellungsphase (Kennenlernen), der optionalen Assoziationsphase (Kanal aufbauen) und der Phase der Authentisierung bzw. Authentifizierung. Es folgen die Phasen im Einzelnen.

Initiierung- und Feststellung (engl. Discovery)

Nach dem man eine Anfrage zur Benutzung eines bestimmten Web-Dienstes (z.B. E-Mail) gestellt hat, erhält man ein Formular als Antwort. Der erste Schritt ist nun die Eingabe des („claimed“) Identifikators, zum Beispiel zeitgeist09.openid.com. Das Ziel des Ganzen ist es, wie gesagt, die Zugehörigkeit dieses Identifikators zum Nutzer zu überprüfen.

Gleichzeitig ist dieser Identifikator eine Referenz auf eine Informationsseite, auf der sich Meta-Informationen für den Web-Dienst zum Ablauf der Kommunikation befinden: Welche Protokollversion wird benutzt? Wo befindet sich der Namespace, d. h. die eigentliche Informationsquelle? Ist der OpenID-Provider festgestellt, beginnt die (optionale) Assoziationsphase.

(Optionale) Assoziation

Diese Phase ist optional und empfohlen, wenn beide Seiten die Möglichkeit haben, Sitzungsinformationen abzuspeichern. Das Ziel dieser Phase ist der Aufbau eines sogenannten „shared secretes“ zwischen dem Web-Dienst und dem OpenID-Provider. Es handelt sich hierbei um einen MAC-Schlüssel, der später dem Signieren bzw. der Verifizierung von sogenannten Versicherungen (engl. Assertion) dient. Kommuniziert wird mittels direkter HTTP-Requests und -Responds. Web-Dienst und Provider verhandeln nun unter anderem über die Verwendung des Signieralgorithmus (HMAC-SHA1, HMAC-SHA256) und wenn möglich über den Verschlüsselungsalgorithmus (no-encryption, DH-SHA1, DH-SHA256) für die Verschlüsselung des MAC-Schlüssels. Es gibt zwei Möglichkeiten: Entweder wird auf Transportebene verschlüsselt, so dass eine Verschlüsselung des MAC-Schlüssels nicht nötig ist, oder der MAC-Schlüssel wird per DH-SHA1 bzw. DH-SHA256 verschlüsselt. Letzteres funktioniert folgendermaßen:

1. Der Web-Dienst verschickt in einem ersten Request die DH-Parameter: Modul (m), Generator (g) und seinen öffentlichen Schlüssel ($g^{xa}modp$).
2. Der Provider berechnet nun aus dem öffentlichen Schlüssel des Web-Dienstes und seinem privaten Schlüssel den DH-Schlüssel. Nun sendet der Provider in einem Respond die fehlende Diffie-Hellman-Information: seinen öffentlichen Schlüssel ($g^{xb}modp$). Des Weiteren generiert er einen MAC-Schlüssel, den er nun mit dem neuen DH-Schlüssel verschlüsselt: Hash(DH-Schlüssel) XOR MAC-Schlüssel. Wie man sieht, wird der DH-Schlüssel zuvor mit SHA1 bzw. SHA256 gehasht.
3. Der Web-Dienst kann nun auch das „shared secrete“ berechnen. Nun ist er auch in der Lage, den mitgelieferten verschlüsselten MAC-Schlüssel durch eine einfache XOR-Verknüpfung zu entschlüsseln.

Authentifizierung

Im Gegensatz zur Assoziierung erfolgt die Kommunikation zwischen Web-Dienst und Provider immer über den Internet-Nutzer (indirekte Kommunikation). Eine explizite Erklärung gibt es dafür jedoch nicht. Das Ziel dieser Phase ist es nun, Gewissheit in Form einer „Assertion“ zu erlangen über die Zugehörigkeit des Identifikator zum Besitzer. Dazu schickt der Web-Dienst als erstes eine Authentifizierungsanfrage, in der er dem Provider mitteilt,

1. um wen es geht (Nutzer-Identifikator),
2. wer er selber ist, um die Rückumleitung für eine Antwort zu ermöglichen und
3. welche Nutzerdaten er benötigt.

Der nächste Schritt ist im Protokoll nicht spezifiziert und hängt vom Provider ab. Sein Anliegen ist es, die Identität des betroffenen Nutzers zu prüfen, beispielsweise durch die Eingabe eines Kennwortes, um dem Web-Dienst eine negative beziehungsweise positive Versicherung (Assertion) zuzusenden.

Als Antwort erhält der Web-Dienst nun jene Versicherung. Es stellt sich nun die Frage bevor er die Versicherung auswertet, woher er wissen kann, dass diese Versicherung echt ist. Aus diesem Grund muss die Versicherung geprüft werden. Dafür gibt es zwei Wege, die im Folgenden erklärt werden.

Verifikation mittels Assoziation

Voraussetzung hierfür ist die Vollendung der Assoziationsphase und damit die Existenz eines „shared key“. Vier Bedingungen müssen erfüllt sein, damit eine Versicherung von dem Web-Dienst akzeptiert werden kann.

1. Die Rückumleitungs-URL (openid.returnurl) muss gleich seiner eigenen URL sein.
2. Die Informationen aus der Feststellungsphase müssen den Informationen in der Versicherung entsprechen.
3. Die Versicherung, die einen bestimmten Nonce-Wert enthält, wurde zuvor noch nicht von speziell diesem Provider akzeptiert.
4. Die Signatur ist valide und alle Felder, die signiert werden mussten, sind signiert.

Direkter Verifikation über den Provider

Dieser Schritt sollte eher eine Ausnahme darstellen, und zwar für den Fall, dass die Assoziationsphase ausgelassen wurde oder aber die Assoziation nicht mehr gültig ist (Zerfall des „shared secretes“). Unter diesen Umtänden muss der Web-Dienst trotzdem prüfen können, ob die vom Nutzer weitergeleitete Versicherung echt ist. Die Idee dabei klingt im ersten Moment komisch: die erhaltene Versicherung lässt sich der Drittanbieter per direkter Kommunikation nochmals vom selben OpenID-Provider gegenprüfen. Anders ausgedrückt heißt dies, dass die Versicherung vom OpenID-Provider zum Nutzer, vom Nutzer zum Drittanbieter, vom Drittanbieter zum OpenID-Provider weitergeleitet wird und dieser seine eigene Unterschrift prüft und eine direkte Antwort zum Drittanbieter zurückschickt.

Aus technischer Sicht muss dafür die Bedingung erfüllt sein, dass der Provider einen privaten Assoziations-Handle gespeichert hat. Dieses Handle muss in der Versicherung enthalten sein und mit dem Handle selbst unterschrieben sein. Nach Erhalt der Versicherung sendet der Web-Dienst eine Kopie der erhaltenen Versicherungsdaten direkt an den Provider zurück. Dieser verifiziert die exakte Übereinstimmung und prüft auch die von ihm ehemals erstellte Signatur mit dem privaten Assoziations-Handle. Daraufhin sendet er eine direkte Verifikations-Antwort an den Web-Dienst zurück. Die Einschränkung, dass immer nur eine Verifikations-Antwort auf eine Versicherung folgen kann, stellt einen weiterer Sicherheitsaspekt gegen Replay-Attacken dar (dies wird durch einen Nonce-Wert sichergestellt).

Analyse des Vertrauensverhältnisses

Angesichts der relativen Komplexität dieses Protokolls ist die Ortung von Vertrauensfaktoren eher schwierig auf dem ersten Blick. Nachfolgend sollen einige Fragen gestellt und beantwortet werden, die Aufschlüsse über das konkrete Vertrauensverhältnis geben sollen.

Ist es möglich, dass ein Angreifer einen eigenen OpenID-Server benutzt, um Zugang zu einem fremden Account beim Drittanbieter zu erlangen?

Das Szenario sehe so aus, dass der Angreifer versucht, sich mit einem fremden („claimed“) Identifikator beim Web-Dienst anzumelden. Dazu könnte er ja seinen eigenen OpenID-Server benutzt, welcher dem Web-Dienst bei einer Authentifizierungsanfrage mit einer positiven Versicherung antwortet. Diesem Angriff liegt ein logischer Fehler zu Grunde. Der („claimed“) Identifikator bezeichnet in seiner doppelten Funktion auch eine URL (oder alternativ eine XRI), die auf den richtigen Discovery-Server verweist. Dieser wiederum sollte auf den richtigen OpenID-Provider verweisen. Somit sind „http://zeitgeist09.openid.net“ und „http://zeitgeist09.myid.org“ zwei komplett verschiedene Identifikatoren. Natürlich werden hierfür neue Angriffsvektoren geschaffen. Die Sicherheit hängt nun davon ab, wie sicher der Discovery-Server gegen Manipulationen ist, und zweitens, ob DNS-Spoofing verhindert werden kann.

Wer weiß welche Informationen in der Authentifikationsphase?

Da sich der Nutzer faktisch beim OpenID-Provider anmeldet, weiß der Provider, dass der Nutzer zum Identifikator gehört und dass der Nutzer autorisiert ist, seine Daten dem Web-Dienst zur Verfügung zu stellen.

Fall 1: Nach Abschluss der optionalen Assoziationsphase sollten OpenID-Provider und Web-Dienst einen MAC-Key besitzen. Damit ist sichergestellt, dass die Daten danach authentisch bleiben. Zusätzlich generiert der OpenID-Provider einen Nonce-Wert für seine Antworten, damit sich der Web-Dienst vor Replay-Attacken schützen kann.

Fall 2: Ohne die Assoziationsphase und die Fähigkeit Sitzungen zu speichern, besitzt der Web-Dienst keine Sitzungsinformationen. In diesem Fall besitzt der OpenID-Provider einen eigenen privaten Assoziations-Handle (zur Identifizierung der Verbindung) und einen MAC-Key zum Signieren. Die Authentizität der Daten wird allein durch eine Verifikationsmeldung über einen direkten Kommunikationskanal, also ohne Umwege über den Nutzerbrowser, sichergestellt:

1. Der Nutzer geht auf die OpenID-Login-Seite des respektiven Services.
2. Dieser leitet den Nutzer weiter zum OpenID-Provider. Der Provider fragt nach dem Passwort und der Nutzer gibt sein Passwort ein.
3. Der OpenID-Provider schickt eine positive Versicherung für den Web-Dienst über den Nutzer.
4. Der Web-Dienst möchte die Versicherung auf Echtheit prüfen und schickt über einen direkten Kanal die gleichen (signierten) Daten an den Web-Dienst zurück.
5. Der Web-Dienst sucht die Sitzung mittels des Assoziations-Handle aus seinen Verbindungen heraus, verifiziert dann die Unterschrift und den Nonce-Wert und antwortet über den direkten Kanal mit einer positiven bzw. negativen Antwort.

Angriffe

Die hier aufgezählten Angriffe beziehen sich stets auf das OpenID-Protokoll als Authentifizierungsverfahren.

Lauschangriffe

Grundsätzlich können Lauschangriffe durch die Verwendung eines verschlüsselten Kanals (zwischen Drittanbieter und Nutzer, Nutzer und OpenID-Provider) bis zu einem bestimmten Grad verhindert werden (TLS). Da zu Anfang der Kommunikation die Daten theoretisch auch mitgehört werden können, verhindert die Verwendung des Nonce-Wertes zumindest die Wiederverwendung von Versicherungen.

„Man in the Middle“

Dieser Angriff ist nach wie vor möglich, da z. B. DNS einen Angriffsvektor bietet. Eine Lösung dafür wäre der Einsatz von DNSsec.

Malware / Spyware

Der Web-Browser stellt weiterhin eine Gefahr dar für die vertrauensvolle Kommunikation. Die OpenID-Spezifikation empfiehlt beispielsweise auf die Verwendung von JavaScript zu verzichten, um XSS-Angriffe (Cross-Site-Scripting) zu verhindern.

Phishing

Folgendes Szenario ist denkbar, um an das Passwort des Nutzers heranzukommen:

1. Der Nutzer nimmt einen Gauner-Web-Dienst in Anspruch, der eine OpenID-Login-Seite anzeigt.
2. Nun gibt der Nutzer seinen Identifikator ein.
3. Der Gauner-Web-Dienst leitet den Nutzer zu einer Seite weiter, die aussieht wie sein OpenID-Provider. Es handelt sich jedoch um einen gefälschten Provider, der dem Gauner gehört.
4. Der gefälschte Provider fragt den Nutzer nach dem Passwort.
5. Der getäuschte Nutzer gibt nun sein Passwort ein.
6. Nun hat der gefälschte Provider das Passwort.

Für dieses Szenario werden zur Zeit mehrere Lösungen in den Web-Foren diskutiert.

Zusammenfassung

OpenID v.2.0 ist auf den ersten Blick ein Authentifizierungsprotokoll mit einer viel versprechenden Zweckausrichtung: nur ein Benutzerkonto für die Verwendung mehrerer Dienste. Doch die Analyse dieses Protokolls zeigt an erster Stelle, dass die Abläufe relativ komplex sind und die Sicherheit damit potentiell angreifbarer macht. Ein Beispiel dafür ist das bisher ungelöste Problem des oben erwähnten Phishing-Angriffs.