Sichere Authentifizierung im Web 2.0

Aus Winfwiki

Name des Autors:	Timo Altenfeld
Titel der Arbeit:	Sichere Authentifizierung im Web 2.0
Hochschule und Studienort:	FOM Essen
Studiengang:	Bachelor of Science / Wirtschaftsinformatik, 3. Fachsemester
Name des Betreuers:	Dipl-Inf. (FH) Christian Schäfer
Erstellungszeitraum:	WS 2009
Datum der Abgabe:	07.02.2010

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einleitung 4 Grundlagen 4.1 Authentifizierung 4.2 Autorisierung 4.3 Web/Web 2.0 4.4 Single Sign-On 5 Verbindungssicherheit/Transportsicherheit 6 Authentifizierungsmethoden 6.1 Username/Passwort 6.1.1 Sicherheit von Passwörtern 6.1.2 Passwort Speicherung 6.1.3 Zusammenfassung Passwort Sicherheit 6.2 Zertifikat 6.2.1 Funktionsweise 6.2.2 Zusammenfassung Zertifikate 6.3 Tokens 6.3.1 Challenge/Respones-Tokens 6.3.2 Zeitbasierte Tokens 6.3.3 Yubikey 6.3.4 Zusammenfassung 7 OpenID 7.1 Entwicklungsgeschichte 7.2 Funktionsweise 7.3 Verbreitung 7.4 Zusammenfassung 8 Fazit 9 Fußnoten 10 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
AES	Advanced Encryption Standard
CA	Certificate Authority
HTTP	Hypertext Transfer Protocol
IETF	Internet Engineering Task Force
OTP	One Time Password
PKI	Public-Key-Infrastruktur
SSL	Secure Socket Layer-Protokoll
SSO	Single Sign-On
USB	Universal Serial Bus
XML	Extensible Markup Language

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	SSO Verbindungsaufbau
2	Häufigkeit Passwort Verwendung
3	Yubikey OTP Aufbau
4	OpenID Logo
5	OpenID Verbindungsaufbau

3 Einleitung

Das Web ist in der Vergangenheit zu einem Populären wenn nicht sogar zu dem Populärsten Kommunikation und Wissensaustausch Plattform in unsere Zeit geworden. Diese Arbeit möchte sich mit dem Blickpunkt der Authentifizierung mit dem Web 2.0 auseinandersetzen. Es soll aufgezeigt werden welche Möglichkeiten es gibt sich im Web zu Authentifizieren und welche heute schon im Web 2.0 genutzt werden. Diese Authentifizierungs Mechanismen sollen auch aus Sicherheitstechnischen Gesichtspunkten untersucht werden. Eine Sichere Authentifizierung ist der Grundstein zu Verwendung von Web Diensten. Wenn eine Authentifizierung im email Verkehr als nicht sicher gilt kann ich mir nicht sicher sein ob der jenige dem ich gerader eine Email schreibe auch wirklich der ist für den ich ihn halte oder ob nicht noch jemand anderes Einblick in diese Informationen hat. Genau so ist es auch mit anderen Web Diensten zu sehen. In der Nachfolgenden Beitrag soll also gezeigt werden ob es überhaupt möglich sich Sicher zu sein das die Person mit der ich gerader Schatte oder von der ich gerade einen Block Eintrag lese auch wirklich die ich Hoffe das es sie ist. Es stellt sich also die Zentrale Frage ob Web 2.0 Dienste überhaupt über eine Sichere Authentifizierung verfügen und ob es Möglichkeiten gibt diese Sicherer zu machen.

4 Grundlagen

4.1 Authentifizierung

Bei der Authentifizierung geht es darum zu bestätigen das man die Person oder der Gegenstand (Server) ist für den man sich ausgibt. Hierbei geht es nicht darum seine Identität in form eines Personalausweises zu bestätigen, sondern es geht darum zu identifizieren ob ich der Kommunikationspartner bin für den ich mich gerade ausgeben möchte. Bei der Authentifizierung authentifiziert sich meistens nur die eine Seite gegenüber der anderen, im Web ist dies meistens der Benutzer gegenüber dem Server.^[1] Laut Hansen und Neumann wird Authentifizierung demnach folgender Maßen definiert:"Unter der Authentifizierung (engl. authentification) versteht man die nach weißliche Identifikation eines Benutzers oder eines Kommunikationspartners(beispielsweise eines softwarebasierten Dienstes)."^[2] In den meisten Web Applikationen erfolgt eine Authentifizierung meistens über Benutzername und Passwort. Es ist in diesem Fall also so das beide Kommunikationspartner ein Geheimnis haben. Mit diesem Geheimnis was nur die beiden kennen sollten wird die Identität bestätigt. Das hier verwendetet Geheimnis ist das Passwort, der Benutzername ist manchmal auch dritten Parteien bekannt. Es gibt noch weitere Möglichkeiten sich beim Kommunikationspartner zu Authentifizieren, diese werden im Nächsten Kapitel genauer erläutert.

4.2 Autorisierung

Der Begriff der Autorisierung soll hier kurz erläutert werden da es oft Verwechslungen mit dem Begriff der Authentifizierung gibt. Bei der Autorisierung geht es darum was ein Kommunikationspartner alles für Rechte Besitzt. Dies kann z.B. sein ob er Administrative Rechte hat wie der User root unter Linux oder der Administrator unter Windows Betriebsystemen.^[3] Bei diesem Wiki-System ist es z.B. genau so, ein normaler Gast der Seite kann die Artikel zwar Lesen ist aber nicht Autorisiert sie zu verändern, während ein Student der sich erfolgreich gegenüber dem System Authentifiziert hat Artikel bearbeiten darf.

4.3 Web/Web 2.0

