Authentifizierungsprotokolle

Im Wesentlichen wird bei den Authentifizierungsprotokollen zwischen den Challenge-Response-Verfahren und der Authentifizierung über vertrauenswürdige Dritte unterschieden. Der Unterschied besteht darin, dass beim einfachen Challenge-Response-Verfahren nur Client und Server beteiligt sind, während bei der Authentifizierung über vertrauenswürdige Dritte eine weitere Instanz, die Authentifizierungs-Autorität, beteiligt ist [Tso10, S. 127 ff].

Challenge-Response-Verfahren beschreiben einen Ansatz, wobei eine Partei bei der anderen eine Antwort anfordert, die nur richtig sein kann, wenn die andere Partei den zugehörigen, geheimen Schlüssel kennt. Bei den Challenge-Response-Verfahren wird zwischen symmetrischen und asymmetrischen unterschieden. Beim symmetrischen Challenge-Response-Verfahren besitzen beide Kommunikationspartner einen gemeinsamen geheimen Schlüssel, während bei dem asymmetrischen Challenge-Response-Verfahren die Kommunikationspartner jeweils ein eigenes Schlüsselpaar besitzen. Bei diesem Schlüsselpaar wird der eine Schlüssel zum Verschlüsseln und der andere zum Entschlüsseln genutzt.

Zertifikate

Die Authentifizierung per Zertifikat ist ein alternativer Authentifizierungsmechanismus. Grundsätzlich wird hier zwischen Client- und Serverzertifikat unterschieden. Die Verwendung von Zertifikaten ist wesentlich sicherer als die Verwendung von Benutzername/Kennwort-Kombinationen, da ein Zertifikat einen eindeutigen Benutzernamen mit einer für diesen Benutzer spezifischen asymmetrischen Verschlüsselung verbindet. Ein entscheidender Unterschied besteht darin, dass der Benutzer die verwendeten Schlüssel nicht auswendig kennen und selbst manuell angeben muss. Stattdessen übernimmt dies der Web-Browser, welcher Zertifikate importieren und automatisch verwenden kann. Daher sind Zertifikatsschlüssel in der Regel sehr viel länger als es Kennwörter aus praktischen Gründen sein könnten.

Ein weiterer großer Vorteil ist, dass der private Schlüssel bei der Authentifizierung niemals selbst übertragen wird, sondern lediglich Daten, die mit ihm verschlüsselt wurden. Selbst das Abfangen von Abfragedaten würde einem Angreifer das Kennwort nicht offenbaren.

Ein digitales Zertifikat dient seinem Inhaber als Identitätsnachweis und wird von einer Zertifizierungsstelle ausgestellt. Diese prüft die Identität des Antragstellers z. B. anhand von Ausweispapieren. Um die Echtheit von digitalen Zertifikaten nachweisen zu können, werden diese von den Zertifizierungsstellen digital signiert, so dass zur Durchführung der Überprüfung der öffentliche Schlüssel und somit das Zertifikat der Zertifizierungsstelle benötigt wird.

Die Authentifizierung eines Servers gegenüber einem Client mittels Zertifikaten ist eine Vorstufe der SSL/TLS-Verschlüsselung. Daher findet man die sogenannten Server-Zertifikate sehr häufig vor. Anders herum kann sich aber auch ein Client gegenüber einem Server mit einen Client-Zertifikat authentifizieren. Diese Form der Authentifizierung ist eher selten. Ein öffentlich verwendetes Zertifikat muss ebenfalls von einer Zertifizierungsstelle signiert sein, was mit Kosten verbunden ist. Wenn ein solches Zertifikat von einem Client verwendet wird, muss er es auf seinem Rechner installieren. Dadurch ist der Missbrauch durch einen Mitbenutzer dieses Rechners möglich. Wenn der Zertifikatsinhaber sein System wechselt, muss er das Zertifikat transportieren. Dies sollte nicht über ein Netzwerk erfolgen, da sich ansonsten Dritte Besitz verschaffen könnten. Installation und Weitergabe von Client-Zertifikaten ist somit aufwändig.

