OpenID-Sicherheit. Tobias Dussa. 3. DFN-Forum KT, 27. Mai KIT-CERT. Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825

Größe: px

Ab Seite anzeigen:

Download "OpenID-Sicherheit. Tobias Dussa. 3. DFN-Forum KT, 27. Mai KIT-CERT. Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825"

Rudolf Holst
vor 5 Jahren
Abrufe

1 Tobias Dussa KIT-CERT 3. DFN-Forum KT, 27. Mai 2010 KIT die Kooperation von GmbH und

2 Übersicht 1 Einleitung 2 OpenID-Übersicht 3 Sicherheitsprobleme 4 Folgerungen Page2of16

3 Ziele des Vortrags Grundsätzliches Verständnis von OpenID. Sicherheitsrisiken von OpenID aus Nutzersicht und aus Betreibersicht. Page3of16

4 Motivation SCC ist Partner von»opencirrus«. Internationales Projekt zum Thema Cloud Computing. Wesentliche Problematik: Nutzer aus verschiedenen Ländern und Einrichtungen. Problem: Wie Authentifizierung effektiv lösen? Vorschlag einiger Partner: OpenID. Gute Idee? Page4of16

5 Wozu OpenID? Umfeld: Web 2.0. Traditionell: Pro Webseite und Nutzer ein Login. Ansatz von OpenID: Einheitliche Technik zur Identifizierung gegenüber einer Webseite. Authentifizierung erfolgt nicht gegenüber der Webseite, sondern gegenüber dritter Instanz (OpenID-Provider). Aus Nutzersicht: Zentrale Authentifizierung. Nur noch ein Login nötig. Aus Betreibersicht: Dezentrale Authentifizierung. Authentifizierung wird dritter Instanz übertragen. Page5of16

6 Beispiel OpenID-URL: OpenID-Provider: AOL. Anmeldung an einer beliebigen OpenID-unterstützenden Webseite mit obiger URL. Authentifizierung dann gegenüber AOL (mittlerweile Bebo). AOL bestätigt dann der Webseite die Identität. Page6of16

7 Ablauf einer Anmeldung 1 Nutzer gibt auf einer Webseite (Relying party, RP) seine OpenID-URL ein. 2 RP lädt diese URL herunter. Darin enthalten: Verweis auf den Identitätsprovider (IdP). 3 Optional: RP kontaktiert IdP und handelt mit Diffie-Hellman einen gemeinsamen Schlüssel aus. 4 RP schickt einen HTTP-Redirect auf den IdP an den Nutzer. 5 Nutzer authentifiziert sich gegenüber dem IdP. 6 IdP schickt einen HTTP-Redirect auf die RP an den Nutzer. Darin enthalten: Aussagen über die Authentifizierung. 7 RP prüft die im HTTP-Aufruf enthaltenen Aussagen mit DH-Schlüssel, falls vorhanden; durch Nachfrage andernfalls. Page7of16

8 Und nochmal als Bild Nutzer 4, 5, 6 Server 1, 4, 6 2 (3, 7) Webseite ID- Provider Page8of16

9 Die Klassiker Keine Verschlüsselung gefordert: Mitlesen möglich. Replay-Angriffe durch gewürfelte Einmaltransaktionsnummern verhindert. Folge: Angreifer gewinnt, wenn er schneller ist als der Nutzer. Beinahe jeder Schritt gegenüber Man-in-the-Middle-Angriffen verwundbar: Einladung zum Phishing. Abhilfe gemäß Spezifikation: SSL verwenden. Page9of16

10 Nicht ganz so Offensichtliches Datenschutz: Eine einzige ID; leicht korrelierbar. Pro Nutzer ein zentraler IdP; hervorragend geeignet zum Profilen. Cross-Site Scripting: Je nach Policy und Einstellungen des IdP nach Anmeldung an einer Webseite möglich. Falls möglich: Automatisiertes Anmelden auf beliebigen weiteren Webseiten ohne Nutzerwissen möglich. Page 10 of 16

11 Für Betreiber Unangenehmes Nutzer gibt eine beliebige URL als ID ein. Webseite muß diese URL gemäß Verfahren herunterladen. Probleme offensichtlich: Tar pit, große Dateien: DoS. Lokale Systeme: Mögliches Eindringen in interne Netze. Portscans: Scans auf andere Rechner von Rechnern des Betreibers aus. Page 11 of 16

12 Und ganz grundsätzlich: Identität eines Nutzers wird bestätigt von einer dritten Instanz, die nicht vorher bekannt ist, deren Policy und Sicherheitsstandards unklar sind und auf die der Nutzer verweist. Spot a problem, anyone? Page 12 of 16

bekannt ist, deren Policy und Sicherheitsstandards unklar

13 Und ganz grundsätzlich: Identität eines Nutzers wird bestätigt von einer dritten Instanz, die nicht vorher bekannt ist, deren Policy und Sicherheitsstandards unklar sind und auf die der Nutzer verweist. Spot a problem, anyone? Page 12 of 16

14 Beispielszenario 1 Abzusichernder Webdienst: Studierendenportal. Funktionalitäten: Erstellung von Notenauszügen, An-/Abmelden von Klausuren, Zurückmelden/Exmatrikulieren. Beliebige IdP zugelassen. Kritisch, weil sehr sensible Daten betroffen sind. Page 13 of 16

15 Beispielszenario 1 Abzusichernder Webdienst: Studierendenportal. Funktionalitäten: Erstellung von Notenauszügen, An-/Abmelden von Klausuren, Zurückmelden/Exmatrikulieren. Beliebige IdP zugelassen. Kritisch, weil sehr sensible Daten betroffen sind. Page 13 of 16

16 Beispielszenario 2 Abzusichernder Webdienst: Bibliothekszugriff. Funktionalitäten: Literaturrercherche, Bestellen/Verlängern von Ausleihen, Zugriff auf Onlinedatenbanken von Zeitschriften. Zugelassene IdPs: IdP der eigenen Einrichtung sowie IdPs kooperierender Einrichtungen. Kommunikation mit SSL abgesichert. Aus Sicherheitssicht akzeptabel. Page 14 of 16

17 Beispielszenario 2 Abzusichernder Webdienst: Bibliothekszugriff. Funktionalitäten: Literaturrercherche, Bestellen/Verlängern von Ausleihen, Zugriff auf Onlinedatenbanken von Zeitschriften. Zugelassene IdPs: IdP der eigenen Einrichtung sowie IdPs kooperierender Einrichtungen. Kommunikation mit SSL abgesichert. Aus Sicherheitssicht akzeptabel. Page 14 of 16

18 Zusammenfassung OpenID bietet einige interessante Vorteile. Für Anwendungen mit niedrigen Sicherheitsanforderungen durchaus geeignet (Blogs etc.). Bei»ernsthafteren«Anwendungen überwiegen möglicherweise die Nachteile. Nicht ohne weiteres akzeptabel für Anwendungen, die wirklich sicher sein müssen. Page 15 of 16

19 C est ça Fragen? Page 16 of 16

Ähnliche Dokumente

OpeneGK. Benutzerfreundliche und sichere Authentisierung für Mehrwertdienste im Gesundheitswesen. Mannheim,

OpeneGK. Benutzerfreundliche und sichere Authentisierung für Mehrwertdienste im Gesundheitswesen. Mannheim, OpeneGK Benutzerfreundliche und sichere Authentisierung für Mehrwertdienste im Gesundheitswesen Mannheim, 08.09.2010 Daniel Eske, Detlef Hühnlein, Johannes Schmölz, Sachar Paulus, Tobias Wich, Thomas Wieland