In diesem abschnitt soll es um die Thematik des Web 2.0 gehen. Es dient als Aufbau für die weiteren Kapitel und soll den Begriff des Web 2.0 erklären. Der Begriff Web 2.0 ist das erste mal als Name für eine Konferenzreihe vom O’Reilly Verlag und MediaLive International im Jahr 2004 aufgetaucht. Wirklich bekannt wurde der Begriff durch einen Beitrag von Tim Oreily im Jahr 2005 mit dem Namen "What ist the Web 2.0". Nach dem dot.com Crash im Jahr 2001 war die Zukunft des Web unklar und das Vertrauen stark angekratzt. Aber was unterschied die Unternehmen die den Crash überlebt haben von denen die es nicht geschafft hatten. Diese Frage wollte man auf der Konferenz nachgehen. Es war eine Art Brainstorming um sich darüber klar zu werden welches Potenzial noch im Web steckte. Für viele Leute ist der Begriff des Web 2.0 ein reines Marketing Wort, welches man sich auf die Fahne schreiben kann um als möglichst Modern zu gelten. ^[4] Die Technologie die das Web 2.0 möglich machte war unter anderem Ajax. Unter Ajax wird der Asynchrone Informationsaustausch bezeichnet der mit Hilfe von Javascript und XML erfolgt. Der Benutzer bekommt nichts davon mit da die Informationen im Hintergrund übertragen werden. Ajax gilt als die Schlüsseltechnologie im Web 2.0. Ein weiterer Grund für den Erfolg des Web geht daraus hervor das Microsoft den Browser Kampf gegen Netzcape gewonnen hatte. Da durch war es für Web Entwickler einfacher Web Applikationen zu entwickeln, da sie dies nur für einen Browser tun mussten und sich nicht auf alle Browser vorbereiten mussten. Heute gibt es zwar auch mehrere Browser nur gibt es nun einen Standard an den sich die meisten Browser halten. Das World Wide Web Konsortium kurz W3C beschäftigt sich seid 1994 mit der Entwicklung von Web Standards und den damit verbundenen Technologien. ^[5] Damit das Web 2.0 funktionieren konnte musste natürlich auch der Zugriff auf das Web schnell und zuverlässig sein. Dies wurde durch moderne DSL Anschlüsse möglich, ohne diese breite Verfügbarkeit der Breitbandanschlüsse und der Flatrates wären die die Web Technologien für die Benutzer überhaupt nicht nutzbar gewesen. Dienste wie Flickr wären mit ein Modem gar nicht denkbar gewesen der Upload der Fotos hätte den Benutzern zu lange gedauert, und sie hätten den Dienst nie in der form genutzt wie es heute der fall ist. Der Begriff des Web 2.0 wird Häufig auch in dem Kontext des "Mitmach Webs" verwendet. Hiermit sind Technologien die Wikis gemeint bei denen der Content nicht von einer Firma oder Redakteuren alleine vorgegeben wird sondern von nahezu jedem Benutzer verändert werden kann.

4.4 Single Sign-On

Hier soll eine Definition von Single Sign-On (SSO) gegeben werden damit im weitere Verlauf der Arbeit die Funktionalität Verstanden werden kann. Bei SSO geht es darum das sich der Benutzer bei einem Authentifizierungs Provider (AP) Authentifiziert und dies nur einmal im laufe seiner Sitzung. Der Zugriff auf weitere Ressourcen oft auch Dienste genannt und die Überprüfung des Benutzers erfolgt im weitere dann durch den (AP) ohne eine Erneute Eingabe z.B. durch Benutzername und Passwort. Dieser Mechanismus wird als True-SS0 bezeichnet. Hierbei wird der Benutzername und das Passwort nur einmal übermittelt nämlich zum AP. Bei einem Pseudo-SS0 Provider funktioniert der Ablauf so das man sich bei dem Pseudo-SSO authentifiziert, dieser SSO hält dann alle Authentifizierungs Mechanismen bereit um sich so mit der Erlaubnis des Benutzers bei anderen Providern zu Authentifizieren häufig durch Speichern des Benutzernamens und des Passwortes durch den Dienste Provider. ^[6]. Beim True-SSO hingegen wird über eine eigene Schnittstelle sichergestellt ob der Benutzer Authentifiziert ist oder nicht. Es muss nur Übertragen werden ob der Benutzer Authentifiziert ist. Dieser Informationsaustausch kann durch die Abb. 1 Nachvollzogen werden. Der Benutzer möchte einen Dienst beim Dienste Provider nutzen, zuerst Authentifiziert er sich aber bei seinem AP. Nach der erfolgreichen Authentifizierung (Schritt 1) möchte der Benutzer nun einen Dienst nutzen. Um ihn Nutzen zu können muss er sich aber erst Authentifizieren, dieser schritt entfällt aber nun weil der Dienste Provider einfach beim AP nachfragt ob der Benutzer sich erfolgreich Authentifiziert hat (Schritt 3). Wenn die Identität bestätigt wird kann der Benutzer einfach loslegen ohne erneut sein Passwort eingeben zu müssen. Diese Art der Übermittlung ist weit aus sicherer da keine geheimen Informationen übertragen werden sonder lediglich ob der Benutzer Authentifiziert ist oder nicht. Zwischen dem AP und dem Dienst Provider muss natürlich ein Vertrauen bestehen da der Dienste Provider dem AP vertraut das es sich wirklich um den Benutzer handelt.

5 Verbindungssicherheit/Transportsicherheit