Basic- und Digest-Authentifizierung

Die einfachste Art der Authentifizierung ist die Basic- und Digest-Authentifizierung nach RFC 2617 [Fra99] über den Benutzernamen und ein Kennwort. Diese Methode basiert auf einer öffentlichen Information, dem Benutzernamen, und einer privaten Information, dem Kennwort, dem gemeinsamen Geheimnis. Basic Authentifizierung sollte nur in Kombination mit einer SSL/TLS-Verbindung zum Einsatz kommen, um Man-In-The-Middle-Attacken zu verhindern. Diese Kombination ist eine beliebte Variante im E-Commerce [Til11, S. 131].

HTTP(S) bietet mit der Basic- und Digest-Authentifizierung einen einfachen Challenge-Response-Authentifizierungsmechanismus an, der es dem Server erlaubt, beim Client Authentifizierungsinformationen abzufragen und dem Client erlaubt, die Authentifizierungsinformationen bereitzustellen. Basic- und Digest-Authentifizierung ist in RFC 2617 [Fra99] standardisiert.

Sowohl bei Basic- als auch bei Digest-Authentifizierung teilen Client und Server ein Geheimnis – ein Kennwort. Die Basic-Authentifizierung bietet einen grundlegenden Zugriffsschutz, jedoch wird das Kennwort im Klartext in der Nachricht mitversendet. Eine Alternative ist die Digest-Authentifizierung. Bei der Digest-Authentifizierung wird im Gegensatz zur Basic-Authentifizierung das Kennwort nicht im Klartext übermittelt, sondern als Hashcode – in der Regel MD5.

Bei der Basic- und Digest-Authentifizierung wird ein Token genutzt, der das Authentifizierungsschema angibt, gefolgt von Komma-getrennten Schlüssel-Werte-Paaren, die die notwendigen Parameter transportieren. Die 401 (Unauthorized) Response-Nachricht wird vom Server genutzt, um über den WWW-Authenticate-Header die Authentifizierungsinformationen beim Client abzufragen [Fie99, Kapitel 10.4.2].

Das Basic-Authentifizierungs-Schema basiert auf dem Model, dass der Client sich gegen jede Realm mit einem Benutzernamen und einem Kennwort authentifizieren muss [Fie99, Kapitel 11]. Die Realm-Directive wird für alle Authentifizierungsschemas benötigt, die auf einem Request beruhen. Der Realm-Wert in Verbindung mit der Root-URL definiert den Sicherheitsbereich. Geschützte Ressourcen können in Sicherheitsbereiche eingeteilt werden. Ein Client kann sich beim Server authentifizieren, indem er einen Authorization-Header im Request mitschickt. Dies muss nicht zwingend auf ein 401 (Unauthorized) erfolgen, sondern er kann bei bekanntem Authentifizierungsverfahren auch beim initialen Request den richtigen Authorize-Header mitschicken [Fie99, Kapitel 14.8].

Der Nachrichtenfluss für Basic-Authentifizierung soll hier beispielhaft dargestellt werden. Der erste Request von Komponente A an Ressource RI auf Komponente B sieht wie folgt aus:

072513_1137_authentifiz1

Im Request ist kein Authentication-Header mit zusätzlichen Authentifizierungsinformationen angegeben. Da es sich bei Ressource RI um eine geschützte Ressource handelt, erfolgt folgende Challenge von Komponente B:

072513_1137_authentifiz2