Um eine sichere Authentifizierung zu gewährleisten dürfen die Daten nicht einfach über das normale HTTP(Hyertext Transfer Protokoll) Protokoll übertragen werden, da sie so unverschlüsselt übertragen werden was das Abhören der Verbindung z.B. durch einer Man in the Middle Attacke ermöglicht. Eine sichere Authentifizierung sollte deshalb immer über SSL(Secure Socket Layer) und in form von HTTP über HTTPS stattfinden. Das würde eine Minimale Sicherheit bieten. Grundsätzlich sollten Schützenswerte Daten immer Verschlüsselt übertragen werden.

Um Login Informationen oder auch Daten sicher über das Web zu übertragen muss eine Verschlüsselung verwendet werden dies geschieht in form von HTTPS je nach dem welche Version verwendet wird geschieht dies über TLS oder SSL. SSL ist ein offener Standart der von Netzcape vorgeschlagen wurde um Sichere www Dienste wie HTTP oder FTP nutzen zu können. ^[7]SSL gibt es aktuell in zwei Version 2.0 und 3.0 den unterschied hier im einzelnen zu erläutern würde den rahmen dieser Arbeit sprengen, Zusammenfassend lässt sich sagen das die Version 3.0 mehr Sicherheitsfunktionen besitzt. SSL ist kein offizieller Standart, aus diesem Grund hat die IETF (Internet Engineering Task Force) als Ersatz für SSL v3.0 TLS 1.0 entwickelt. Diese beiden Versionen sind sich fast identisch. Welche Version eingesetzt wird hängt von der Implementierung im Browser sowie auf dem Server ab. Die heutigen Browser unterstützen oft beide Versionen. Ein Verbindungsaufbau einer gesicherten Verbindung erfolgt in viert schritten. ^[8]

Im ersten Schritt wird eine Cipher-Suite ausgehandelt. Der Server und der Browser ermitteln hier die gemeinsamste größte SSL bzw. TLS Version.

Im zweiten Schritt generiert der Browser einen geheimen Schlüssel den er mit dem Öffentlichen Schlüssel des Servers verschlüsselt, so ist sicher das nur der Server diesen Schlüssel entschlüsseln kann. Nach diesem Schritt besitzen Server und Browser einen gemeinsamen Symmetrischen Schlüssel über den die weitere Kommunikation erfolgen kann.

Im dritter Schritt authentifiziert der Browser den Server in dem er das Zertifikat von Server analysiert und untersucht ob es von einer ihm bekannten Vertrauenswürdigen CA (Certifcate Authorotiy) unterschrieben wurde. Wenn es nicht stimmt oder der Servername in der URL nicht mit dem "Common Name" im Zertifikat überein stimmt erhält der Benutzer, häufig in form eines Pop-Up Fensters eine Meldung das der Server nicht vertrauenswürdig zu seien scheint. Er kann diese Meldung aber ignorieren in dem er sagt das er trotzdem fortfahren möchte.

Der vierte Schritt ist optional und zwar wird hier gegebenfalls das Browser Zertifikat untersucht. Ein solches liegt aber nur vor wenn der Browser ein solches Zertifikat bereitstellt. Dieses Zertifikat kann dann ebenfalls als Authentifizierungsmerkmal genutzt werden und wird in Kapitel 6.2.1 genauer beläuchtet.^[9]

6 Authentifizierungsmethoden

Es gibt viele Authentifizierungsmethoden die man Nutzen kann um sich zu authentifizieren, in diesem Abschnitt soll ein Überblick über diese gegen werden. Ebenfalls sollen die Vor- und Nachteile der Jeweiligen Methoden aufgezeigt werden. Die Authentfizierungsmethoden werden immer mit einem Blick auf das Web begutachtet um so festzulegen welche hier genutzt werden können.

6.1 Username/Passwort

Die Authentifizierung mit einem Kennwort häufig auch Passwort genannt ist die am Häufigsten verwendete Möglichkeit sich zu authentifizieren. Bei dieser Art der Authentifizierung geht es darum ein Geheimnisse zu haben was nur der Benutzer kennt, um so sicher zu stellen das es sich auch wirklich um den Benutzer handelt. Der SP auf der anderen Seite Speichert diese Passwort Verschlüsselt in einer Datenbank. Der Benutzername wird im klar Text gespeichert um eine Verknüpfung zwischen diesen beiden Merkmalen herzustellen. Der Authentifizierungsmechanismus verschlüsselt dann das eingegebene Passwort des Benutzers mit dem gleichen Algorithmus wie es in der DB vorliegt und vergleicht die werte. Bei Gleichheit ist die Authentifizierung erfolgt und der Benutzer hat Zugriff auf das System.

6.1.1 Sicherheit von Passwörtern

Bei der Sicherheit von Benutzername und Passwort kommt es Hauptsächlich auf das Passwort an, aber auch der Benutzername darf nicht Unterschätzt werden. Ein Passwort sollte schwer für dritte zu erraten sein, am besten gar nicht. Das BSI hat eine reihe von Sicherheitsmerkmalen in seinem Grundschutzkatalog zusammen getragen die ein Passwort aufweisen sollte damit es als Sicher gilt. ^[10] In dem folgenden abschnitt soll ein grobe Übersicht über mögliche Regeln gegeben werden. Ein Passwort darf nicht leicht zu erraten sein, aus diesem Grund sollte auf Passwörter wie Geburtsdatum, Autokennzeichen oder Name des Freundes der Freundin Verzichtet werden. Passwörter sollten immer eine gewisse Komplexität aufweisen. Sie sollten also nicht nur aus Buchstaben oder nur aus zahlen bestehen ebenfalls sollte auf Passwörter verzichtet werden die im Wörterbuch stehen. Der Grund hierfür ist das solche Passwörter sehr schnell einem Wörterbuch angriff zum Opfer fallen können. Bei einem solchen Angriff können sehr schnell sehr viele Passwörter durchprobiert werden. Auch auf häufiger Kombinationen wie z.B. qwertz sollte verzichtet werden da solche Passwörter in Passwort listen eingetragen werden und solche listen auch die erste Angriffsmöglichkeit für so genannte "Brute Force" Attacken sind. Bei einer solchen Attacke werden wahllos Passwörter durchprobiert.

Eine Aktuelle Studie des Imperva in der 32 Millionen Passwörter des Portals rockyou.com Verwendet wurden zeigt auf das immer noch häufig zu einfache Passwörter verwendet werden. In dieser Studie wird klar das das am Häufigsten verwendete Passwort 123456 ist. Im Oktober 2009 bekam ein Hacker zugriff auf 10000 Passwörter des Microsoft Webdienstes Hotmail.com, auch hier war mit 64 mal das am Häufigsten verwendetet Passwort 123456^[11]. Die Länge lässt sich darauf zurückführen das kürze Passwörter im Hotmail dienst nicht erlaubt sind. Diese Zahlen zeigen auf das immer noch zu häufig einfachst Passwörter verwendet werden.

6.1.2 Passwort Speicherung

Menschen müssen sich in ihrem Alltag zahlreiche Passwörter und PINs merken. Ohne solche kommt ein Mensch in der heutigen Gesellschaft nicht mehr aus. Viele Menschen fällt es schwer sich also ein viel zahl von solchen Kombinationen zu merken. Deshalb kommt es oft das einfache Passwörter verwendet werden wie im Vorigen Kapitel zu sehen. Oft ist es auch so das immer wieder das gleiche Passwort verwendet wird. Falls Private das gleiche wie im Unternehmen verwendet wird ist auch dies als Kritische an zu sehen. Um sich das merken der Passwörter zu Erleichtern gibt es so genante "Passwort-safes". Diese Tools sollten Gewisse Anforderungen haben damit sie als Sicher gelten können. Das BSI führt einige auf diese sollen hier kurz zusammengefasst werden. ^[12] Die Speicherung der Passwörter sollte Verschlüsselt werden, jeder Zugriff auf die Passwörter sollte Dokumentiert werden damit der Benutzer nachvollziehen kann ob vielleicht jemand unbefugtes Zugriff hatte. Der Zugriff selber sollte wieder auch immer nur über ein Master Passwort möglich sein welches dann allerdings natürlich auch den Passwort Sicherheitskriterien entsprechen sollte. Viele Browser wie z.B. Mozilla Firefox bieten auch die Möglichkeit Passwörter zu Speichern. Kritisch hierbei zu sehen ist das der Passwort Manager bei jeder Webseite mit Login fragt ob das Passwort gespeichert werden soll. In dieser Phase aber noch kein Master Passwort vergeben werden musste. Dieses muss erst durch selbst eingreifen des Benutzers über die Einstellungen erfolgen. Wenn der Benutzer diesen Vorgang nicht Vornimmt hat jeder, der Zugriff auf den Browser des Benutzers hat, auch Zugriff auf alle Passwörter. Was also nicht den Sicherheitskriterien entspricht. Eine Erstellung des Master Passwortes beim ersten Eintragen würde die Sicherheit hier enorm verbessern. Diese Art der Verwaltung von Authentifizierung wird als Pseudo-SSO bezeichnet. Dieses Maß an Sicherheit bieten aber noch lange nicht alle Browser der Safari Browser z.B. bietet auch die Möglichkeit Passwörter zu Speichern und zu verwalten die Festlegung eines Master Passwortes ist allerdings nicht Möglich aus diesem Grund sollte hier auf die Speicherung von Passwörtern ganz verzichtet werden. Was in den Standart Einstellungen auch der Fall ist. Der Zugriff auf einen Solchen im Browser verwendeten Passwort Safe ist auch nur eingeschränkt so kann er z.B. nicht auf einem andere Rechner verwendet werden, hierfür gibt es zwar zusätzliche Tools die, einen Abgleich der im Browser gespeicherten Daten bieten können, nur ist der Zugriff hierbei auch nicht auf jedem Endgerät oder mit jedem Browser möglich. Ein Passwort Safe sollte also die Möglichkeit eines Ständigen Zugriffs ermöglichen damit er effizient genutzt werden kann.

6.1.3 Zusammenfassung Passwort Sicherheit

Zusammenfassend lässt sich also Sagen das die Authentifizierung per Passwort nur als sicher gelten kann wenn die Passwörter den Sicherheitskriterien entsprechen. Dennoch sind Passwörter am häufigsten verwundetste Authentifzierungsmittel. Dies hängt damit zusammen das Passwörter bei der Registrierung eines neuen Benutzers schnell und unkompliziert funktionieren oder auch das jeder der einen Computer verwendet es nur so kennt das er um sich zu Authentifizieren ein Passwort verwenden muss. Die Sicherheit von Passwörtern lässt allerdings sehr Stark zu wünschen übrig was es Angreifern sehr einfach macht. Vielen Benutzer ist es beim Registrieren eines Profils bei einem Web 2.0 Dienst oft nicht klar welchen Status dieses Profil ein nehmen könnte. So ist zum Beispiel bei Sozialen Netzwerken so das man sich den Account macht um erst mal einen Überblick zu bekommen und der Account jetzt noch lange nicht geheim ist. Mit der Zeit wickelt man aber immer mehr über diesen Account ab wie zum Beispiel das Kommunizieren mit Freunden. So gewinnt der Account an Bedeutung das Passwort bleibt aber bestehen.

6.2 Zertifikat