Daraufhin wiederholt Komponente A den Request mit den erforderlichen Authentifizierungsinformationen, die im Authentication-Header angegeben werden. Wenn dem Client im Vorfeld das Authentifizierungsschema und der zugehörige Realm bekannt sind, kann er auch schon im initialen Request die Authentifizierungsinformationen senden. Der Realm repräsentiert den Gültigkeitsbereich der konkreten Authentifizierungsinformationen. Da in den beschriebenen Szenarien für jede Ressource separat authentifiziert wird, gibt es für jede Ressource einen eigenen Realm. Realm ist kein optionaler Parameter.

Zweiter Request von Komponente A an Ressource RI auf Komponente B mit Authentifizierung:

072513_1137_authentifiz3

Im Falle einer erfolgreichen Authentifizierung, Autorisierung und Anlage der Ressource RN antwortet Komponente B wie folgt:

072513_1137_authentifiz4

Das HTTP-Protokoll macht keine Einschränkungen auf den Challenge-Response-Mechanismus. Vielmehr können zahlreiche andere Mechanismen zusätzlich angewandt werden. Das kann z. B. Verschlüsselung auf der Transportebene mit SSL/TLS sein, Message Encapsulation oder zusätzliche Header-Felder.

Der größte Nachteil bei der Basic-Authentifizierung ist, dass das Kennwort im Klartext übertragen wird. Andererseits wird weder bei Basic- noch bei Digest-Authentifizierung der Message-Body verschlüsselt. Digest ist ausschließlich zum Ersetzen der Basic-Authentifizierung gedacht, damit das Kennwort nicht mehr lesbar übertragen wird. Ansonsten gelten für Digest dieselben Probleme wie bei allen anderen kennwortbasierten Systemen [Fra99]. Eine mögliche Angriffsform ist der Wörterbuchangriff (Dictionary Attack).

Der Wörterbuchangriff ist als Angriffsmöglichkeit auf Rechner bereits seit langem bekannt. Hierbei verwendet man Wörterbücher und testet mittels eines Skripts Kennwort für Kennwort aus, bis man das passende gefunden hat. Der Angreifer kann aber auch mittels einer Brute-Force Attacke alle möglichen Zeichenkombinationen von einem Rechner automatisch ausprobieren lassen. Diese Angriffsformen gefährden besonders Systeme, die den Benutzer nicht nach einer bestimmten Anzahl von Fehlversuchen der Passworteingabe aussperren. Wenn diese Funktionalität realisiert ist, kann ein Angreifer durch vielfache Fehleingabe eines Kennwortes bewusst alle Benutzer aus dem System aussperren.

Da bei Basic-/Digest-Authentifizierung sind zwei zusammenhängende Informationen in einer Datenbasis auf beiden Seiten des Kommunikationskanals gespeichert werden müssen, muss diese Speicherung in einer besonders geschützten Form erfolgen, da ansonsten die Gefahr eines Wörterbuchangriffs besteht.

Single-Sign-On

Ein Problem bei der Authentifizierung über ein Kennwort in einem Netzwerk ist, dass jeder mit jedem seine Kennwörter austauschen muss. Um dem entgegenzuwirken, wird eine zentrale Instanz eingeführt, die mit jedem Host ein Geheimnis teilt. Diese Instanz wird auch vertrauenswürdiger Dritter (Trusted Third Parties; Secutity Token Issuer) genannt. Sie fungiert als zentrale Authentifizierungsautorität für mehrere Services gleichzeitig. Hierbei wird vermieden, dass sich ein Client selbst beim Zielservice authentifizieren muss.

Ein mögliches Modell ist das Schlüsselverteilungszentrum, mit dem jeder einzelne Client einen gemeinsamen Schlüssel teilt. Möchte ein Client mit einem Service kommunizieren, teilt er dem Schlüsselverteilungszentrum seinen geheimen Schlüssel und den Namen des Services mit. Das Schlüsselverteilungszentrum authentifiziert den Client und leitet dessen Identität und den Sitzungsschlüssel an den Service weiter. Dieses Verfahren ist gegen Replay-Attacken gefährdet. Dabei initiiert ein Angreifer einen Service-Aufruf und lauscht auf die Nachricht, die das Schlüsselverteilungszentrum dem Service sendet und extrahiert den Sitzungsschlüssel, um ihn dann für eigene Anfragen zu nutzen [Tan03, S. 854 ff].