Eine weitere Möglichkeit der Authentifizierung ist die Authentifizierung mit Zertifikaten. Sie wird aber aufgrund des Hohen administrativen Aufwandes und der entstehenden Kosten sehr selten im Web Verwendet, aus diesem Grund soll sie hier auch nur kurz beschrieben werden. Ein Zertifikat als Authentifizierungsmerkmal ist auch durch aus umstritten da nicht sicher ist ob das Zertifikat noch in dem Besitzt des Benutzers ist für den es Ursprünglich mal ausgestellt wurde. Aus diesem Grund werden solche Zertifikate häufig mit einem Passwort geschützt, welches beim Zugriff eingegeben werden muss. Eine Bekannte Software die auf eine solche Authentifizierungsmethode nutzt ist die Elster Online Portal. ^[13]

6.2.1 Funktionsweise

Zum Verwenden einer Zerfikatsbasierten Authentifizierung benötigt man eine PKI (Public Key Infrastructur). Eine solche PKI bedarf einigem Aufwand und ist auch der große Nachteil dieses Authentifizierungsverfahrens. In einer solchen PKI gibt es eine CA der alle Vertrauen diese CA stellt für alle Untergeordneten Nutzer, Rechner oder Dienste Zertifikate aus. Dadurch das alle dieser CA Vertrauen kann man sich gegenseitig in seiner Identität Bestätigen. Bei Aufruf einer Web Seite über eine gesicherte HTTPS Verbindung (siehe Kapitel 5) gibt es Optional die Möglichkeit im vierten Schritt des Verbindungsaufbaus, die Identität des Benutzers zu überprüfen. Hierbei fordert der Server sein Zertifikat beim Browser an der Client liefert ihm eins zurück wenn der Server diesem vertraut, es also in seiner CA Steht ist der Benutzer bzw. der Browser Authentifiziert.^[14]

6.2.2 Zusammenfassung Zertifikate

Der Vorteil bei dieser Methode ist das sie bei richtigen Umgang als sehr sicher gilt. Das Zertifikat für den Benutzer ist allerdings fest im Browser gespeichert und muss exportiert werden um es woanders verwenden zu können. Der Benutzer hat also einen größeren Aufwand als es z.B. beim Passwort der Fall ist. Er kann sich aber auch einen angenehmen Komfort erhalten wenn er seine Zertifikate gut verwaltet. Wenn ein Zertifikat einmal in einem Browser integriert ist brauch er nämlich nicht sein Passwort einzugeben um es abzurufen sondern nur beim exportieren, es mit einem Passwort zu schützen. Bei diesem Sicherheitskonzept wird also davon ausgegangen das außer dem Benutzer kein weiterer Zugriff auf den Browser hat, was in vielen Situationen schwer realisierbar ist, wie z.B. wenn es in einer Familie nur einen Rechner ohne mehr Benutzer betrieb gibt. Hier müsste der Benutzer um sicher zu gehen das niemand sonst seinen Account missbraucht das Zertifikat immer wieder aus dem Browser löschen nach dem er es Importiert hat. Fast alle Web 2.0 Dienste bieten gar keinen Zertifikates basierten Login an. Die Gründe dafür sind wohl der höhere Aufwand einer Solchen Verwaltung so wie die Unwissenheit der Benutzer mit dem Umgang solcher Zertifikate. Es gibt Allerdings OpenID Provider die es ermöglichen eine OpenID mit einem Zertifikat in Verbindung als Authentifizierungs Merkmal zu nutzen.

6.3 Tokens

Eine zusätzliche Möglichkeit sich zu Authentifizieren sind Tokens. Tokens generieren in einem bestimmten Zeitfenster Kombinationen die übertragen werden können und so den Benutzer auszuweisen. Die Kombinationen sind Pseudo-Zufällig. Es gibt unterschiedliche arten von Tokens. Die meisten sind so groß wie ein Schlüsselanhänger. Es gibt Tokens die auf einem Display zahlen und/oder Buchstaben Kombinationen anzeigen die den Token identifizieren. Diese Kombinationen werden nach einer gewissen zeit neu berechnet und sind einmalig. Die Kombinationen sind Pseudo-Zufällig da sie auf einer gewissen Grundlage entstehen, diese Grundlage ist dem Authentifizierungssystem vertraut, damit er den Token identifizieren kann. ^[15] Solche Tokens kann man sich also als eine Art Schlüssel vorstellen, mit dem sich eine Applikation aufschließen lässt. So ein Token alleine als Authentifizierungsmerkmal zu nutzen wird in bestimmten Bereichen als Kritisch angesehen genau so wie es bei einem Zertifikat der Fall ist, da bei Verlust jede andere Person dieses Token verwenden kann um sich Zugriff auf das System zu verschaffen. Die Frage hierbei ist nur wie mit einem Gefundenen Schlüssel weiß er welche Tür er aufschließen kann. Aus diesem Grund werden Tokens oft in Kombination mit einem Passwort eingesetzt um so die Sicherheit zu erhöhen. Es kann zwischen zwei arten von Tokens unterschieden werden.

6.3.1 Challenge/Respones-Tokens

Challenge/Respones-Tokens sind Tokens der einen Sorte. Sie funktionieren nach dem Prinzip das sie sich einen geheimen Schlüssel mit dem Authentifikationsservice teilen. Der Server generiert also eine Zufallszahl mit diese Zufallszahl gibt er auf einem Prompt aus der Benutzer ließt diesen wert ab und gibt ihn in sein Token ein darauf hin generiert das Token einen Response Schlüssel, welchen der Benutzer jetzt in einen Eingabefeld einträgt und an der Server überträgt. Der Server kann dies nun mit dem gleichen Schlüssel den auch der Token hat entschlüsseln und erhält nun wieder seine Zufallszahl wenn diese beiden werte übereinstimmen hat sich der Benutzer erfolgreich Authentifiziert. ^[16] Solche Tokens werden heute auf Grund der Komplexität für den Benutzer bei der Authentifizierung nur noch sehr selten verwendet.

6.3.2 Zeitbasierte Tokens

Zeitbasierte Tokens haben den Vorteil das es bei ihnen kein Eingabefeld mehr gibt, bei ihnen wird als Zufallszahl die Zeit verwendet aus diesem Grund heißen sie auch Zeitbasierte Tokens. Beim erstellen eines solchen Tokens wird auch wieder ein gemeinsamer Schlüssel auf dem Server und auf dem Token hinterlegt. Hinzu zu dieser Information merkt sich der Server die Zeit wann der Token erstellt wurde. Diese Zeit in Verbindung des Schlüssel dient als Geheimnis. Der Token generiert jetzt in den meisten fällen alle 60 Sekunden eine neue Zahl die aus der Vergangenen Zeit seit seiner Erstellung besteht und aus dem Gemeinsamen Schlüssel mit dem Server. Diese Zahl kann nun an den Server übertragen werden und der Server kann mit Hilfe des gemeinsamen Schlüssels die Zeit errechnen die der Token generiert haben sollte stimmt diese mit der Zahl überein die der Server aus der Zeit seit dem erstellen des Tokens erhalten hat ist die Authentifizierung erfolgreich.^[17]

6.3.3 Yubikey

Ein Yubikey ist ein Token was auf eine andere Art funktioniert. Dieses Token besitzt keinen LCD DIsplay da es per USB angeschlossen werden kann und in diesem Augenblick eine USB Tastatur emuliert. Dieses vorgehen bringt den Vorteil mit sich, das der Yubikey so keine Batterie benötigt und so eine fast Untendliche Lebenszeit hat. Der Grund warum der Yubikey hier als Beispiel aufgeführt ist, ist das er OpenID unterstützt genau so wie SAML. Deshalb ist der besonders für das Web gut benutzbar. Die Firma Yubico die solche Yubikeys vertreibt bezeichnet ihn auch als: "The key to the cloud". Ein Yubikey bietet die Möglichkeit einen Yubikey jeder Zeit neu zu beschreiben ihn also neu zu Programmieren, so dass er einen neuen geheimen AES (Advanced Encryption Standard) Schlüssel erhält der dann auch wieder auf dem Authentifizierungsserver hinterlegt werden muss. So ist Sichergestellt das auch wirklich nur der jenige der den Key neu Programmiert hat den AES key kennt, genau so wie der Yubikey selbst natürlich.^[18]

Das OTP(One Time Password) des Yubikeys setzt sich wie auch in Abb. 3 zusehen folgender maßen zusammen. Die ersten sechs Bytes beinhalten eine Private Secret-id mit dem der Yubikey erkannt werden kann. Diese sind bei der Ausgabe immer gleich sie können also als ein Art Benutzername verwendet werden. Die nächsten beiden Bytes enthalten den Usage counter dieser beinhaltet einen nicht flüchtigen wert der bei einer neu Programmierung des Yubikeys erhalten bleibt und bei jeder neu Programmierung um eins erhöht wird. Die nächsten 8 Byte beinhalten den Timestamp er gibt die Zeit zurück seit der der Yubikey Programmiert wurde. Hieran sieht man also das der Yubikey ein Zeitbasiertes Token ist. Der nächste Bereich in der Session usage counter, er beinhaltet einen wert der bei jeder Verwendung des Yubikeys um eins Incrementiert wird. Es folgen weitere 2 Byte aus Zufallszahlen. Die letzten 2 Byte bilden eine Checksumme über den Inhalt. Nach Berechnung dieses wertes wird er mit dem Geheimen AES key verschlüsselt und damit es keine Probleme mit anderen Zeichensetzten gibt mit einem modhex verfahren umgewandelt.^[19]

Da die Yubikey Implementierung frei ist. Wurden zahlreiche Schnittstellen entwickelt so kann ein Yubikey z.B. für die Anmeldung an einem Windows, Linux oder Mac System verwendet werden. Was ihn für das Web 2.0 so Interessant macht ist seine mögliche Verwendung als Authentifizierung gegenüber einem OpenID Provider. Hinzu gibt es zahlreiche Funktionen für Verschiedenste Programmiersprachen wie z.B. PHP oder Java um ihn auch für eigene Anwendungen als Authentfizierungsmerkmal zu verwenden.

6.3.4 Zusammenfassung

Tokens können ein großes maß an Sicherheit bieten besonders in Verwendung mit einem Passwort. Der Nachteil ist das die Anschaffung solcher Tokens mit zusätzlichen Kosten verbunden ist, die im Falle von freien Web 2.0 Programmen der Benutzer selber auf sich nehmen muss. Um einen Yubikey im Web nutzen zu können bedarf einem OpenID Provider in diesem fall bietet sich http://www.clavid.com/ an. Hier gibt es die Möglichkeit sich Kostenlos zu Registrieren und so seinen Yubikey als Authentfizierungsmerkmal zu verwenden.

7 OpenID

OpenID ist ein SSO Technologie für das Web 2.0. Der Gedanke hierbei ist es sich nur einmal bei einem OpenID Provider anzumelden und alle weiteren Web Dienste, die über den Browser zugänglich sind, beim OpenID Provider nachfragen ob er den Benutzer kennt. Die Verwendbarkeit von einem Solchen Authentifizierungsdienst hängt stark von der Verwendung bei den Service Anbietern ab, sie müssen die Möglichkeit nämlich bereit stellen sich per OpenID zu Authentifizieren.

7.1 Entwicklungsgeschichte