Verbessert wird der beschriebene Mechanismus durch ein Mehrwege-Challenge-Response-Verfahren. Ein bekanntes Beispiel ist das Needham-Schroeder-Authentifizierungsprotokoll, wobei Zufallszahlen mit ausgetauscht werden, um Replay-Attacken zu vermeiden. Das Needham-Schroeder-Protokoll vereint Schlüsselaustausch und Authentifizierung und ermöglicht einen sicheren Datenaustausch in einem dezentralen Netzwerk.

Kerberos ist ein offener Standard, der in RFC 4120 [Neu05] definiert ist und basiert auf dem Needham-Schroeder Protokoll. Kerberos kann als System gesehen werden, welches Nutzer dabei unterstützt, einen sicheren Kanal mit jedem Server innerhalb eines verteilten Systems aufzubauen. Kerberos arbeitet mit verschlüsselten “Tickets”: Nach der Authentifizierung bei einem Kerberos-Server erhält der Client einen “Fahrschein”, der als eine Art Ausweis gegenüber den Diensten im Netzwerk fungiert, die der Client benutzen darf [Neu05].

Ein Single-Sign-On- (SSO-) Mechanismus erlaubt es einem Benutzer, sich mit einer einzigen Authentifizierung an einem gesamten Anwendungsverbund anzumelden. Der Nutzer wird nur einmal – in der Regel bei der Anmeldung – zur Eingabe eines Kennwortes aufgefordert. Solange der Nutzer das System nicht wechselt, ist es nicht notwendig, sich bei einem anderen Server selber zu authentifizieren. Der Nutzer hat nur noch ein Kennwort für verschiedene Dienste und wird auch nur einmal zur Eingabe aufgefordert. Verzeichnisse werden abgeglichen. Dieser Mechanismus birgt jedoch auch ein Sicherheitsrisiko, da ein Angreifer das Ausspähen einer einzigen Benutzeridentität ausreicht, um Zugriff auf den gesamten Verbund zu bekommen. Dies wird aber in den meisten Fällen in Kauf genommen, denn der Vorteil von SSO überwiegt. Nach einer einzigen Anmeldung werden alle Systeme im Anwendungsverbund automatisch und zeitsparend mit den notwendigen Authentifizierungsparametern – den Credentials – versorgt.

Single-Sign-On-Systeme unterscheiden sich in der Art, wie dieses Vertrauensverhältnis aufgebaut wird und wie Authentifizierungsinformationen formatiert und übermittelt werden. Das Ergebnis ist aber immer, dass der Benutzer Anwendungen und Dienste aus anderen Domänen aufrufen kann. Solange das Vertrauensverhältnis besteht, wird der Benutzer als bereits authentifiziert erkannt.

Single-Sign-On in einer Web-Umgebung funktioniert im Grunde ähnlich. Eine zentrale Instanz, der Identity-Provider, fügt nach erfolgreicher Authentifizierung einen Token in den HTTP-Header des Browsers ein. Der Browser sendet diesen Token bei jedem Request mit. Wenn eine Anwendung einen solchen Request erhält, muss eine Komponente den Request zuerst abfangen und die Gültigkeit beziehungsweise Existenz des Tokens überprüfen. Ist der Token gültig, wird der Request zugelassen. Ist der Token hingegen ungültig, wird der Aufrufer zur zentralen Anmeldeinstanz weitergeleitet. Oftmals wird diese abfangende Komponente “Policy Enforcement Point” oder kurz PEP genannt. Für die erstmalige Authentifizierung am Sign-On-, bzw. Ticket-Server sollte der Übertragungskanal mit SSL/TLS gesichert sein. Die Anmeldeinformationen werden damit nicht mehr unverschlüsselt über das Netzwerk übertragen, was das Risiko potenzieller Angriffe drastisch reduziert.

Die Implementierung eines Single-Sign-On- (SSO-) Systems ist relativ aufwändig. Am Markt sind jedoch einige existierende Implementierungen – zum Teil proprietär, zum Teil frei verfügbar – erhältlich. Gebräuchliche Implementierungen für Single-Sign-On- (SSO-) Systeme sind OpenID, Kerberos, OpenAM, Microsoft Passport, Central Authentication Service (CAS) und Shibboleth.

Die Security Assertion Markup Language (SAML) ist ein XML-Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten. Es handelt sich in erster Linie um ein Übertragungsformat. Der Austausch kann auch Domänenübergreifend erfolgen. Der typische Anwendungsfall ist, dass sich ein Nutzer bei einem Single-Sign-On System authentifiziert und anschließend zur Nutzung bestimmter Dienste berechtigt ist. Konkrete Implementierungen, die SAML als Übertragungsformat nutzen, basieren auf einer Vertrauensstellung zwischen Identity Provider und Server, die i. d. R. über den Austausch von Zertifikaten hergestellt wird. Dabei handelt es sich um eine Abhängigkeit, die für das hier zu betrachtende System nicht geeignet ist. Diese Abhängigkeit besteht bei der Nutzung von OpenID nicht.

OpenID

OpenID ist ein Web-Single-Sign-On System, welches aus einem Open-Source-Projekt entstanden und mittlerweile als offener Standard auf der OpenID-Foundation Webseite spezifiziert ist [Ope07]. OpenID ist ein auf öffentlich zugängliche Webseiten zugeschnittener Dienst [Küb11, S. 78]. Über OpenID kann man sich mit einer Identität online über verschiedene Webanwendungen authentifizieren. Es ist also nicht mehr erforderlich, für jede Webanwendung ein eigenes Benutzerkonto zu pflegen, sondern man authentifiziert sich mit einem OpenID Benutzerkonto gegen eine Vielzahl von Anwendungen.

Wie bereits in Kapitel 2.3 für die Ressourcen beschrieben, gilt auch bei der Verwendung eines URI als Benutzerkennung, dass diese weltweit eindeutig ist. Dadurch entfällt die Abhängigkeit von einer zentralen Instanz. Nachteil von OpenID ist, dass ein Angreifer Zugang zu allen verbundenen Anwendungen erhält, wenn er den Dienst selbst erfolgreich angreifen kann [Küb11, S. 78]. Der Nachrichtenaustausch erfolgt zwischen Endpunkten. Diese Endpunkte repräsentieren die Relying Party (RP) und den Identity Provider (IP). Zum Nachrichtenaustausch benutzt OpenID HTTP.

Arbeitsweise des OpenID-Protokolls

072513_1137_authentifiz5

Abbildung 1: Kommunikationspartner im OpenID-Protokoll

In Abbildung 1 werden die Beteiligten Parteien einer OpenID-Authentifizierung dargestellt. Dies sind der Browser des Nutzers (Client), der OpenID-Provider (IP) und die Relying-Party (RP). Die RP ist ein Service Provider, der eine beliebige Ressource zur Verfügung stellt. Im eigentlichen OpenID-Protokoll ist die Ressource nicht auf eine REST-konforme Ressource beschränkt, sondern kann auch ein Service o. Ä. sein. In Abbildung 52 ist der Nachrichtenfluss in einem Sequenzdiagramm dargestellt.

072513_1137_authentifiz6

Abbildung 2: Sequenzdiagramm OpenID-Protokoll