Das Protokoll was OpenID zugrunde liegt wurde 2005 von Brad Fitzpatrick entwickelt. Brad Fitzpatrick ist der Entwickler der bekannten Community Webseite LiveJournal, der Name der heute als OpenID bekannt war hieß damals noch YARIS(Yet another distributed identity system). Er hatte die Idee sich über einen Relay mit Hilfe des Browser sich einmal bei einer Web Seite anzumelden und diese dann als Authentifizierungsserver für andere Dienste wie Blogs zu nutzen. ^[20] Als Lifejournal von SixApart aufgekauft wurde, bekam YARIS den Namen OpenID. Im Juni 2007 wurde dann die OpenID Fundation gegründet eine Organisation die es sich zum Ziel gesetzt hat OpenID weiter zu entwickeln ohne dabei den Profit in den Vordergrund zu stellen. ^[21]. Im laufe der Zeit schlossen sich immer mehr Namenhafte Unternehmen wie AOL, Versign, Microsoft und Google der OpenID Foundation an und Unterstützen die weiter Entwicklung mit Spenden.

In der Zeit der Entwicklung von OpenID wurden 3 Version des OpenID Protokolls entwickelt. Version 1.0 wurde 2005 veröffentlicht. Diese wird heute aber nicht mehr verwendet sonder nur der Nachfolger der im Mai 2006 veröffentlicht wurde, nämlich die Version 1.1 sie ist heute noch im Einsatz z.B. bei Facebook.

2007 wurde dann schon die Version 2.0 veröffentlicht. Die Version hat einige Verbesserungen wie die Directed Identity erhalten hier mit reicht es aus den OpeniD Provider an zu gegeben anstatt die komplette OpenID Url. Eine weiter Neuerung war die Einführung der OpenID Attribute Exchange 1.0, hiermit ist es dem Benutzer möglich seine Daten in allen Profilen Synchron zu halten. Dieses obliegt aber des Benutzers ob er dies so möchte oder nicht. Eine sinnvolle Funktion stellt es z.B. beim Kauf von Waren in einem Web Shop da. ^[22]

7.2 Funktionsweise

OpenID funktioniert über ein URL basiertes Login System. Ein OpenID Benutzer hat eine OpenID in form einer URL dies macht den Login weltweit Eindeutig. Wenn sich der Benutzer jetzt auf einer Seite anmelden möchte gibt er hier seine OpenID URL ein oder hinterlegt diese in seinem Benutzer Profil. Wenn er sich bei dem Dienst Provider anmelden möchte, gibt er hier seine OpenID URL ein oder nur seinen Benutzernamen. Nun wird er auf die Webseite seiner OpenID weitergeleitet wo er sich für die aktuelle Sitzung anmelden muss. Wenn die Anmeldung erfolgreich war wird er wieder zurück auf die Dienst Seite geleitet die er nutzen wollte und ist hier Authentifiziert. Falls der Benutzer schon einmal in der Aktuellen Sitzung bei seinem OpenID Provider angemeldet war bekommt er hiervon nichts mehr mit da er automatisch einmal zum Provider hin und dann wieder direkt zurück geleitet wird und so Authentifiziert ist^[23] siehe hierzu auch Abb. Bei der ersten Verknüpfung mit einem OpenID Provider werden aber nicht nur die Authentifizierungsdaten Übertragen sondern es können noch weitere Daten übertragen werden die der Service Provider haben möchte, welche das sind hängt ganz von Server Provider ab. Der Benutzer hat hier aber immer zu entscheiden welche Daten er weiter geben möchte und welche nicht. Der Service Provider entscheidet dann ob ihm das genügt und ob er den Login in Zukunft zu lässt.

7.3 Verbreitung

Für die Verwendung von OpenID gibt es zahlreiche Provider. Zu den Namenhaftesten gehören Google, Microsoft, Yahoo, und Verisign^[24]. Viele dieser Sponsoren haben OpenID auch schon implementiert, jeder der z.B. einen Google Account Besitzt hat auch automatisch die Möglichkeit diesen als OpenID zu Benutzen, ähnliches gilt auch für Yahoo. Leider treten diese immer nur als Provider auf und ermöglichen aber keinen Login mit der OpenID eines anderen Providers. So ist es heute noch nicht möglich seinen Yahoo Account für die Authentifizierung bei Google zu verwenden um sich so das erneute Anmelden zu Sparen. Als verbreitetster Service Provider der OpenID nutzt ist zur Zeit Facebook zu nennen. Bei Facebook ist es möglich seine OpenID in einem erstellten Profil zu hinterlegen um sich dann automatisch anzumelden. Es ist aber noch nicht möglich sich so direkt ein Profil erzeugen zu lassen und sich so die Registrierungsvorgang zu Sparen, hinzu haben einige Test gezeigt, das der Login mit einigen OpenID Providern wie z.B. clavid oft Fehlschlägt. Facebook will die Möglichkeit wohl auch noch nicht für die breite Öffentlichkeit anbieten sondern sieht es Momentan nur als Testbetrieb. Aktuell soll es mehr als 48000 Webseiten geben die den Login mit einer OpenID ermöglichen. Was bei der Menge an Webseiten die es gibt und der fülle an denen die eine Registrierung erfordern wohl noch lange nicht die Breite masse ist.^[25]

7.4 Zusammenfassung

OpenID ist eine sehr Interessante Implementierung eines SSO System im Web 2.0. Die mangelnde Verwendung und die Umsetzung scheitert leider oft an der Verbreitung der Service Provider die einen Login mit einer OpenID Implementierung ermöglichen. Wenn diese Verbreitung besser werden würde, könnte OpenID zu dem Login für alle werden egal welchen Provider man gerade nutzt. Für viele könnte z.B. ihr Email Provider dieser Provider sein, weil das erste was Sie machen ist es sich in ihr Web interface einzuloggen wenn Sie online gehen, für alle weiteren Websites brauchten sie dann keinen weiteren Login Mechanismus mehr. Ein solche Verbreitung würde auch die Sicherheit im Web verstärken.