Im Folgenden werden die Nachrichten angelehnt an [Ope07, Kapitel 3] beschrieben:

  1. Der Client möchte auf eine geschützte Ressource der RP zugreifen (Im Protokoll nicht spezifiziert).
  2. Initiation: Die RP leitet auf eine Login-Seite um und fordert den Client auf, seinen OpenID-URI einzutragen. Diese OpenID ist der sog. User-Supplied Identifier.
  3. Der Client übermittelt der RP seinen OpenID-URI bzw. User-Supplied Identifier.
  4. Discovery: Der User-Supplied Identifier muss nicht dem Claimed Identifier entsprechen. Die RP ermittelt mittels Discovery den Claimed Identifier und den OpenID-Endpunkt des IP. Der Discovery-Prozess nutzt hierzu das Yadis-Protokoll oder HTML-Dokumente.
  5. Response der Discovery-Seite mit dem Claimed Identifier.
  6. Key Exchange (optional): RP und IP tauschen ein Geheimnis mittels Diffie-Hellman Key Exchange aus [Res99].
  7. Response aus Key Exchange
  8. Redirect: Als Response auf die Initiation (3) sendet die RP eine OpenID-Authentifizierungs-Request in Form einer HTML-Seite mit einer Redirect-Anweisung zum IP an den Client.
  9. Authentication: Der Redirect auf den IP erfolgt für den Nutzer transparent. Der Browser erzeugt aus Nachricht (8) eine Authentication-Request an den IP.
  10. Der IP empfängt die Authentication-Request des Clients und antwortet mit einer HTML-Seite zur Eingabe den Kennwortes. (Im Protokoll nicht spezifiziert)
  11. Der Client gibt sein Kennwort ein und übermittelt es dem IP. (Im Protokoll nicht spezifiziert)
  12. Redirect: Der IP verifiziert die Identität und erzeugt einen Response in Form einer HTML-Seite mit einer Redirect-Anweisung zur RP an den Client. Die HTML-Seite enthält die Information, ob die Authentifizierung erfolgreich war oder nicht.
  13. Credentials: Der Client übermittelt – für den Nutzer transparent – der RP die Authentifizierungs-Request.
  14. Bei erfolgreicher Authentifizierung und Autorisierung antwortet die RP mit der ursprünglich angeforderten Ressource [Til11, 137 f].

RP und IP kommunizieren indirekt miteinander, d. h. Nachrichten werden über den Client geleitet.

 

[Fie99] R. Fielding et al. (1999, June) RFC 2616 – Hypertext Transfer Protocol — HTTP/1.1. [Online]. http://tools.ietf.org/html/rfc2616

[Fra99] J. Franks et al. (1999, June) RFC 2617 – HTTP Authentication: Basic and Digest Access Authentication. [Online]. http://www.ietf.org/rfc/rfc2617.txt

[Küb11] Sebastian Kübeck, Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor Angreifern schützen. Heidelberg, München, Landsberg, Frechen, Hamburg: mitp, 2011.

[Neu05] C. Neuman, T. Yu, S. Hartman, and K. Raeburn. (2005, July) RFC 4120 – The Kerberos Network Authentication Service (V5). [Online]. http://www.rfc-editor.org/rfc/rfc4120.txt

[Ope07] (2007, Dec.) OpenID Authentication 2.0 – Final. [Online]. http://openid.net/specs/openid-authentication-2_0.html

[Res99] E. Rescorla. (1999, June) RFC 2631 – Diffie-Hellman Key Agreement Method. [Online]. http://www.ietf.org/rfc/rfc2631.txt

[Tan03] Andrew S. Tanenbaum, Computernetzwerke. München: Pearson Studium, 2003.

[Til11] Stefan Tilkov, REST und HTTP – Einsatz der Architektur des Web für Integrationsszenarien. Heidelberg: dpunkt.verlag, 2011.

[Tso10] Alexander Tsolkas and Klaus Schmidt, Rollen und Berechtigungskonzepte. Wiesbaden: Vieweg+Teubner Verlag, 2010, TWZ 4536.

Leave a Reply