8 Fazit

Es gibt viele Authentifizierungsmöglichkeiten in der IT Welt. Einige haben sich in Unternehmen für das Verwenden Kritischer Daten schon Etabliert. Häufig werden Tokens z.B. bei der Authentifizierung beim Aufbau eines VPN Tunnels genutzt. Im Web 2.0 sind diese Möglichkeiten leider noch nicht angekommen. Hier wird immer noch die Kombination aus Benutzername und Passwort als Authentifizierungsmerkmal verwendet. Leider zeigen diese Mechanismen aber auch immer wieder ihre Schwächen auf, da die Benutzer zu Faul sind sich sichere Passwörter auszudenken. Die Provider versuchen dies mit Mindest Passwort längen oder der anzeige wie Sicher eine Passwort ist zu verbessern aber so lange es hier keine bessere Aufklärung gibt wird die Verwendung von einfachst Passwärter wohl immer so weiter gehen.

Andere Technologien um sich zu Authentifizierung gibt es genug, so ist durch OpenID und Provider wie clavid.com möglich fast alle Authentifizierungsmechanismen zu Nutzen die es gibt, auch wenn diese Selbstverständlich auch ihre Schwächen haben. Im Verbund mit einem Passwort stellen Tokens oder Zertifikate aber eine Ausreichende Sicherheit da die diese Sicherheitslücke ausräumen könnte. Diese ist aber nur mit einer weiteren Verbreitung von OpenID nicht nur als Provider möglich. Es scheitert also zum Aktuellen Stand vieles daran das OpenID bis jetzt noch nicht weit genug Verbreitet ist um es für alle Webaccounts die man hat nutzen zu können. Eine weitere Verbreitung dieser Technologie könnte die Authentifizierung im Web sicherer und angenehmer machen.

9 Fußnoten

1. ↑ Vgl. Brink et al. S. 343-346
2. ↑ Hansen und Neumann 2005 S. 287
3. ↑ Linux Sicherheitskochbuch
4. ↑ Vgl. Tim Oreily
5. ↑ Vgl. W3c
6. ↑ Vgl. Mitchell / Pashalidis S. 2-4
7. ↑ Vgl. Brink et al. S. 550
8. ↑ Vgl. Lane und Williams (2004)
9. ↑ Vgl. Lane und Williams S. 432
10. ↑ Vgl. M 2.11 Regelung des Passwortgebrauchs
11. ↑ http://www.acunetix.com/blog/websecuritynews/statistics-from-10000-leaked-hotmail-passwords/# (31.01.2010)
12. ↑ Vgl. M 4.306 Umgang mit Passwort-Speicher-Tools
13. ↑ Vgl. Brink et al. S. 76 - 122
14. ↑ Vgl. RFC 2818
15. ↑ Vgl. Brink et al. S.365-367
16. ↑ Vgl. Brink et al. Buch S. 367-372
17. ↑ Vgl. Brink et al. S. 372-377
18. ↑ Vgl. Yubico Evaluation
19. ↑ Vgl. Yubikey Manual
20. ↑ http://community.livejournal.com/lj_dev/683939.html
21. ↑ Vgl. http://openid.net/foundation/
22. ↑ Vgl. http://www.xlogon.net/de/gossip/openid-2-0-veroeffentlicht
23. ↑ Vgl. heise Developer Artikel OpenID
24. ↑ http://openid.net/foundation/sponsoring-members/
25. ↑ http://blog.janrain.com/2009/07/relying-party-stats-as-of-july-1-2009.html

10 Literatur- und Quellenverzeichnis

Brink et al.(2002)	Derek Brink, Wiliam Duane, Celia Joseph, Andrew Nash: PKI e-securtiy implementieren, 1. Auflage, mitp Verlage, Bonn 2002
M 2.11 Regeln zum Passwort gebrauch	https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/m/m02/m02011.html (31.01.2010)
M 4.306 Umgang mit Passwort-Speicher-Tools	https://www.bsi.bund.de/cln_183/ContentBSI/grundschutz/kataloge/m/m04/m04306.html (31.01.2010)
Hansen / Neumann (2005)	Hans Rober Hansen, Gustaf Neumann: Wirtschaftsinformatik 1 Grundlagen und Anwendungen, 9. Auflage Lucius & Lucius Verlagsgesellschaft, Stuttgart 2005
Authentifizierungsdienste mit OpenID	http://www.heise.de/developer/artikel/Identity-Management-Authentifizierungsdienste-mit-OpenID-227202.html (23.01.2010)
Imperva Passwort Studie rockyou.com	http://www.imperva.com/docs/WP_Consumer_Password_Worst_Practices.pdf (31.01.2010)
Lane / Williams (2004)	David Lane und Hugh E. Williams, Webdatenbank-Applikationen mit PHP und MySQL, 2. Auflage, O'Reilly Verlag, 2004
Mitchell / Pashalidis	Andreas Pashalidis, Chris J. Mitchell: A Taxonomy of Single Sign-On Systems,
OpenID Spezikationen	http://openid.net/specs/openid-authentication-2_0.html (02.02.2010)
Oreily (2005)	Tim Oreily, What Is Web 2.0, http://oreilly.com/web2/archive/what-is-web-20.html (25.01.2010)
RFC 2818	http://www.ietf.org/rfc/rfc2818.txt (31.01.2010)
Yubikey Manual	http://www.yubico.com/files/YubiKey_manual-2.0.pdf (31.01.2010)
Yubico Security Evaluation	http://www.yubico.com/files/Security_Evaluation_2009-09-09.pdf (31.01.2010)
W3c	http://www.w3.org/standards/webdesign/ (25.01.2010)