Dipl. - Universität Tübingen

Transcrição

Eberhard-Karls-Universität Tübingen
Fakultät für Informations- und Kognitionswissenschaften
Wilhelm-Schickard-Institut für Informatik
Arbeitsbereich für Theoretische Informatik / Formale Sprachen
Diplomarbeit Informatik
Analyse von AuthentisierungsVerfahren für Online Accounts
Il-Hyun Kim
15. Februar 2012
Betreuer
Prof. Dr. Klaus Reinhardt
Dr. Bernd Borchert
Inhaltsverzeichnis
1
2
Einleitung.............................................................................................................................. 4
1.1
Motivation..................................................................................................................... 4
1.2
Thema und Ziel .............................................................................................................. 5
1.3
Vorgehensweise ............................................................................................................. 6
1.4
Übersicht von Authentisierungsverfahren........................................................................ 7
Grundlagen ........................................................................................................................... 8
2.1
Authentisierung ↔ Authentifizierung .............................................................................. 8
2.2
Sichere Übermittlung von Daten ..................................................................................... 9
2.3
Arten von Angriffen...................................................................................................... 11
2.3.1
Brute-Force Angriff................................................................................................ 11
2.3.2
Phishing................................................................................................................ 12
2.3.3
Trojaner ............................................................................................................... 13
2.3.4
Man-in-the-Middle Angriff..................................................................................... 15
2.3.5
Replay-Angriff ....................................................................................................... 16
2.3.6
Qualität der Angriffe ............................................................................................. 16
2.3.7
Sicherheitsrisiken.................................................................................................. 17
2.4
3
Methoden der Authentisierung..................................................................................... 18
2.4.1
Authentisierung durch Wissen (something you know) ............................................. 18
2.4.2
Authentisierung durch Besitz (something you have) ................................................ 19
2.4.3
Authentisierung durch persönliches Merkmal (something you are) .......................... 19
2.4.4
Authentisierung über jemanden, den man kennt (somebody you know) .................. 20
Authentisierungsverfahren ................................................................................................... 22
3.1
Wissen......................................................................................................................... 22
3.1.1
Passwortverfahren................................................................................................ 22
3.1.2
PIN-Verfahren....................................................................................................... 30
3.1.3
indizierte PIN-Verfahren (iPIN) ............................................................................... 31
3.1.4
Sicherheitsfrage .................................................................................................... 32
3.1.5
Zwei-Schritte Abfrage durch Kombination mit verschiedenen Passwort-Verfahren ... 33
3.1.6
Einmalpasswörter ................................................................................................. 34
3.1.7
Fazit Wissen.......................................................................................................... 34
3.2
Besitz........................................................................................................................... 36
3.2.1
RSA SecurID Token ................................................................................................ 36
3.2.2
USB-Device ........................................................................................................... 39
3.2.3
IBM Zone Trusted Information Channel (ZTIC)......................................................... 39
1
Fazit Besitz............................................................................................................ 41
3.2.4
4
Onlinebankingverfahren als Authentisierungsverfahren für Online Accounts........................... 42
4.1
4.1.1
Einmal-PIN Liste .................................................................................................... 42
4.1.2
indizierte Einmal-PIN Liste ..................................................................................... 46
4.1.3
Indizierte Einmalpasswortliste mit Schutz vor Man-in-the-Middle Angriffe ............... 47
4.1.4
indirekt indizierte Einmal-PIN Liste ......................................................................... 49
4.1.5
indirekt indiziertes Bild-Einmal-PIN-Liste ................................................................ 51
4.1.6
Linien-PIN............................................................................................................. 54
4.1.7
Cardano-PIN ......................................................................................................... 55
4.1.8
Visuelle-PIN .......................................................................................................... 57
4.1.9
Permutations-PIN.................................................................................................. 59
4.1.10
Bildpasswort-PIN................................................................................................... 62
4.2
6
TAN-Generatoren für Online Account Authentisierung ................................................... 64
4.2.1
eTAN / Token........................................................................................................ 64
4.2.2
eTAN-Plus / BW-Bank TAN-Generator .................................................................... 65
4.2.3
sm@rt-TAN........................................................................................................... 67
4.2.4
sm@rtTAN-Plus/chip TAN manuell ......................................................................... 68
4.2.5
sm@rt optic (Flickering)/chipTAN comfort.............................................................. 69
4.3
5
Papier TAN-Verfahren für Online Account Authentisierung ............................................. 42
Fazit Onlinebankingverfahren als Authentisierungsverfahren für Online Accounts ........... 71
Zwei- Wege-Kommunikation Authentifizierung...................................................................... 75
5.1
mTAN, smsTAN ............................................................................................................ 75
5.2
eKaay .......................................................................................................................... 78
5.3
Google Sesame............................................................................................................. 81
5.4
eKaayPIN mit Zwei-Wege-Kommunikation Authentifizierung .......................................... 83
5.5
Fazit Zwei-Wege-Kommunikation.................................................................................. 85
Zwei-Faktor-Authentifizierung .............................................................................................. 86
6.1
HBCI-1, HBCI-2, HBCI-3 (Secoder) .................................................................................. 87
6.2
2-step verification ........................................................................................................ 90
6.3
Internetpassport .......................................................................................................... 92
6.4
nPA ............................................................................................................................. 94
6.5
eKaayPIN ....................................................................................................................100
6.6
NFC-Foto-TAN .............................................................................................................102
6.7
Sichere Fenster ...........................................................................................................104
6.8
Schlüsselkarte .............................................................................................................105
6.9
Fazit Zwei-Faktor-Authentifizierung..............................................................................107
2
7
Symbiotische Zwei-Faktor Authentisierung...........................................................................109
7.1
Passwörter..................................................................................................................110
7.1.1
Low-Tech Verfahren.............................................................................................110
7.1.2
High-Tech Verfahren ............................................................................................111
7.1.3
Surjektive Substitution .........................................................................................111
7.2
Papier-TAN Verfahren als symbiotische Zwei-Faktor Authentisierung .............................112
7.2.1
indirekt indizierte Einmal-PIN Liste ........................................................................112
7.2.2
indirekt indizierte Einmal-Bild -Liste ......................................................................114
7.2.3
Linien-PIN............................................................................................................114
7.2.4
Visuelle-PIN .........................................................................................................115
7.3
TAN-Generatoren als symbiotische Zwei-Faktor Authentisierung ...................................116
7.4
Fazit Symbiotische Zwei-Faktor Authentisierung ...........................................................116
8
Klassifizierung von Authentisierungsverfahren......................................................................116
9
Single Sign On.....................................................................................................................119
9.1
Identity Management..................................................................................................119
9.2
Identität .....................................................................................................................119
9.3
Techniken für SSO .......................................................................................................120
9.3.1
9.4
Kerberos..............................................................................................................121
SSO Verfahren.............................................................................................................124
9.4.1
OpenID................................................................................................................124
9.4.2
Shibboleth ...........................................................................................................127
9.4.3
Liberty Alliance Project.........................................................................................130
9.4.4
Facebook Connect (FB Connect)............................................................................131
9.4.5
Microsoft Windows Live ID (ehemals .NET Passport) ..............................................140
9.4.6
Windows CardSpace (ehemals InfoCard)...............................................................141
9.4.7
Mozilla BrowserID................................................................................................143
9.5
Unterschiede und Gemeinsamkeiten von SSO Verfahren ..............................................150
9.6
Fazit SSO.....................................................................................................................150
10
Authentisierungsverfahren im Vergleich ...........................................................................151
10.1
Sicherheit und Benutzerfreundlichkeit ..........................................................................151
10.2
Authentisierungsverfahren auf einem Blick ...................................................................157
11
Schlusswort ....................................................................................................................159
12
Literaturverzeichnis.........................................................................................................162
13
Tabellenverzeichnis.........................................................................................................168
14
Abbildungsverzeichnis .....................................................................................................168
Erklärung...................................................................................................................................172
3
1
Einleitung
Ein Benutzer des Internets kann heute auf vielfältige Dienste zugreifen wie:
 Kommunikation (E-Mails, Soziale Netzwerke wie Facebook)
 Freizeit (Onlinespiele wie World of Warcraft, Cultures Online)
 Geschäfte (Online Banking, Amazon, eBay)
 Ämter (eGovernment)
Das Verwenden eines Dienstes durch einen Benutzer sollte sicherstellen, dass sowohl der Dienst als
auch der Benutzer ihrer angegebenen Identität entsprechen. So besitzt beispielsweise ein Benutzer
Zugangsdaten, welche nur ihm und dem Dienst bekannt sind und mit welchen er sich dem Dienst
gegenüber ausweist, also sich dem Dienst gegenüber authentisiert. Die verbreiteteste Form der
Authentisierung für Online Accounts ist die Abfrage über eine eindeutige Benutzerkennung und ein
dazugehöriges Passwort. Die meisten Onlinedienste bieten diese Art der Authentisierung an, da sie
die Möglichkeit der schnellen Einrichtung und sofortige Nutzung des Dienstes ermöglicht, sowie auf
die breite Akzeptanz der Benutzer trifft. Während den Anfängen des Internets war eine solche
Authentisierung vielleicht sicher genug, aber mit der fortschreitenden Technik stehen heutzutage
viele Methoden zur Verfügung stehen, um an das Passwort und zugehöriger Benutzerkennung zu
gelangen. Authentisierungsverfahren scheinen damit nicht Schritt gehalten zu haben. Die Benutzer
wollen sich schnell und komfortabel einloggen und sie scheinen sich an Passwörter gewöhnt zu
haben. Das mag vor 20 Jahren noch in Ordnung gewesen sein. Doch heutzutage besitzt man mehrere
Accounts und man wird von einer Passwortflut regelrecht erschlagen. Diese alle zu merken wird
immer schwieriger und die Benutzer benutzen entweder nur noch ein Passwort für alle Accounts
(was gefährlich für alle Online Konten sein kann, wenn ein Konto gehackt wurde) oder entwickeln
Systeme um sich alle Passwörter merken zu können, die schon an kryptologische Verfahren erinnern
können.
1.1 Motivation
Das World Wide Web ist 20 Jahre alt geworden und seit der Entstehung des Internets brauchte man
immer einen Weg um sich für bestimmte Dienste zu authentisieren, angefangen mit der E-Mail. Die
einfachste und schnellste Methode zu der Zeit war eine eindeutige Benutzerkennung und ein
dazugehöriges Passwort. Damals waren die Nutzer und Dienste übersichtlicher und die Technik noch
nicht so weit entwickelt, so dass ein achtstelliges Passwort noch als sicher galt. Doch seit den 90er
Jahren gibt es in Deutschland ca. 50 Millionen Internetnutzer [Wilkens, 2010]. Da viele Menschen in
Deutschland schon mehrere Accounts besitzen (z.B. eine oder mehrere E-Mail Accounts, ein Account
bei Facebook, Amazon, eBay, Onlinebanking), müssen sie sich dafür anmelden und private Daten wie
Name und Adresse angeben. Mit der Zeit wurde der Datenhunger der verschiedenen Dienste immer
größer und neben dem Namen werden auch weitere sensible Daten verlangt, wie Geburtstage,
Kreditkartennummer oder sonstige Bankdaten. Doch zusätzliche Accountsicherheit bieten meist nur
Dienste an, die offensichtlich mit sensiblen Daten zu tun haben, wie Onlinebanking. Und in diesem
Fall beschränkt man sich nur auf den Schutz von Transaktionen während einer Überweisung. Der
Account an sich ist in vielen Fällen immer noch nur mit einem Passwort geschützt. Diese können
heutzutage aber sehr leicht abgehört werden. Laut Polizeistatistik beträgt rund 38 Prozent der Fälle
für Computerkriminalität das Ausspähen und Abfangen von Daten und der Betrug mit
Zugangsberechtigungen [lis/AFP/dpa, 2011]. Man sollte aber mit einer hohen Dunkelziffer rechnen,
da wahrscheinlich viele Fälle nicht zur Anzeige gebracht werden. Da Banken um ihren Ruf fürchten,
4
sind zuverlässige Zahlen in dem Bereich nicht bekannt und auch in der Spielebranche werden wohl
viele gehackte Online Accounts nicht zur Anzeige gebracht. Sucht man aber im Internet nach
Kaufmöglichkeiten für virtuelles Gold von Onlinespielen, so kann man dort sehr leicht viele Angebote
finden. Es ist ein lukratives Geschäft daraus geworden1. Dabei werden die Betreiber der Dienste und
auch die Benutzer in die Pflicht genommen, sichere Passwörter zu benutzen und sie regelmäßig zu
ändern, sowie Antivirenprogramme und Firewalls zu installieren. Aber da eine regelmäßige Änderung
von sicheren Passwörtern den meisten Kunden zu anstrengend ist (man möchte nicht alle 14 Tage ein
neues sicheres Passwort ausdenken), wird dies auch von Serverbetreibern meist nicht verpflichtend
vollzogen, wie es z.B. bei Arbeitsplätzen der Fall ist. Dabei sind Schadprogramme im Internet in
großen Mengen vorhanden und so ist jeder 14. Download mit dem Internet Explorer eine Malware
[Haber, 2011]. Es ist auch ein sehr lohnendes Geschäft, da der gläserne Kunde wohl nun Wirklichkeit
geworden ist und man bereitwillig Daten weitergibt um Accounts zu eröffnen und dessen Dienst
benutzen zu können. So scheinen Nachrichten über Facebook und Apples IPhone, die im großen
Umfang Daten sammeln, keine großen Auswirkungen auf das Benutzerverhalten zu haben. Man
scheint sich schon damit abgefunden zu haben und man opfert die Privatsphäre, damit man die
Dienste nutzen kann. Doch gehackte Accounts können großen Schaden anrichten, auch wenn man
denkt, das Anschauen alleine kann nicht schaden. Neben dem Verkauf von den Benutzerdaten und
Informationen, was vielleicht mit etwas Glück in nur erhöhtem Spamaufkommen enden kann,
könnten Hacker diese Informationen auch nutzen, um gezielte Phishingversuche zu unternehmen
und so an noch sensiblere Daten zu gelangen. Auch ist der Verkauf von Nutzerdaten wie
Kreditkartennummern sehr lukrativ und schadet die Wirtschaft sehr. So werden damit Mikrodienste
z.B. für Onlinespiele bezahlt oder Onlinetickets bei Fluggesellschaften ersteigert und weiterverkauft.
Der Schaden für Banken, Fluggesellschaften und Versicherungen durch Onlinebetrug kann jährlich in
Milliarden gehen [Knoke, 2011]. Das Geschäft mit Kreditkartendaten und Adressen boomt und ein
kompletter Kreditkartensatz ist im Internet für bereits für 1-2$ erhältlich [Welchering, 2011].
Deshalb wäre es empfehlenswert die Benutzer und Betreiber weiterhin über die Gefahren
aufzuklären und dabei auch Alternativen zum bekannten Passwortverfahren zu entwickeln.
1.2 Thema und Ziel
Das Thema der Diplomarbeit ist es, verschiedene Authentisierungsverfahren für Online Accounts zu
analysieren. Dabei soll der Schwerpunkt der Arbeit auf Ablauf und mögliche Sicherheitsrisiken der
Authentisierung liegen. Da aber auch Benutzerfreundlichkeit/Kosten und Account Recovery zur
Authentisierung gehören, werde ich darauf auch am Ende jedes Verfahrens kurz eingehen und
versuchen diese mit den anderen Methoden zu vergleichen. Ich werde nicht nur bereits existierende
Methoden und Umsetzungen, sondern auch theoretische Ideen für Authentisierungen und neue
Klassifizierungen, die auf die klassische Verfahren und Einteilungen basieren können, vorstellen.
Das Ziel der Diplomarbeit wird es sein, Alternativen zum bekannten Passwortverfahren aufzuzeigen
und einen Überblick zu schaffen, sie zu klassifizieren und zu vergleichen.
1
Innerhalb von 14 Tagen läss t sich 77.000 Euro mit virtuellem Gold erwirtschaften und 418.000 Euro mit
Accounts [Schneider, 2011].
5
1.3 Vorgehensweise
In dieser Arbeit wird vorausgesetzt, dass die Daten auf den Servern sicher und verschlüsselt
gespeichert sind und die Webseiten und Server entsprechend sicher implementiert und gewartet
werden. So sollten Sicherheitsprobleme wie es z.B. bei Sony gab und man auf unverschlüsselte
Passwörter und andere sensible Daten zugreifen konnte nicht auftauchen
[amz/dapd/AP/Reuters/dpa/AFP, 2011]. Sollten nämlich die gespeicherten Passwörter Angreifern in
die Hände fallen, dann wären auch noch so sichere Authentisierungsverfahren nutzlos. In meiner
Arbeit werde ich bereits bekannte, experimentelle und theoretische Authentisierungsverfahren
vorstellen. Dabei werde ich im nachfolgenden Kapitel kurz auf die theoretische Grundlagen für eine
sichere Authentisierung vorstellen: Eine sichere Übertragung, Gefahren von Angriffen und Methoden
der Authentisierung.
Im dritten Kapitel stelle ich verschiedene Authentisierungsverfahren vor, die ich klassisch nach
Wissen und Besitz einordne. Ich versuche sie auf ihre Sicherheit, Benutzerfreundlichkeit und Kosten
zu analysieren.
Im vierten Kapitel werde ich Verfahren, die in erster Linie für Onlinebanking entworfen wurden, als
Authentisierungsverfahren für Online Accounts vorstellen. Danach stelle ich weitere Möglichkeiten
der Authentisierungen in jeweils eigenen Kapiteln vor: Die Zwei-Wege-Kommunikation und ZweiFaktor-Authentifizierungen und Unterschiede zwischen Zwei-Faktor-Authentifizierung und werde
anschließend im achten Kapitel die Authentisierungsverfahren entsprechend nach Unterschieden
und Gemeinsamkeiten klassifizieren.
Im neunten Kapitel möchte ich noch auf die Single Sign On (SSO) Authentisierungsverfahren für
Online Accounts näher eingehen und verschiedene Möglichkeiten vorstellen. Ich werde dabei auf
technische Details so gut es geht verzichten und mich mehr auf den Ablauf konzentrieren und wo
man Risikofaktoren finden kann.
Am Ende werde ich die Authentisierungsverfahren nach ihrer Sicherheit und Benutzerfreundlichkeit
vergleichen und tabellarisch auflisten und mit einem Schlusswort die Arbeit beenden.
6
1.4 Übersicht von Authentisierungsverfahren
In der folgenden Tabelle habe ich die Authentisierungsverfahren zusammengefasst, die ich in dieser
Arbeit näher betrachten werde.
Wissen
Passwort
PIN
iPIN
Sicherheitsfrage
2-Schritte Abfrage
Besitz
Einmal-PIN
Indizierte Einmal-PIN
Indizierte Einmal-PIN mit CAPTCHA
Indirekte indizierte Einmal-PIN
Linien-PIN
Cardano-PIN
Bildpasswort-PIN
Indirekt indizierte Bild Einmal-PIN
Permutations-PIN
Visuelle-PIN
eTAN
eTAN-Plus
RSA SecurID Token
sm@rt-TAN
sm@rtTAN-Plus
sm@rt optic
USB-Stick
ZTIC
Zwei-Faktor-Authentifizierung
HBCI-1, HBCI-2, HBCI-3
2-step-verification
Internetpassport
nPA
NFC-Foto-TAN
Schlüsselkarte
Sichere Fenster
Zwei-Wege-Kommunikation Authentifizierung
mTAN/smsTAN
Google Sesame
eKaayPIN als Zwei-Wege-Kommunikation
eKaay
Single Sign On
Shibboleth
Libberty Alliance Project
Facebook Connect
Microsoft Windows Live ID
Windows CardSpace
Mozilla Browser ID
Tabelle 1: Übersicht von Authentisierungsverfahren
7
2 Grundlagen
In diesem Kapitel möchte ich kurz auf ein paar Angriffsmethoden für Online Accounts eingehen und
die grundlegenden Methoden vorstellen, die es für eine Authentisierung gibt.
2.1 Authentisierung ↔ Authentifizierung
In dieser Arbeit geht es um Authentisierungsverfahren. Da man auf dem ersten Blick keinen
Unterschied zwischen den Ausdrücken Authentisierungsverfahren und Authentifizierungsverfahren
erkennen kann, möchte ich hier kurz auf den kleinen Unterschied eingehen. Im Englischen gibt es nur
den Ausdruck Authentication und im Deutschen stammen Authentisierung und Authentifizierung
vom gleichen griechischem Wort "authentikós" ab, das mit "echt" oder mit "Urheber" übersetzt
werden kann [Hoeveler, 2010]. Der Unterschied zwischen den beiden Ausdrücken ist Minimal und
der Duden schreibt für authentifizieren "beglaubigen, die Echtheit von etwas bezeugen" und
authentisieren "glaubwürdig, rechtsgültig machen". Der feine Unterschied zwischen den beiden
Wörtern ist, dass der Benutzer sich authentisiert und der Server den Benutzer authentifiziert.
Ansonsten ist die Bedeutung das gleiche: Nämlich sich als Berechtigter zu identifizieren und Zugang
zu Daten zu erhalten.
Abbildung 1: Benutzer - Server Beziehung
8
2.2 Sichere Übermittlung von Daten
In Abbildung 1 sieht man die vereinfachte Kommunikation zwischen einem Benutzer und dem Server.
Dabei geht man davon aus, dass es zu keiner Beeinträchtigung während der Übermittlung der Daten
kommt. Dies ist aber in der Wirklichkeit nicht möglich und bei der Übermittlung von Daten über das
Internet kann es zu folgenden Beeinträchtigungen kommen [Hauck, 2003]:




zufällige Störungen
systematische Störungen (physikalisch bedingt)
passive Beeinträchtigung (Abhören von Übertragungen, Speichermedien)
aktive Beeinflussung (Fälschen von Daten, Übertragungen)
Die ersten beiden Störungen sind mehr technischer oder physikalischer Natur. Für die letzten beiden
Beeinträchtigungen kann die Kryptologie weiterhelfen. Sie hat die Aufgabe eine oder gleichzeitig
mehrere der folgenden Anforderungen an die Datensicherheit zu gewährleisten:




Geheimhaltung (soll das Lesen oder Abhören einer Nachricht verhindern)
Authentifizierung (Identitätsbeweis, d.h. der Empfänger einer Nachricht sollte sicher sein,
dass die Nachricht nicht von einem unbefugten Absender kommt)
Integrität (Verhinderung der Beeinflussung einer Nachricht von Unbefugten)
Verbindlichkeit (Absender kann nicht leugnen eine Nachricht abgeschickt zu haben)
Die Kryptologie lässt sich dabei in zwei Teildisziplinen einteilen: Die Kryptografie und die
Kryptoanalyse [Hauck, 2003]. Dabei ist die Kryptografie dafür zuständig, ein
Verschlüsselungsverfahren zu entwerfen und die Kryptoanalyse untersucht, wie man das Verfahren
brechen kann. In der Kryptografie gibt es dabei verschiedene Verfahren. Bekannte kryptologische
Verfahren sind:





DES (Data Encryption Standard)
3DES (Triple DES)
AES (Advanced Encryption Standard)
RSA (River-Shamir-Adleman)
Diffie-Hellman Public Key Verfahren
Die Sicherheit der Verfahren sollte dabei nicht von der Geheimhaltung des Verfahrens selbst
abhängig sein, sondern nur vom Schlüssel. So sollte eine Verschlüsselung nicht zu brechen sein,
selbst wenn man das Verschlüsselungsverfahren kennt. Dieses Prinzip wird Kerkhoffs'sches Prinzip
[Kerckhoffs, 2011] genannt. Die Sicherheit sollte also nur von der Schlüssellänge abhängig sein. Das
DES2 Verfahren benutzt einen 54 Bit großen Schlüssel, was zu der Zeit3 in der es entwickelt wurde
lang genug war. Doch durch die rasante Entwicklung der Computer ist diese nicht mehr sicher genug.
So verkürzte sich die Zeit um ein DES Schlüssel zu ermitteln während der DES Challenges von 96 Tage
im Jahre 1997 auf 22 Stunden 1999 [Deep Crack, 2011].
Die Verschlüsselungsverfahren lassen sich durch die Anzahl der Schlüssel einordnen. Man kann eine
Chiffrierung und Dechiffrierung entweder mit einem gemeinsamen geheimen Schlüssel oder mit zwei
Schlüsseln, einem sogenannten öffentlichen und einem privaten Schlüssel, durchführen. Die
2
3
Data Encryption Standard
1977
9
Verfahren werden Symmetrische (Klassisch) und Asymmetrische (Public Key) Verschlüsselung
genannt. Für ein symmetrisches Verfahren wird ein Schlüssel benutzt, für ein asymmetrisches
Verfahren werden zwei Schlüssel gebraucht.
Bekannte symmetrische Verfahren sind:



DES (benutzt eine Schlüssellänge von 56 Bit)
3DES (benutzt eine Schlüssellänge von 168 Bit)
AES (kann eine Schlüssellänge von 128, 192 oder 256 Bit benutzen)
Bekannte asymmetrische Verfahren sind:


RSA (Schlüssellänge von 3072 Bit möglich)
Diffie-Hellman Public Key Verfahren (Schlüssellänge von 3072 Bit möglich)
Der Grund warum man Verfahren mit kürzerer Schlüssellänge wählt liegt meistens daran, dass eine
Verschlüsselung damit schneller berechnet werden kann. Zurzeit gilt eine Schlüssellänge von 128 Bit
Schlüssel als sicher. So ergeben sich damit
≈ 2,5*
Schlüssel. Nimmt man also an, dass man
Schlüssel pro Sekunde testen kann und 50% der Schlüssel getestet werden müssen, dann ergibt
dies einen Aufwand von 1,25*
Sekunden ≈ 4*
Jahre. Doch lautet Moore's Gesetz, dass sich
die Rechenleistung ungefähr alle 18-24 Monate verdoppelt. Das könnte in der Zukunft dazu führen,
dass diese Schlüssellänge nicht mehr sicher genug ist [Key size, 2011]. Man versucht aber auch die
Sicherheit zusätzlich zu erhöhen, indem man verschiedene Verschlüsslungen hintereinander ausführt.
In der Kryptologie wird der Absender Alice genannt und der Empfänger Bob. Der aktive Hacker wird
Mallory genannt und die passive Lauscherin Eve. Später sind bei meiner Analyse von
Authentisierungsverfahren Alice der Benutzer, Bob der Onlinedienst und der Hacker ein Angreifer.
Abbildung 2: Darstellung von Sender, Hacker und Empfänger
DES
3DES
AES
RSA
Diffie-Hellman
Symmetrische
Asymmetrische
Verschlüsselung Verschlüsselung
X
X
X
X
X
Schlüssellänge in Bit
56
168
128, 192, 256
1024 empfohlen
1024 empfohlen
Tabelle 2: Verschlüsselungsverfahren
10
2.3 Arten von Angriffen
In der Kryptoanalyse gibt es qualitative Unterschiede (in absteigender Reihenfolge):



Vollständiges Aufbrechen (Schlüssel ist bekannt)
Globale Deduktion (Nachricht ist ohne Kenntnis des Schlüssels entschlüsselbar)
Lokale Deduktion (Es kann nur eine abgefangene Nachricht entschlüsselt werden)
Dabei gibt es verschiedene Arten von Angriffen in der Kryptoanalyse [Kryptoanalyse, 2011]:





Cyphertext-Only-Attack: Dem Hacker ist nur eine bestimmte Menge von verschlüsselten
Daten bekannt. Mit diesen Informationen versucht er den Schlüssel zu finden.
Known-Plaintext-Attack: Dem Hacker sind die verschlüsselten und die dazugehörigen
entschlüsselten Daten bekannt.
Chosen-Plaintext-Attack: Der Hacker hat Zugang zu beliebige verschlüsselte Daten die
dazugehörigen entschlüsselten Daten.
Brute-Force-Attack: Man probiert den gesamten Schlüsselraum durch um den Schlüssel zu
finden.
Angriffe mit Gewalt, Bestechung, Erpressung, Social Engineering (Phishing), Malware
(Trojaner/Keylogger, Viren) o.ä.
In der Praxis sind die letztgenannten Angriffe sehr erfolgreich. Durch das sogenannte Social
Engineering, wie z.B. das einfache nachschauen von Passwörtern am Arbeitsplatz oder Phishings
sowie durch Trojaner, Keylogger und sonstige Computerviren lassen sich schnell und einfach
Passwörter herausfinden. Ein Angreifer kann verschiedene Methoden benutzen um Accountdaten zu
erhalten. Da Hacker meist die einfachste Methode wählen, wird die Sicherheit von
Authentisierungsverfahren in dieser Arbeit hauptsächlich auf bekannte passive (abhören über
Trojaner, Keylogger und sonstige Malwares, Replay Angriff) und aktive Angriffsarten (Brute-Force,
Social Engineering, Man-in-the-Middle) analysiert. Neben den Sicherheitsanalyse auf bekannte
Gefahren werde ich auch Sicherheitsprobleme ansprechen, die durch neue technische Neuerungen
entstehen könnten4. Für die praktische Sicherheitsanalyse stelle ich nun die bekannten Angriffsarten
näher vor.
2.3.1
Brute-Force Angriff
Bei einem Brute-Force Angriff probiert man alle Kombinationen aus, die es für den Schlüssel bzw.
Passwort geben kann. Irgendwann wird man dann die richtige Reihenfolge finden. Normalerweise
dauert das aber sehr lange. Verbesserte Techniken, wie schnellere Prozessoren, Zusammenschließen
von Rechenkapazitäten5, größere Speicherkapazitäten usw. beschleunigen aber solche Angriffe und
sollten daher nicht unterschätzt werden. Brute-Force-Angriffe kann man mit sogenannten
Wörterbuch-Angriffen oder Rainbow Tables optimieren, damit man nicht alle Kombinationen
ausprobieren muss und so schwache Passwörter schnell herausfinden kann. Bei WörterbuchAngriffen wird eine Passwortliste mit bekannten Passwörtern (oder einfach aus Wörtern aus einem
Wortschatz) durchprobiert [Wörterbuchangriff, 2011]. Rainbow Table ist eine Datenstruktur, die
eine schnelle und probalistische Suche nach einem Hashwert zugeordnetem Passwort ermöglicht.
4
5
Viren für Smartphones könnten z.B. in Zukunft eine ernste Gefahr darstellen.
Z.B. Cloud Computing.
11
Dies ist eine mögliche Methode um ausgespähte verschlüsselte Passwörter, die auf einem Server
gespeichert sind, zu knacken.
Abbildung 3: Hacker Mallory probiert alle Kombinationen für ein Passwort aus.
2.3.2
Phishing
Phishing ist eine Variante des Social Engineerings. Das Ziel von Social Engineering ist es, über
zwischenmenschliche Beeinflussung und Manipulation an unberechtigte Daten zu gelangen [Social
Engineering, 2011]. So kann man Passwörter ausspähen, indem man einfach am Arbeitsplatz
vorbeischaut und entweder heimlich über die Schulter schaut oder auch nach aufgeschriebenen
Passwörtern sucht, die sich auf Zettel am Monitor usw. befinden. Eine beliebte Methode ist es auch
sich als eine Autoritätsperson auszugeben, sei es am Telefon, per E-Mail oder indem man sie auf der
Straße einfach "interviewt". Das Wort Phishing könnte vom Password fishing bzw. Password
harvesting fishing herkommen, d.h. das "Fischen von Passwörtern mit einem Köder" [Phishing, 2011].
Beim Phishing versucht man beispielsweise den Benutzer auf eine gefälschte Webseite zu locken und
ihn mit einem Trick dazu zu bringen, seine Benutzerdaten wie Benutzername und Passwort
einzugeben. Wenn man beim Phishingversuch das soziale Umfeld zuerst ausspäht und dann einen
personalisierten Angriff macht, nennt man es Spear Phishing sprechen. Ein typischer Phishingversuch
könnte in etwa so aussehen:
1. Mallory schickt an Alice eine gefälschte E-Mail. Die E-Mail hat meist die Aufmachung einer
offiziellen Stelle wie die Polizei oder einer Firma, von der man die Daten gerne hätte, wie z.B.
einer Bank. Gewöhnlich sind die E-Mails von der Aufmachung kaum von den Originalen zu
unterscheiden und auch die Absendeadresse ist gefälscht.
Abbildung 4: Mallory schickt eine Phishingmail an den Alice.
12
2. In der E-Mail steht ein Link dabei und man wird darauf hingewiesen, dass man z.B. aus
Sicherheitsgründen6 einen Identitätsnachweis benötigt und dort alle nötigen Daten eingeben
muss, damit man ihn verifizieren kann. In Abbildung 5 geht der Benutzer auf eine gefälschte
Homepage, die wie eine offizielle Seite aussieht und gibt dort die Daten ein. Diese Daten
werden dann an den Hacker zugeschickt.
Abbildung 5: Alice bes ucht eine gefälschte Seite und gibt seine Daten ein, die an den Mallory weitergeleitet werden
3. Mallory kann sich mit diesen Daten als Alice gegenüber Bob authentisieren.
Abbildung 6: Mallory gibt sich gegenüber Bob als Alice aus
Es gibt auch abgewandelte Methoden, wie z.B. manipulierte Webseiten von offiziellen
Onlinediensten, die dann anstatt zur richtigen Loginseite zu einer falschen führen, die die dort
eingegebenen Daten an Mallory weiterleiten. Diese nennt man Cross Site Scripting (XSS) und durch
Ausnutzen von Sicherheitslücken in Webanwendungen können damit auch Phishingangriffe gestartet
werden [Cross-Site-Scripting, 2011].
2.3.3
Trojaner
Ein Trojaner oder auch Trojanisches Pferd ist ein Programm, dass sich als ein anderes (nützliches)
Programm tarnt, aber eine andere Funktion erfüllt ohne Wissen des Benutzers. Der Trojaner gehört
dabei zu der Familie der Malware7 [Trojanisches Pferd, 2011]. Ein Trojaner kann z.B. ein Keylogger
installieren. Ein Keylogger ist ein Programm, das heimlich im Hintergrund die Tastatureingaben
6
Weil man z.B. illegale Aktivitäten auf dem Benutzeraccount vermutet.
Malware ist dabei der Überbegriff für die verschiedenen Schadprogramme, die im Umlauf sind [Malware,
2011].
7
13
aufzeichnet. Da Trojaner Programme sind, die installiert werden müssen, können sie nur über Wege
auf dem Computer gelangen, über die man Daten auf dem Computer speichert. Das geht über
Datenträger wie CD, DVD, USB Sticks oder Netzwerkverbindungen. Zwei übliche Methoden die
Trojaner zu verbreiten sind E- Mails und Webseiten. So muss Mallory nicht unbedingt wie bei
Phishingseiten eine gefälschte Webseite erstellen und Nutzer auf diese Seite locken, sondern er kann
auch versuchen offizielle und harmlose Webseiten zu hacken und sie zu verändern, damit
Internetsurfer, die diese Seite besuchen, einen Trojaner automatisch unbeabsichtigt runterladen.
Abbildung 7: Mallory manipuliert eine Webseite mit einem Trojaner.
Dieses sogenannte Drive-by-Download nutzt dabei Sicherheitslücken von Webbrowser aus [Drive-byDownload, 2011].
Abbildung 8: Alice installiert den Trojaner unwissentlich über einen Drive-by-Download auf seinen Rechner.
Die andere beliebte Methode um einen Trojaner zu verbreiten ist, wenn Mallory an Bob eine E-Mail
verschickt und den Trojaner als eine harmlose Datei tarnt, die an der E-Mail angehängt ist. Sie kann
als Bild, gepacktes Dokument oder als Textdatei getarnt sein. Öffnet Alice die Datei, so wird dann
unwissentlich ein Trojaner installiert (Abbildung 9).
Abbildung 9: Mallory schickt eine E-Mail mit einem angehängten Trojaner an Alice.
14
Wurde nun Alice mit einem Trojaner infiziert, so können z.B. Keylogger alle Tastatureinschläge
speichern und sie an Mallory senden. So können Benutzernamen und Passwörter ausgespäht werden
(Abbildung 10). Auch könnten Trojaner Screenshots vom Bildschirm machen und die Bilder an
Mallory schicken.
Abbildung 10: Alice verbindet sich mit Bob und die Zugangsdaten werden auch an Mallory gesendet.
Mit den so erschlichenen Daten kann Mallory sich als Alice bei Bob authentisieren (Abbildung 11).
Abbildung 11: Mallory loggt sich bei Bob ein.
2.3.4
Man-in-the-Middle Angriff
Bei einem Man-in-the-Middle Angriff befindet sich der Angreifer zwischen zwei
Kommunikationspartnern und kann die Informationen abhören und manipulieren [MITM, 2011]. Eine
Art aktives Abhören. Dabei können unsichere Verbindungen wie öffentliche WLANs als eine Plattform
für solche Angriffe dienen. Mallory hängt sich zwischen Alice und Bob ein und manipuliert dabei die
Daten, die von Alice an Bob geschickt werden und umgekehrt. Dabei spielt Mallory die Rolle des Bobs
gegenüber Alice und Alice gegenüber Bob. So kann Mallory die abgehörten Benutzerdaten für eigene
Zwecke benutzen.
Abbildung 12: Mallory fängt die Kommunikation zwischen Alice und Bob ab und kann sie verändert an ihnen weitergeben.
Diese Angriffsmethode kann auch für Phishing über Cross Site Scripting (XSS) benutzt werden. Dabei
nutzt der Angreifer z.B. Sicherheitslücken auf Webseiten oder Browser aus um den Benutzer auf
15
seine Seite zu locken und dort die Eingabe des Benutzernamens und Passwortes abzuhören. Dabei
merkt der Benutzer nicht, dass er auf eine Seite von Mallory anstatt des Onlinedienstes ist. Nachdem
der Benutzer seine Daten eingegeben hat, gaukelt z.B. Mallory ihm vor, dass es einen Fehler gab.
Gelingt Mallory die Session zwischen Alice und Bob zu klauen, dann ist damit Mallory möglich, sich
als Alice auszugeben und ohne Probleme auf den Account einzuloggen. Solche Angriffe versucht man
natürlich mit verschiedenen Methoden zu verhindern, wie z.B. verschlüsselte Übertragung,
verschlüsselte Session, zeitlich begrenzt gültige Session und regelmäßige Überprüfung zwischen den
beiden Kommunikationspartnern.
2.3.5
Replay-Angriff
Bei einem Replay-Angriff belauscht Eve den Datenverkehr zwischen Alice und Bob und gibt sich
später gegenüber Bob als Alice aus und benutzt die abgehörten Daten um sich zu authentisieren.
Abbildung 13: Eve hört die gesendeten Daten zwischen Alice und Bob ab.
Dabei sendet er einfach die kopierten abgehörten Daten unverändert an Bob.
Abbildung 14: Eve gibt sich Bob gegenüber als Alice aus und sendet die abgehörten Daten an Bob.
2.3.6
Qualität der Angriffe
Wendet man die qualitativen Unterschiede von den Angriffen der Kryptoanalyse auf die
Authentisierungsverfahren an, so wäre z.B. das vollständige Aufbrechen, wenn das Passwort bekannt
wäre und man damit unbegrenzt oft einloggen kann. Eine globale Deduktion bedeutet, dass man sich
unbegrenzt oft in ein Account einloggen kann, ohne den Schlüssel zu kennen. Dies wäre z.B. durch
fehlerhafte Implementierung möglich, wenn über Cookies oder URL Bezeichnungen Schwachstellen
zu finden wäre, die es ermöglichen mit diesen Informationen sich auf Accounts einzuloggen, wie es
z.B. bei LinkedIN der Fall war. So konnte man sich, nur mit Hilfe der abgefangenen Cookies und der
Session ID, Zugang zu fremden Accounts verschaffen [Narang, 2011]. Mit einem erfolgreichen Replay
Angriff könnte man eine globale Deduktion erreichen, d.h. auch ohne Wissen des Passworts
unbegrenzten Zugang zum Account erhalten. Mit Hilfe von einem Man-in-the-Middle Angriff wäre es
16
möglich einmalig auf ein Account zuzugreifen zu können, indem er die Daten vom Benutzer zum
Server abfängt. Das wäre mit der lokalen Deduktion vergleichbar. Ein Anfang um sich gegen die oben
genannten globale oder lokale Deduktion zu schützen wäre das Nutzen eines sicheren Kanals zur
Kommunikation, z.B. eine Zwei-Kanal-Kommunikation wie die SMS eines Handys.
Angriffsarten
Vollständiges Aufbrechen
Phishing
X
Malware
X
Man-in-the-Middle
X
Brute-Force
X
Replay
Globale Deduktion Lokale Deduktion
X
X
X
X
X
Tabelle 3: Qualität eines Angriffs
2.3.7
Sicherheitsrisiken
Wie wir gesehen haben, hat ein Angreifer verschiedene Möglichkeiten, um Zugriff auf einen
Accountschlüssel zu erhalten. Die im späteren Kapiteln vorgestellten Authentisierungsverfahren
werden nach den hier vorgestellten Sicherheitsrisiken R1.R5 überprüft. Es kann noch andere
Angriffsmöglichkeiten geben, doch möchte ich in dieser Arbeit hauptsächlich auf die Möglichkeiten
beschränken, die beliebt und einfach für Angreifer zu realisieren sind. So arbeiten Angreifer meistens
nach Kosten/Nutzen-Faktor. Nach den folgenden Kriterien werden ich die Authentisierungsverfahren
überprüfen:
R1. Der Schlüssel (z.B. Passwörter): Wie einfach ist es, den Schlüssel mit Brute-Force Methoden
herauszufinden? Man kann jeden Schlüssel mit Ausprobieren irgendwann herausfinden. R1
gilt als ausreichend sicher, wenn es dem Angreifer zu teuer werden würde um den Schlüssel
mit Brute-Force herauszufinden. Teuer kann dabei die Zeit oder die Ressourcen bedeuten,
die er benötigt, um den Schlüssel herauszufinden.
R2. Der Benutzer und Besitzer des Schlüssels: Auch er kann Ziel des Angreifers sein. Dies
geschieht meistens über Social Engineering wie z.B. Phishingversuche über E-Mails. Auch XSS
Angriffe gelten hier dazu, wenn man sie über Tricks auf Webseiten leitet um damit
Benutzerdaten zu erhalten. R2 gilt als ausreichend sicher, wenn eine Weitergabe des
Schlüssels schwierig, für den Angreifer nutzlos oder zu teuer ist.
Weitere Angriffsmöglichkeiten auf den Schlüssel bieten die Orte, wo er übertragen bzw. gespeichert
wird.
R3. Die Eingabe des Schlüssels: Der Angreifer versucht während der Eingabe Informationen über
den Schlüssel zu erhalten bzw. zu manipulieren, so dass er am Ende Zugang zum Account
erhalten kann. Das versucht er z.B. mit Hilfe von Trojanern wie Keyloggern. R3 kann als sicher
gelten, wenn ein Angreifer nicht genügend Informationen (z.B. für Ciphertext-Only Angriffe)
oder Zugang zum Account durch das einfache Abhören oder Manipulieren erhalten kann.
R4. Übertragung des Schlüssels: Der Angreifer versucht während der Übertragung Informationen
über den Schlüssel zu erhalten bzw. zu manipulieren. Dies kann durch Abhören oder
Abfangen geschehen, indem Replay oder Man-in-the-Middle Angriffe eingesetzt werden. R4
kann als ausreichend sicher gelten, wenn ein Angreifer nicht genügend Informationen (z.B.
für Ciphertext-Only Angriffe) erhalten kann oder Zugang zum Account durch einfache
17
Manipulationen erhält. Sollte ein Angreifer nur in der Lage sein, erfolgreiche Angriffe zu
starten, wenn sie zeitgleich geschehen müssen, dann kann man R4 als ausreichend sicher
ansehen, da solche Operationen meistens für Angreifer zu teuer sind.
R5. Speicherorte des Schlüssels: Der Schlüssel kann an verschiedenen Orten aufbewahrt werden.
So kann er auf einem Server gespeichert sein oder je nach Methode auch auf Listen, Tokens
oder Smartcards. R5 kann gelten, wenn die Schlüssel so gut abgesichert sind, dass es einem
Angreifer nicht möglich ist darauf zuzugreifen oder es ihm viel Mühe kosten würde. Meistens
werden z.B. Server nur gehackt, wenn Sicherheitsvorkehrungen nicht eingehalten bzw.
Sicherheitslücken nicht geschlossen wurden. In den meisten Fällen sollte man voraussetzen,
dass die Schlüssel sicher aufbewahrt werden. Daher sollte R5 normalerweise für fast alle
Authentisierungsverfahren als ausreichend sicher gelten. Doch in der Vergangenheit wurden
leider schon genügend Fälle bekannt, in der Angreifer einfache Sicherheitslücken ausnutzten
und so Kundendaten stehlen konnten.
2.4 Methoden der Authentisierung
Möchte sich ein Benutzer auf sein Account einloggen, so muss er sich dem Onlinedienst
gegenüber authentisieren. Der Onlinedienst authentifiziert den Benutzer und bestätigt die
Echtheit oder die Zugangsberechtigung. Diese Bestätigung wird auch Autorisierung genannt.
Im nächsten Kapitel werden bestimmte Authentisierungsverfahren und Möglichkeiten
vorgestellt. In diesem Kapitel wird näher auf die Methoden der Authentisierung eingegangen.
Es gibt hauptsächlich drei Möglichkeiten, wie sich ein Benutzer einem Onlinedienst
gegenüber authentisieren kann [Authentifizierung, 2011]: Wissen, Besitz und Persönliche
Merkmale.
2.4.1
Authentisierung durch Wissen (something you know)
Der Benutzer weiß etwas um seine Identität nachweisen zu können. Dabei kann es sich z.B. um ein
Passwort, PIN (Persönliche Identifikationsnummer) oder die Antwort auf eine Sicherheitsfrage sein.
Eigenschaften dieser Methode sind:




Das Wissen kann vergessen werden.
Das Wissen kann vervielfältigt, weitergegeben und verraten werden.
Das Wissen kann eventuell erraten werden (schwache PIN wie Geburtstage)
Die Preisgabe von Wissen kann kompromittiert werden.
18
Abbildung 15: Benutzer kennt ein Geheimnis, dass nur er wissen kann, z.B. ein
Passwort und authentisiert sich damit beim Onlinedienst.
2.4.2
Authentisierung durch Besitz (something you have)
Der Benutzer besitzt etwas, was nur er haben kann und benutzt es um seine Identität nachzuweisen.
Wie z.B. ein physischer Schlüssel im Form einer Chipkarte (Smartcard), Magnetstreifenkarte, RFIDKarte, USB-Stick oder Festplatte mit Passwort oder Schlüssel-Code, Zertifikat. Für
Einmalpasswortverfahren kann man eine TAN-Liste oder Handys bei mTAN benutzen und auch
sogenannte Authentifikatoren.
Eigenschaften dieser Methoden sind:
 Benutzer sollte den physischen Schlüssel immer bei sich tragen.
 Schlüsselherstellung kann Zeit (in manchen Fällen muss der Schlüssel verschickt werden) und
Geld (Lesegeräte bzw. Herstellungskosten für den phsyischen Schlüssel wie eine RFID-Karte)
kosten.
 Der Schlüssel kann verloren gehen.
 Der Schlüssel kann gestohlen werden.
 Der Schlüssel kann weitergegeben oder kopiert (wie TAN-Listen) werden.
 Der Schlüssel kann ersetzt werden.
 Der Schlüssel kann Daten speichern (z.B. bei Smarcard, RFID-Karten).
 Der Schlüssel kann sich selbst schützen und verändert werden (z.B. über Updates bei
Smartcards).
Abbildung 16: Benutzer besitzt einen schwer zu fälschenden Gegenstand, z.B. ein Ausweis und
authentisiert sich damit beim Onlinedienst.
2.4.3
Authentisierung durch persönliches Merkmal (something you are)
Der Benutzer authentisiert sich mit sich selber, z.B. mit einem biometrischen Merkmal wie ein
Fingerabdruck. Weitere einzigartige körperliche Merkmale wäre das Gesicht, die Stimme, die Iris
oder die Retina, die Handfläche bzw. Handlinienstruktur und die DNA. Die Handschrift wäre auch
noch eine Möglichkeit, die ein persönliches Merkmal darstellen kann.
Eigenschaften dieser Methode wären:




Das Merkmal wird immer mitgeführt.
Bestimmte Merkmale kann man nicht einfach weitergeben oder kopieren. In manchen Fällen
ist eine Lebenderkennung empfehlenswert, da künstliche Fingerabdrücke hergestellt werden
können.
Merkmalerkennung benötigt spezielle Scanner, Technik oder Software.
Merkmalerkennung kann zu Datenschutzproblemen führen, da die erfassten Merkmale
verteilt und abgespeichert werden müssen.
19




Merkmalerkennung nicht 100%ig möglich, sondern nur mit einer bestimmten
Wahrscheinlichkeit . Es kann zu einer fehlerhaften Erkennung (False Acceptance, die
eingelesenen Daten werden fehlerhaft übermittelt) oder fehlerhaften Zurückweisung (False
Rejection, die eingelesenen Daten werden fehlerhaft verglichen) führen.
Persönliche Merkmale können sich mit der Zeit verändern.
Persönliche Merkmale können nicht ersetzt werden.
Benutzer, denen das persönliche Merkmal fehlt, können dieses Verfahren nicht benutzen.
Abbildung 17: Benutzer besitzt biometrische Daten wie Fingerabdruck, Iris, DNA und authentisiert
sich damit beim Onlinedienst.
Zu den drei Methoden der Authentisierung ist neuerdings auch eine vierte hinzugekommen:
Jemand den man kennt
2.4.4
Authentisierung über jemanden, den man kennt (somebody you know)
Der vierte Faktor für eine Authentifizierung wäre die Möglichkeit über jemand den man kennt
[Brainard, Juels, Rivest, Szydlo, & Yung, 2006]. Durch die Popularität der sozialen Netzwerke ist es
auch möglich sich über Bekannten einem Server gegenüber zu identifizieren. Sich über jemanden
identifizieren zu lassen ist sehr alt und kann auf jeder Party vorkommen, wenn man einen Freund
jemanden vorstellt. Möchte sich ein Benutzer auf einem Server authentisieren (Abbildung 18), dann
kann er über einen anderen Kanal (z.B. Telefon) einen Freund kontaktieren (1.) und sich ihm
gegenüber identifizieren (2.). Der Bekannte bestätigt seine Identität und fragt beim Server nach
einem Passwort an (3.). Der Server bestätigt eine Beziehung zwischen den beiden und so erhält der
Bekannte anschließend beispielsweise ein temporäres Passwort (4.), welches er weiterleitet (5.) und
mit dem sich der Benutzer dann einloggen kann (6.).
Eigenschaften dieser Methode wären:
o
o
Ein unabhängiger zweiter Kanal ist notwendig.
Gemeinsames Netzwerk ist notwendig.
20
o Der Server muss die Beziehungen unter den Benutzer kennen.
Abbildung 18: Authentisierung über das soziale Netzwerk: Jemand bestätigt die Identität vom
Besitzer beim Onlinedienst.
Die letzte Methode ist aber eher sinnvoll, wenn man einen verlorenen Account zurückerhalten
möchte oder wenn ein Verdacht besteht, dass der Account gehackt bzw. kompromittiert wurde. Dies
wäre eine Alternative zur Geheimfrage und Antwort, wie man es normalerweise kennt. Für Online
Accounts wären nur die ersten zwei klassischen Methoden interessant und Persönliche Merkmale
wären als Sicherheitssysteme von Geräten sinnvoll. Weitere Formen der Authentisierung wären:



Zwei-Faktor-Authentifizierung: Es werden zwei von den drei unterschiedlichen Methoden zur
Authentisierung benötigt.
Zwei-Kanal-Kommunikation: Es wird ein zweiter unabhängiger Kanal, wie ein Handy, zur
Authentisierung benutzt.
Vier-Augen-Prinzip: Es werden zwei unabhängige Personen zur getrennten Authentisierung
benutzt.
21
Abbildung 19: Methoden der Authentisierung
Eine Methode allein ist meistens nicht sicher genug, da sie fast immer eine Schwachstelle besitzen.
Die drei verschiedenen Methoden könnten daher miteinander kombiniert werden und damit
entsprechend die Sicherheit erhöhen. Durch die Kombinationen der Methoden können aber auch
die Kosten8 erhöht werden.
3 Authentisierungsverfahren
In diesem Kapitel werde ich Authentisierungsverfahren vorstellen, die auf Wissen und Besitz beruhen.
Dabei stelle ich klassische und auch theoretische Authentisierungsverfahren vor. In späteren Kapiteln
werde ich TAN-Verfahren für Online Banking in Authentisierungsverfahren für Online Accounts
umwandeln und darlegen, warum TAN-Verfahren auch für Authentisierungen von Accounts
anwendbar sind und auch weitere Formen der Authentisierung wie Zwei-Wege-Kommunikation oder
Mehrfaktorverfahren vorstellen.
3.1 Wissen
Hier werde ich verschiedene Möglichkeiten vorstellen, wie man sich mit Hilfe von Wissen
authentisieren kann. Das Wissen, was benötigt wird, ist meistens ein Passwort, Kennwort,
Schlüsselwort, Codewort oder Passphrase.
3.1.1
Passwortverfahren
Das Passwortverfahren gehört zu den ältesten Authentisierungsverfahren. Es ist augenscheinlich das
einfachste und billigste Verfahren. Man kann damit schnell einen Account erstellen und die Kosten
für den Benutzer und Administrator/Support sind auf dem ersten Blick auch gering: Man benötigt nur
einen Benutzernamen und einen Passwort.
8
Wie z.B. die Zeit bis man sich eingeloggt hat bzw. Aufwand und Geld, bis man einen Account eingerichtet hat.
22
Ablauf:
Der normale Ablauf ist im Prinzip auch sehr einfach: Der Benutzer übermittelt dem Onlinedienst
seinen Benutzernamen und Passwort. Diese werden vom Onlinedienst mit dem gespeichertem
Passwort in der Datenbank verglichen und ist es korrekt, dann darf sich der Benutzer einloggen.
Abbildung 20: Klartextpasswortübertragung
Mögliche Sicherheitsrisikofaktoren:
Mit diesem Verfahren ist das Ziel des Angreifers das Passwort. Für den Angreifer ergeben sich dabei
verschiedene Angriffsmöglichkeiten, um an das Passwort zu kommen:
Abbildung 21: Sicherheitsrisikofaktoren: Passwort, Benutzer, Übertragung, Speicherung
1. Passwörter:
Passwörter können ein Sicherheitsrisiko sein, wenn sie zu einfach sind. So können einfach zu
merkende Passwörter9 leicht erraten werden. Angreifer können dabei versuchen zufällige
Worte oder Wortfolgen durchzuprobieren. Sind Passwörter aber lang genug und bestehen
aus einer großen Menge von zufälligen Zeichenfolgen, so kann es Brute-Force-Angriffe mit
Wörterbuch-Angriffe erschweren. Darum sollten Passwörter nicht aus einfachen Zeichen9
Wie z.B. Na men oder einfache Wörter.
23
oder Ziffernketten (wie z.B. asdf, 1234) bestehen, da diese schnell durchprobiert werden
können. Empfehlenswerte Passwörter besitzen mindestens 12 Stellen und bestehen aus
möglichst vielen Zeichenarten, d.h. sind alphanumerisch, unterscheiden Groß- und
Kleinschreibung und können Sonderzeichen erkennen. Die frühere Empfehlung von
achtstelligen Passwörtern wurde durch die verbesserte Technik eingeholt [Information zum
Datenschutz, 2011]. Doch solche Maßnahmen schützen nicht vor Brute-Force Angriffe. Sie
verzögern nur die Zeit bis man das Passwort herausfindet. Erhöhen kann man zusätzlich die
Passwortsicherheit, wenn man die Versuche begrenzt, sich auf ein Account einzuloggen oder
regelmäßig das Passwort ändert. Neben dem statischem Passwort, das gleich bleibt, gibt es
auch dynamische Passwörter, die sich verändern.
Begrenzt man die Anzahl der Versuche um auf einen Account mit einem falschen Passwort
einzuloggen auf drei Fehlversuche hintereinander, so ist die Wahrscheinlichkeit, dass man
das Passwort erraten kann:
P= +
*
=
Wobei a die Anzahl der Möglichkeiten für ein Passwort ist und der Angreifer die zwei bzw.
drei benutzten Passwörter nicht nochmal ausprobiert. Besteht z.B. das Passwort nur aus
Ziffern von 0-9 und aus 4 Stellen, so folgt daraus 10 * 10 * 10 * 10 = 10000 Kombinationen10 .
Die Wahrscheinlichkeit das Passwort mit drei Versuchen zu erraten wäre dann P ≈
≈
. Die Wahrscheinlichkeit lässt sich also verringern, wenn man die Möglichkeiten pro
Stelle und die Länge des Passwortes erhöht. So wäre die Wahrscheinlichkeit bei einem 6stelligen alphanummerischem Passwort:
P=
=
≈
Man kann das Risiko der schwachen Passwörter verhindern, indem man schon beim
Einrichten des Accounts den Benutzer zwingt ein sicheres Passwort einzugeben. Der
Benutzer kann dann bestimmte Wörter nicht benutzen, die man z.B. aus einer Tabelle
vergleicht11 . Auch kann man eine Mindestlänge der Zeichenkette auf 12 festlegen. ⇒ R1
wäre gegeben, wenn alle vorher genannten Bedingungen erfüllt sind: Mindestlänge, zufällige
Folge von Symbolen aus einer großen Menge, begrenzte Anzahl von Fehlversuchen und
regelmäßiges Wechseln des Passworts. So kann ein Angreifer keinen erfolgreichen Angriff
starten, da er zu lange braucht. Aber selbst sichere Passwörter sind nicht sicher, wenn
Benutzer selber Ziel von Angriffen sind.
2. Benutzer:
Ein weiterer Sicherheitsrisikofaktor ist der Benutzer selbst. Es ist nicht leicht viele und
wechselnde Passwörter zu merken, vor allem die keine Bedeutung haben, wie z.B.
L&83r%!aD. Besitzt ein Benutzer mehrere Accounts, so kann es schwierig sein, sich alle
Passwörter zu merken. Darum können sie aus einfachen Wörtern bestehen, aus dem sozialen
Kontext bestehen, sehr kurz sein oder man benutzt für verschiedene Accounts das gleiche
Passwort. Der Vorteil ist, der Benutzer kann sie sich dann einfacher merken, der Verlust
durch Vergesslichkeit ist damit geringer und man kann auch Zeit sparen, da ein Benutzer
entsprechend Zeit braucht, sich mit einem Passwort einzuloggen. Durch Social Engineering
kann man den sozialen Kontext herausfinden. Man beobachtet das soziale Umfeld im
Internet über soziale Netzwerke oder findet aufgeschriebene Passwörter am Computer. So
10
11
Also pro Stelle hat man 10 Möglichkeiten
Eine Tabelle, die schwache Passwörter beinhaltet, sozusagen ein Wörterbuch.
24
können Verwandte leicht an solche Passwörter gelangen. Da Passwörter auch kopiert und
weitergegeben werden können, sind sie anfällig für Phishingangriffe. Dabei werden gezielt
die Benutzer angegriffen. Einen sicheren Schutz gegen solche Angriffe gibt es nicht, außer
den gesunden Menschenverstand und Wachsamkeit. So sollte man niemals Passwörter
weitergeben, auch wenn man danach fragen sollte. Mitarbeiter, Administratoren usw. fragen
niemals nach solchen Details. URLs von Homepages und Webformulare sollten genau
überprüft werden, da die Webseiten auch gefälscht sein könnten. Doch durch die
Verlinkungen zu anderen Netzwerken wie das "Like it" Button von Facebook oder die
Möglichkeit sich über andere Webseiten darauf einzuloggen, können dadurch leicht
Phishingseiten erstellt werden, die die Passwörter abhören. Eine alternative wären
Abwandlungen zum klassischen Passwort-Verfahren, wie z.B. das Einmalpasswort-Verfahren,
welches später näher erläutert wird. ⇒ R2 ist nicht gegeben, da Passwörter leicht
weitergegeben werden können und Angreifer ein großen Ideenreichtum an den Tag bringen,
damit Benutzer ihre Passwörter weitergeben.
3. Übertragung:
Eine weitere Angriffsfläche ist die Übertragung des Passworts beginnend mit der Eingabe.
Trojaner12 können die Passwörter während der Eingabe belauschen und weitergeben. Auch
unverschlüsselte Übertragungen und Klartextübertragungen des Passwortes können leicht
abgehört werden. Verschlüsselte Übertragungen können das Abhören verhindern, aber es
wäre immer noch ein Replay Angriff möglich. Dies kann man verhindern, indem man eine
Nonce13 mit überträgt, mit der man erkennen kann, ob man diese Daten schon einmal
verschickt hatte bzw. die nur zeitlich begrenzt gültig ist, wie z.B. eine SessionID.
Um sicherzugehen, dass Übertragungen nicht manipuliert oder abgefangen werden, wie
während eines Man-in-the-Middle Angriffs, können Verfahren wie Challenge-Response
Authentisierung oder Zero-Knowledge-Beweise angewendet werden. Dabei werden die
Passwörter nicht übertragen.
Bei der Challenge-Response Authentisierung kann der Benutzer eine Aufgabe des Servers nur
lösen, wenn er das Passwort kennt. Man kann dies mit dem symmetrischen oder
asymmetrischen Verschlüsselungsverfahren realisieren: Beim symmetrischen Verfahren
sendet der Onlinedienst eine Zufallszahl w an den Benutzer und wird mit einer
Einwegfunktion f und Passwort k verschlüsselt.
c = (w) wird an den Onlinedienst zurückgeschickt und entschlüsselt. Kommt dabei w raus,
dann wurde der Benutzer vom Onlinedienst authentifiziert. Dabei müssen der Benutzer und
der Onlinedienst das Passwort kennen. Der Nachteil ist also, dass beide das Passwort kennen
müssen und es auch eine Angriffsfläche für die Differenzielle Kryptoanalyse14 bieten. Man
kann deshalb auch das Verfahren mit der asymmetrischen Verschlüsselung benutzen, in der
man anstatt eines Passwortes mit zwei arbeitet, mit dem öffentlichen und privaten Schlüssel
des Public-Key Verfahrens. Dabei schickt dann Bob die verschlüsselte Zufallszahl w mit dem
öffentlichen Schlüssel an Alice und die entschlüsselte Antwort mit dem geheimen Schlüssel
wird zurückgeschickt. Dabei muss Bob nicht unbedingt die verschlüsselte Zahl schicken,
sondern nur die Signatur einer Hashfunktion, die von Alice verifiziert wird. Da man aber
12
z.B. Keylogger
Nonce (used onle once) können zufällige Zahlen- oder Buchstabenkombinationen sein, die nach einmaliger
Verwendung verworfen werden (z.B. eine Zufallszahl).
14
Man versucht über Differenzen von Klartextblöcken und Chiffretextblöcken den geheimen Schlüssel
herauszufinden.
13
25
einen öffentlichen Schlüssel benutzt, könnte einem Angreifer dies als Grundlage für ChosenPlaintext-Attack dienen.
Abbildung 22: Challenge-Response Verfahren mit symmetrischer Verschlüsselung
Auch der Zero-Knowledge-Beweis braucht keine Übertragung des Passwortes. Das Konzept
wurde 1985 von Goldwasser, Micali und Rackoff eingeführt. Dabei ähnelt es dem ChallengeResponse Verfahren mit der Public-Key Authentisierung. Der Zero-Knowledge-Beweis ist ein
interaktives Beweissystem, bei dem der Benutzer das Geheimnis15 kennt und der
Onlinedienst nicht. Der Benutzer und der Onlinedienst führen ein Protokoll durch, bei dem
der Benutzer dem Onlinedienst überzeugen kann, dass er das Geheimnis kennt. Ein Hacker
könnte das nicht. Im Grunde geht das über ein Protokoll zwischen den beiden, in der der
Onlinedienst an den Benutzer eine Aufgabe schickt, bei der es zwei Lösungen geben kann.
Die Wahrscheinlichkeit, dass der Benutzer die richtige Antwort schickt, obwohl der Benutzer
das Passwort nicht kennt ist . Wiederholt man also n Mal das Protokoll, so ist die
Wahrscheinlichkeit
groß. So kann man nach n Aufgabenstellungen mit einer
Wahrscheinlichkeit von 1-
sicher gehen, dass der Benutzer tatsächlich der Benutzer ist. Ein
Beispiel wäre das Fiat-Shamir-Verfahren von 1986 [Fiat & Shamir, 2011]. ⇒ R3 ist hier nicht
gegeben, da die Eingabe des Passwortes immer ungeschützt ist und kann durch Keylogger
abgehört werden. Durch einen sicheren PC kann man das Risiko verringern, aber nicht
einfach ausschließen, da immer neuere Computerviren trotz Sicherheitsmaßnahmen wie
Antivirenprogramme auf dem PC gelangen können.
⇒ R4 kann man hier als gegeben ansehen, da die Übermittlung durch eine sicherere
verschlüsselte Verbindung ausreichend Schutz bieten sollte.
4. Speicherort von Passwörtern:
Eine weitere Angriffsmöglichkeit für Angreifer sind die gespeicherten Passwörter selbst. Ein
Angreifer könnte versuchen auf Rechner einzudringen und diese gespeicherten Passwörter
zu klauen. Diese können auf einem Server vom Onlinedienst in einer Datenbank liegen16 oder
15
z.B. das Passwort
Die der Onlinedienst benötigt um feststellen zu können, ob das Passwortabfrage des Benutzers korrekt
beantwortet wurde.
16
26
auch auf dem PC von Benutzer, z.B. bei Browsern mit automatischer Passwortspeicherung.
Liegen die Daten unverschlüsselt vor, so ist es ein großes Sicherheitsproblem, da ein
Angreifer sie stehlen und dann ohne Probleme anwenden kann. Daher sollten
Passwortverzeichnisse vor Zugriff geschützt und verschlüsselt sein. Bereits in den
Unixsystemen wurden daher die Passwörter verschlüsselt abgespeichert. So wird das
Passwort k mit einer Einwegfunktion f in
abgespeichert. Während einer
Authentifizierung wird das gesendete Passwort erneut verschlüsselt und das Ergebnis
verglichen. Versucht ein Hacker ein so verschlüsseltes Passwort herauszufinden, dann
benutzt er die gleiche Methode für sein Brute-Force Angriff17 . Man verwendet dafür oft
Hash-Verfahren wie MD5 oder SHA-512 um die Passwörter kryptographisch zu sichern.
Kryptographisch sichere Hashfunktionen sollten daher stark Kollisionsresistenz18 sein. Starke
Kollisionsresistenz soll dem Geburtstagsparadox und die damit verbundene
Geburtstagsattacke19 verhindern. Da man aber dafür die Existenz von Einwegfunktionen
voraussetzt und sowas noch nicht bewiesen wurde, ist es immer noch fraglich, ob die zurzeit
benutzten Hash-Verfahren sicher sind. Bisher konnte man aber diese Verfahren noch nicht
brechen. Da jedoch die Technik besser geworden ist, sind ältere Hashfunktionen wie MD5,
die für schnelle Verarbeitung optimiert wurde, nicht mehr sicher genug. So können
achtstellige Passwörter innerhalb von 4 Tagen geknackt werden. Und schwache Passwörter
kann man mit Hilfe von Wörterbuchangriffen innerhalb von Stunden ermitteln. Um eine
schnelle Entschlüsselung durch einfache Passwörter zu vermeiden, können die Passwörter
mit Salt- und Key-Stretching-Verfahren oder deren Kombination verlängert werden. Man
könnte die Berechnung eines Passworts von einer Mikrosekunde auf eine Millisekunde
verlangsamen, dann würde es dem Benutzer kaum auffallen. Dies dient nur als ein
Bremsfaktor und nicht zur Erhöhung der Sicherheit eines Passworts. Aber die Verlangsamung
um den Faktor 1000 würde den Hacker die Zeit für die Suche nach dem Passwort stark
erhöhen. Würde er z.B. statt 100 Millionen Passwörter pro Sekunde nur 100000 Passwörter
pro Sekunde durchprobieren können, dann würde der Hacker für das Passwort "P4ssW0r7"
48 Jahre anstatt 18 Tage brauchen. So wird beim Salt-Verfahren einfach zufällige
Zeichenfolgen dem Passwort angehängt. Die können auch mit der Hashfunktion verschlüsselt
werden und im Klartext mit abgespeichert sein, da der Sinn nur darin besteht, dass der
Angreifer ein langes Passwort überprüfen muss. Beim Key-Stretching, welches z.B. AES
benutzt um einen 256 Bit Schlüssel zu verlängern, wird das Passwort mehrere Runden durch
einen Hash-Algorithmus geschickt. Das Standardverfahren dazu nennt man PBKDF220. WPAPSK Schlüssel bei WLANs verwenden dieses Verfahren [Bachfeld, 2011].
Eine weitere Gefahrenquelle ist zudem die bequeme Speicherung von Passwörtern über dem
Browser21. Personen, die Zugriff auf dem Computer haben22 , können da dann leicht Zugang
zu den Accounts erlangen. Der Benutzer sollte sich auch immer ausloggen, da ansonsten die
Gefahr besteht, dass man eingeloggt bleibt und man später immer noch Zugriff auf den
17
Der Angreifer verschlüsselt dabei auch seine durchzuprobierenden Passwörter und vergleicht dann die
verschlüsselten Daten miteinander, ob sie gleich sind.
18
Kollisionsresistenz bedeutet, dass man nicht mit einem anderen Passwort den gleichen Hash berechnen kann.
19
Man versucht dabei die Kollision (Geburtstagsparadoxon) auszunutzen und den gleichen Hashwert mit zwei
unterschiedlichen Dokumenten zu finden.
20
Password-Based-Key Derivation Function 2
21
Wie z.B. der Passwort Manager von Mozilla Firefox.
22
Oft sind es die eigenen Verwandten oder Freunde.
27
Account hat23. Man kann dies Serverseitig begegnen, wenn man Sessionzeiten begrenzt und
den Benutzer nach 5 Minuten automatisch ausloggt24. Probleme kann es aber mit sozialen
Netzwerken geben, wenn sie dort auf angezeigte Links gehen und sich dann nicht
ausloggen25. Unbemerkt installierter Schadsoftware können so Informationen ausspähen.
⇒ R4 sollte wie in den meisten Fällen als vorausgesetzt ansehen. Man sollte den Onlinedienst
dementsprechend vertrauen können. Da man aber viele Accounts von verschiedenen
Onlinediensten hat, ist hier natürlich auch ein erhöhtes Risiko, dass ein Anbieter die Daten
nicht sicher aufbewahrt bzw. weitergibt. Setzt man aber für jeden Dienst ein anderes
Passwort ein, dann kann man den Schaden begrenzen, falls ein Dienst kompromittiert
werden sollte.
Kosten eines Passwortsystems:
Wenn man die Kosten eines Authentisierungs-Verfahren anschauen möchte, dann sollte man da den
Zeitfaktor, Geldfaktor und die Benutzerfreundlichkeit/Aufwand gegenüber dem Verbraucher und
Bereitsteller betrachten.
Benutzerfreundlichkeit/Aufwand:
Auf den ersten Blick ist das Authentisierungsverfahren mit einem Passwort einfach und unkompliziert.
Das gilt für die erstmalige Einrichtung als auch für die tägliche Nutzung aus der Sicht des Anwenders
und des Bereitstellers. Doch für die Bequemlichkeit opfert man oft die Sicherheit. Je nach
Sicherheitsgrad sind Schulungen und Bewusstseinsbildung für sicheres Verhalten und Passwörter [BSI,
2008] notwendig. So muss man nicht nur Richtlinien und Regeln aufstellen, sondern sie auch
überprüfen, ein sicheres Design der Lösung erstellen, Administratoren und Supportkosten beachten
usw. Möchte man also das System sicherer machen, dann muss man bei statischen Passwörtern
regelmäßig das Passwort ändern. Zusätzlich dürfen die Passworte sich dann nicht ähneln und müssen
sicher gelten. Diese sind dann schwer zu merken und der Aufwand wird höher. Nicht nur für den
Verbraucher, sondern auch der Bereitsteller muss einen höheren Aufwand betreiben. Sie müssen
geschult werden dürfen nicht nur die Standardeinstellungen verwenden, die meistens unsicher sind,
sondern zusätzliche Sicherungen wie verschlüsselte Passwortspeicherung, Übertragung,
Zertifizierung usw. hinzufügen. Regelmäßige Änderungen von Passwörtern in kurzen Zeitabständen
bei mehreren Accounts, die sich nicht gleichen dürfen, können den Benutzer auch Probleme bereiten.
Vor allem, wenn die Passwörter durch den Bereitsteller überprüft und unsicher geltende abgelehnt
werden. So wird durch die Erhöhung der Accountsicherheit die Benutzerfreundlichkeit stark
geschmälert. Der Aufwand für einen sicheren Umgang mit vielen Passwörtern steigt dann
exponentiell [Cryptas, 2011].
Zeitfaktor:
Neben dem Einloggen auf ein Account kann auch die Wartung entsprechend Zeit kosten. Bei
entsprechend vielen Accounts und sicheren Passwörtern kann der Benutzer einige Zeit verwenden
sich täglich einzuloggen. Als Vergleich sind Mitarbeiter laut Meta Group Research täglich 16 Minuten
lang beschäftigt sich auf verschiedene Systeme einzuloggen (bei durchschnittlich 27 verschiedenen
Zugriffsberechtigungen und davon 73 Prozent Passwortgeschützt). Auch Administratoren und
23
Gefährlich kann es vor allem sein, wenn man in einem öffentlichen Internetcafé ist und sich nicht ausloggt
oder das Passwort gespeichert wird.
24
Wobei es dann nerven kann, wenn man sich alle 5 Minuten neu einloggen kann.
25
So speichert z.B. Facebook Cookies, die zwei Jahre gültig sind [Schmidt, 2011].
28
Support können viel Zeit verbrauchen um verlorene Passwörter und somit Accounts
wiederherzustellen. So sind 45% von Help-Desk Anfragen Passwortzurücksetzungen [Ohlhorst, 2004].
Kostenbereich TCO26 (Total Cost of Ownership) [Cryptas, 2011]:
Kosten für Passwortsysteme können je nach zusätzliche Maßnahmen variieren. Bei den "Standard" Challenge-Response Einzelsystemen können durch Absicherungsmaßnahmen des Bereitstellers
(serverseitig) die Kosten für Administratoren, Support und andere organisationsseitige Maßnahmen
steigen. Bei den aufwendigeren passwortbasierenden Single Sign-On (SSO) Lösungen werden
hauptsächlich die Anlauf- und Integrationskosten teurer.

Für den Benutzer fallen normalerweise keine zusätzlichen Kosten ein. Denkbar wären:
Passwortspeicherung, Backup, Recovery, Wartung, Support, Lizenzen
 Onlinedienst: Authentication-Datenbank, Lizenzen, Wartung, Support, SSL-Zertifikate
o Serverhardware: Server, eventuell HSM (Hierachical Storage Management) Systeme
Auch können zusätzliche Kosten auf den Dienstanbieter hinzukommen, die aber auch für alle
Authentisierungsverfahren gelten können und ich sie daher nur einmal hier kurz aufliste.
 Einrichtungskosten:
o sicherer laufender Betrieb: physischer Schutz, Redundanz, Backup
 Katastrophenschutz: Disaster Recovery Vorsorge
 Kernteamkosten: Projektmanager, Securitymanager, Anwendungsarchitekt, Administratoren
 erweitertes Teamkosten: Netzwerktechniker, Servertechniker, Helpdesk,
Schulungsverantwortliche, Anwendungsentwickler, Anwendungsverantwortliche
 Vorbereitungskosten: Schulung Kernteam, validieren, Passwortpolicy, "Secure Desktop
Richtlinie"
 Planungskosten: Projektpläne, Betrieb- und Supportplan, Pilot- und Einsatzplan, ChangeManagement
 Designkosten: Zertifikatsarchitektur, PKI-Server-Architektur (Public Key Infrastruktur),
Enrollment, Anwendungsintegration, Support, Evaluierung und Testinfrastruktur
 Entwicklungskosten: Serverinstallation und -integration, Benutzerbank,
Anwendungsentwicklung, Anwendungstest und Installation, Entwicklung von
Administrations-, Supportprozessen
 Einsatz: Endbenutzer-Schulung und Bewusstseinsbildung
Account Recovery:
Für jedes Authentisierungsverfahren muss es auch eine Absicherung geben, falls man den Zugriff auf
den Account verlieren sollte. Dabei muss sich dann der Benutzer anderweitig authentisieren. Neben
dem klassischen Kundensupport, den man meistens telefonisch oder per E-Mail erreichen kann, gibt
es noch andere (automatisierte) Möglichkeiten. Dabei können Passwörter im klassischen Sinne nicht
verloren gehen, aber man kann sie vergessen. Eine Passwortzurücksetzung wäre eine Möglichkeit.
Dabei wird ein neues Passwort automatisch erstellt und dem Benutzer per E-Mail, Post, SMS oder
telefonisch mitgeteilt. Meist muss er sich dann dabei mit einer Antwort auf eine Geheimfrage
authentifizieren. Die Geheimfrage27, eine E-Mail28 oder Handynummer muss er bei der Erstellung des
26
Die anfallenden Kosten können aber auch für alle anderen Authentisierungsverfahren gelten. Man sollte das
immer im Hinterkopf haben und ich werde sie später daher nicht noch einmal vortragen.
27
Meist bestehen die Fragen aus dem persönlichen Umfeld wir die Lieblingsfarbe oder Mädchenname der
Mutter.
29
Accounts vorher angegeben haben. Der Vorteil ist, dass man automatisiert und einfach ein neues
Passwort erstellen kann. Der Nachteil von Geheimfragen ist aber, dass man auch diese vergessen
kann. Vor allem bei einfachen Standardfragen wie die Lieblingsfarbe, die sich mitunter nach ein paar
Jahren ändern kann oder man sich einfach nicht mehr an die Antwort erinnert, da man irgendwas
angegeben hatte. Auch sind sie nicht sicher gegenüber Phishingversuchen, Brute -Force Angriffen usw.
Account Recovery Verfahren könnten deshalb auch Ziele von Hackerangriffen sein. Sollte die
Passwortzurücksetzung nicht funktionieren, wenn z.B. auch die Sicherheitsfrage vergessen wurde,
die E-Mail Adresse oder Handynummer nicht mehr aktiv ist, dann wäre die letzte Möglichkeit, wenn
der Benutzer sich direkt mit dem Accountsupport in Verbindung setzt. Das kann telefonisch oder per
E-Mail sei. Dabei kann sich der Benutzer mit einer Ausweiskopie identifizieren und das neue Passwort
mit einem Brief über den Postweg verschicken.
Neben dem klassischen Passwortverfahren gibt es noch verschiedene Varianten, auf die ich nun
näher eingehen werde.
3.1.2
PIN-Verfahren
Die Persönliche Identifikationsnummer oder Geheimzahl besteht aus einem Passwort bestehend nur
aus Ziffern.
Ablauf:
Der Ablauf ist entsprechend dem des Passwort-Verfahren. Der Benutzer authentisiert sich aber
anstatt eines alphanumerischen Passwortes mit seinem Benutzernamen und seiner PIN.
Die Sicherheitsrisiken R1-R5 entsprechen dem des oben beschriebenen Passwort-Verfahren.
Zusätzlich müssen dazu aber auch verschärfte Sicherheitsregeln für R1 gelten, da eine PIN nur aus
Ziffern besteht und somit nur zehn Zeichen besitzt. Das Bundesamt für Sicherheit in der
Informationstechnik empfiehlt dabei eine Mindestlänge von 6 Stellen und eine begrenzte Anzahl von
Fehlversuchen, bei der danach der Zugang gesperrt wird [BSI, 2008]. Die Möglichkeiten für die
Menge von verschiedenen sicheren PINs verringern sich zudem, wenn man nur zufällige Abfolgen
von Zeichen akzeptiert und "0000" oder "1234" usw. vermeidet.
Kosten eines PIN-Verfahren:
Die Benutzerfreundlichkeit ist vergleichbar dem eines Passwort-Verfahren.
Zeitfaktor:
Die zufällig generierte Geheimzahl wird oft mit der Post verschickt. Damit könnte man sichergehen
wollen, dass nur der adressierte Empfänger die persönliche Geheimzahl erhält und das sie tatsächlich
zufällig ist und kein Geburtstag, Telefonnummer usw. Damit wäre für die Erstellung des Accounts der
Zeitfaktor etwas höher, da man einen Tag oder mehr warten muss, bis die PIN ankommt. Aber auch
beim Passwort-Verfahren könnte man so die Passwörter zustellen.
TCO:
Neben dem TCO vom Passwort-Verfahren können zusätzliche Kosten bei der Einrichtung durch das
PIN-Verfahren entstehen:
28
Eine zweite alternative E-Mailadresse.
30


Beim Benutzer entstehen normalerweise keine zusätzlichen Kosten, außer er muss für die
Papier-, Druck-, Umschlag und Portogebühren aufkommen.
Für den Onlinedienst kommen zusätzlich noch Kosten für den Druck und den Versand der PIN
Nummern hinzu. Zusätzlich benötigt man Server und Softwarekomponenten für die zufällige
PIN Generierung.
Account Recovery:
Als zusätzliche Möglichkeit zur Accountwiederherstellung bei vergessenem oder blockiertem PIN
wäre die PUK (Personal Unblocking Key), eine zweite persönliche Geheimnummer mit der man
Zugang erlangen kann. Die müsste man zusammen mit der PIN vom Onlinedienst erhalten haben.
Ansonsten könnten auch die sonstigen Accountwiederherstellungsmöglichkeiten des PasswortVerfahren gelten.
3.1.3
indizierte PIN-Verfahren (iPIN)
Eine Variante des PIN-Verfahren, um Keylogger die Arbeit zu erschweren, ist es, beim Einloggen nicht
die komplette PIN zu verlangen, sondern nur zufällig bestimmte Stellen des PINs. Die PINs sind also
indiziert.
Ablauf:
Der Ablauf ist ähnlich dem PIN- oder Passwort-Verfahren. Der Benutzer muss dabei beim
Onlinedienst seinen Benutzernamen und PIN eingeben. Bei der Abfrage des PINs wird jedoch nicht
die vollständige Geheimnummer verlangt. So fragt man z.B. bei einem sechsstelligen PIN nur die 3., 4.
und 5. Stelle ab, die man eingeben muss (Abbildung 23). Die Stellen, die man eingeben muss ändert
sich dabei ständig beim jedem Einloggen auf dem Account.
Abbildung 23: Beispiel eines iPIN-Verfahrens bei der Bank of Ireland
Die Sicherheitsrisiken R1, R2, R4 und R5 sind auch hier dem des Passwort-Verfahren ähnlich. Dabei ist
die Sicherheit bei R3 im Falle der Eingabe etwas höher. Keylogger hätten nicht die Möglichkeit beim
ersten Mal die vollständige PIN zu erfahren.
Kosten eines iPIN-Verfahren:
Die Kosten wären ähnlich dem des PIN-Verfahren.
Der Benutzer die Stellen seiner PIN eingeben, was bei langen PINs das Abzählen der Stellen
erschweren kann.
Zeitfaktor:
Die Einrichtungszeit des Accounts ist vergleichbar mit dem PIN-Verfahren und man müsste mit dem
Einloggen des Accounts solange warten, bis der Brief mit der PIN eingetroffen ist. Die Eingabe der
indizierten PIN könnte genau solange dauern wie der einer vollständigen PIN, da man zwar weniger
31
eingeben, aber die entsprechende PIN abzählen muss, was bei manchen Benutzern es komplizierter
erscheinen könnte.
TCO:
Für den Benutzer sollte sich nichts verändern und vergleichbar mit dem PIN- bzw. PasswortVerfahren sein. Der Onlinedienst jedoch benötigt wohl eine zusätzliche Funktion, die die zufällige
Stelle der PIN abfragt und vergleicht.
Account Revovery:
Die Methoden zur Wiederherstellung des Accounts bei gesperrtem oder vergessenem PIN sind auch
hier mit dem PIN-Verfahren vergleichbar.
3.1.4
Sicherheitsfrage
Eine weitere Möglichkeit einer Authentisierung wäre die Antwort auf eine Frage. Dabei muss der
Benutzer üblicherweise auf eine vorher bestimmte Frage aus dem persönlichen Leben die richtige
Antwort geben. Ein Grund für persönliche Fragen wie Name der Grundschule, Mädchenname der
Mutter usw. ist, dass man damit die Benutzerfreundlichkeit erhöhen möchte. Diese Antworten sind
leichter zu merken.
Ablauf:
Der Login Ablauf ist mit dem des Passwort-Verfahren ähnlich. Man kann dabei aber dynamische
Passwörter benutzen. Der Benutzer muss beim Einrichten des Accounts eine schon vordefinierte
Frage beantworten. Diese Antwort entspricht dann dem Passworts. So können mehrere Fragen und
Antworten eingerichtet werden. Hat er den Account eingerichtet, dann muss er sein Benutzernamen
und die Sicherheitsfrage, die auf dem Bildschirm erscheint, eingeben (Abbildung 24).
Abbildung 24: Beispiel eines Logins über eine Geheimfrage bei der Bank of Ireland 29
Die Sicherheitsrisiken R2-R5 ist denen des Passwort-Verfahren vergleichbar. Je nach Frage und
Antwort kann man kein sicheres Passwort verwenden. Sie können recht kurz sein und es sind keine
zufälligen Abfolgen von Zeichen. So sind sie anfälliger vor Wörterbuchangriffen. Und man kann die
Antworten durch Social Engineering erraten oder mit Spear Phishing herausfinden. So ist R1 im
Vergleich zum Passwortverfahren unsicherer, da man eine Antwort als Passwort einfacher
herausfinden kann.
Kosten der Sicherheitsfrage:
Die Kosten sind vergleichbar dem eines Passwort-Verfahren. Benutzerfreundlichkeit/Aufwand:
Die Einrichtung kann länger dauern, da er mehrere Fragen auswählen kann und die Antworten
angeben muss.
29
https://www.365online.com/banking.htm
32
Zeitfaktor:
Die Zeit um sich einzuloggen sollte mit dem Passwort-Verfahren vergleichbar sein.
TCO:
Für den Benutzer sollten keine erhöhten Kosten aufkommen. Aber für den Onlinedienst könnten
vielleicht ein erhöhter Aufwand für Passwortspeicherung und Verwaltung aufkommen, da er im
Vergleich zum Passwort-Verfahren nun mehrere Passwörter speichern und verwalten muss.
Account Recovery:
Wie beim Passwort-Verfahren lässt sich die Antwort auf die Geheimfrage per E-Mail/SMS/Post
zuschicken. Der Nachteil bei elektronischer Versendung ist, dass diese bei unverschlüsselter
Übertragung ausgespäht werden kann. Das Problem ergibt sich, falls die Geheimfrage kompromittiert
wurde. Demnach erhöht sich der Arbeitsaufwand von Administratoren, da sie neue Geheimfragen
erstellen oder der Benutzer Antworten auf Geheimfragen erfinden müssten. Damit wird der Sinn von
persönlichen Fragen in Frage gestellt, da man erfundene Antworten leichter vergessen kann.
3.1.5
Zwei-Schritte Abfrage durch Kombination mit verschiedenen Passwort-Verfahren
Es gibt einige Accounts, die versuchen die Sicherheit durch Kombinationen von verschiedenen
Passwortverfahren zu erhöhen. Anstatt also nur nach einem Passwort zu fragen, benötigt man zwei
verschiedene, wie z.B. bei der Bank of Ireland oder Jefferson Payroll Ltd. Es ist eine Zwei-Schritte
Authentisierung und im Unterschied einer Zwei-Faktor-Authentifizierung werden nicht zwei
verschiedene Methoden, wie Wissen und Haben kombiniert. In diesem Fall werden nur verschiedene
Arten von Passwörtern benutzt.
Ablauf:
Eine Möglichkeit wäre, wenn der Benutzer sich zuerst mit seiner Benutzer ID und einem Passwort
authentisiert. Danach wird noch zusätzlich eine Geheimfrage verlangt. Dabei wäre das Passwort
statisch und die Geheimfrage würde zufällig aus einer Reihe von Geheimfragen ausgewählt.
Eine andere Möglichkeit wäre, wenn sich der Benutzer mit einer zufälligen Geheimfrage im ersten
Schritt authentisieren und danach dann eine PIN eingeben muss. Es kann sich dabei auch nur um
zufällig ausgewählte Stellen einer PIN handeln (Abbildung 25).
Abbildung 25: Beispiel einer Zwei-Schritte Authentisierung bei der Bank of Ireland 30
Man versucht die Sicherheit zu erhöhen und Sicherheitsrisiken zu verkleinern, indem man
verschiedene Passwort-Verfahren kombiniert. Dies wird auch in der Kryptologie angewandt, um
Sicherheiten zu erhöhen, wie z.B. beim 3DES. Leider erhöht man dabei die Sicherheit nicht in dem
30
https://www.365online.com/banking.htm
33
Maße, sodass bekannte Sicherheitslücken geschlossen werden. Sie sind immer noch anfällig auf
bekannte Angriffsarten wie Trojaner und Phishing-Angriffen. Es wird nur das Auffinden von
Passwörtern erschwert. Man kann aber immer noch die Schwächen des oben beschriebenen
Passwort-Verfahren ausnutzen. Allgemein lässt sich die Sicherheit erhöhen, wenn man zusätzlich die
Anzahl der Fehlversuche begrenzt. So ist für R2, R4 und R5 die Sicherheit ähnlich hoch wie beim
Passwortverfahren. Gegenüber R1 und R3 ist die Sicherheit leicht erhöht, da der Angreifer etwas
länger braucht um das Passwort herauszufinden. Es kann aber nicht verhindert werden.
Kosten einer Zwei-Schritte Authentisierung:
Die Kosten können sich entsprechend den verschiedenen zusätzlichen Passwortverfahren addieren.
Der Benutzer muss sich verschiedene und mehrere Passwörter für eine einmalige Anmeldung
merken und benutzen.
Zeitfaktor:
Die Anmeldezeit erhöht sich entsprechend, da der Benutzer nun mehrere verschiedene Passwörter
eingeben muss.
TCO:
Die Kosten erhöhen sich gegenüberPasswortverfahren für den Onlinedienst in dem Maße, dass man
entsprechend mehrere Passwörter verwalten und abspeichern muss. Je nach Passwort-Verfahren
müssen zusätzliche Funktionen eingerichtet und verwaltet werden. Für den Benutzer dürften keine
Mehrkosten wie beim PIN-Verfahren zukommen.
Account Recovery:
Verliert oder vergisst der Benutzer die PIN oder die Geheimantwort, so kann er seinen Account wie
bei den oben beschriebenen Verfahren wiederherstellen lassen.
3.1.6
Einmalpasswörter
Die sichersten Passwörter, die man benutzen kann, sind Einmalpasswörter. Beim EinmalpasswortVerfahren werden die dynamischen Passwörter nach der einmaligen Benutzung ungültig und
ausgewechselt. Dies bringt große Sicherheit gegenüber Trojaner und Replay-Angriffen. Sie können
die Passwörter abfangen, aber nicht mehr benutzen. Gegen Man-in-the-Middle Angriffen sind
Einmalpasswörter aber nicht sicher. Diese könnten vor der Benutzung abgefangen und dann vom
Angreifer eingesetzt werden. Da die Passwörter nach einmaligem Gebrauch ungültig sind, benötigt
man eine Menge von Passwörtern auf Vorrat. Das geht entweder über eine vorher erstellte
Passwortliste (z.B. über einen Pseudozufallsgenerator hergestellte Liste von mehrstelligen PINs) oder
einem Passwortgenerator. Da man für Einmalpasswörter etwas besitzen muss, sei es eine Liste oder
ein Token, werde ich sie in späteren Kapiteln beim Besitzfaktor vorstellen und hier nicht näher auf sie
eingehen.
3.1.7
Fazit Wissen
Die auf Wissen basierenden Authentisierungsverfahren basieren alle auf Passwörter bzw.
Codewörter, die nur der Benutzer und der Onlinedienst kennen sollten. Sie unterscheiden sich im
Prinzip nur voneinander, wie ein Passwort zusammengesetzt ist.: Es kann aus einem Wort, Satz,
Alphanumerisch, nur aus Zahlen, unterschiedliche Längen usw. bestehen.
34
Abbildung 26: Beziehungen zwischen Authentisierungsverfahren basierend auf Wissen
Neben den unterschiedlichen Arten des Passwortes unterscheiden sich die Verfahren durch die
Abfrage. So sollen die unterschiedlichen Abfragemethoden bestimmte Angriffe, z.B. durch Trojaner,
erschweren. Dabei kann man also entweder mehrere Passwörter zufällig abfragen oder nur
bestimmten Stellen eines Passwortes. Auch eine zweistufige Abfrage, in der man verschiedene
Verfahren hintereinander anwendet, sollen Angriffe erschweren. Aber jedes noch so modifiziertes
Verfahren kann die Angriffe nicht verhindern. Neben Trojaner, die immer noch Passwörter
belauschen können, auch wenn es vielleicht etwas länger dauern kann, bis man das Passwort hat,
können mit Phishingmethoden Passwörter geklaut werden. Dabei kann das Passwort auch noch so
sicher wie möglich sein, gegen solche Angriffe sind sie wehrlos. Der große Vorteil ist jedoch, dass
man keine technischen Hilfsmittel braucht. Man merkt sich einfach das Wissen und schon kann man
sich authentisieren.
Gemeinsamkeiten:

Basieren auf Passwörter
Unterschiede:


Abfragemethode
Bestandteil eines Passworts:
o Zahlen
o Alphanumerisch
o Wörter
o Sätze
Nur auf Wissen basierende Verfahren schützen nicht gegen weit verbreitete Angriffsmethoden:


Phishing
Trojaner
35
3.2 Besitz
Im Folgenden werde ich verschiedene Verfahren vorstellen, die auf Besitz basieren. Der Benutzer
kann sich also nur auf ein Account erfolgreich einloggen, wenn er erfolgreich nachweisen kann, dass
er etwas besitzt, was nur er haben kann. Die ältesten Verfahren basieren auf dynamische Passwörter.
Dabei ist das Passwort nur einmal gültig und erhöht somit die Sicherheit. Da man aber für
mehrmaliges Einloggen eine Menge Passwörter braucht31, muss man daher eine Liste oder einen
Passwortgenerator besitzen, die nur für einen Besitzer gültig ist. Beispiele dafür werde ich später
auch bei Onlinebankingverfahren vorstellen. Aber mit fortgeschrittener Technik könnten auch neue
Möglichkeiten der Online Authentisierung gefunden werden, die ich auch noch vorstellen werde.
3.2.1
RSA SecurID Token32
RSA SecurID Token stammen von RSA Security und sind als Schlüsselanhänger erhältlich, die alle 60
Sekunden eine wechselnde sechs- bis achtstellige Zahl anzeigt (sogenannte OTP - One-TimePassword). Das RSA SecurID Token ist zeitgesteuert und das OTP berechnet sich aus einem Zeitindex
und einem geheimen Schlüssel der Länge 128 Bit aus dem jeweiligen Token. Der Schlüssel für jeden
einzelnen Token wird durch einen Zufallszahlgenerator erstellt und ist nur dem Authentication
Manager bekannt. Ein Token hat eine begrenzte Lebensdauer und schaltet sich zwischen einem und
fünf Jahre ab. Das Ablaufdatum befindet sich auf der Rückseite des Tokens. Als Beispiel für
Anmeldungen auf Webseiten oder Onlinespiele könnte man Blizzard Entertainment erwähnen. RSA
SecurID Tokens sind zeitbasiert und sie haben eine Uhr, die synchron mit dem vom
Authentifizierungsserver läuft. Damit Abweichungen abgefangen werden, sind meist der vorherige
und der nächste Code eine Zeitlang noch gültig. Die Lebensdauer ist zwischen ein und fünf Jahren
begrenzt und abhängig von der Batterielebensdauer. Ein Verfallsdatum ist auf der rückwertigen Seite
eingeprägt [SecurID, 2011]. Es stehen auch Apps für Smartphones wie IPhone und Android Handys
zur Verfügung, so dass es nicht nötig ist einen Token zu besorgen.
Abbildung 27: RSA SecurID 700 Token und Battle.Net Authenticator von Blizzard
31
32
Die ein normaler Mensch normalerweisen nicht alle merken kann.
http://germany.rsa.com
36
Ablauf:
Abbildung 28: Möglicher Authentisierungsablauf mit RSA Token
Als Voraussetzung besitzt der Benutzer bereits den RSA SecurID Token und hat ihn über seine
Accountverwaltung registriert.
1. Der Benutzer meldet sich mit einem Benutzernamen und einem Passwort auf dem
Onlinedienst an.
2. Danach wird er nach aufgefordert den Einmalpasswort des RSA SecurID Tokens einzugeben.
Der Benutzer aktiviert den RSA SecurID Token und tippt den dort erscheinenden Code in das
Eingabefenster auf der Webseite ein.
3. Dafür hat er 30 Sekunden bis eine Minute Zeit, dann wechselt der Code und der alte ist
ungültig. Die Uhr des Tokens läuft dabei synchron mit der Uhr des Onlinedienstes.
4. Der Onlinedienst überprüft den Code und ist er korrekt, dann lässt der Dienst den Benutze r
auf sein Account zugreifen.
Abbildung 29: Mögliche Angriffsziele während einer Anmeldung mit einem RSA Token
1. R1 kann als gegeben angesehen werden, da die generierten Einmalpasswörter schon sicher
genug generiert werden (z.B. bezüglich Länge und Ziffernfolge).
37
2. Phishingversuche gegenüber dem Benutzer sind kaum möglich, da die generierten Codes nur
maximal eine Minute lang gültig sind. Der Angreifer müsste da schon versuchen den RSA SecurID
Token in den Besitz zu gelangen. ⇒ R2 gilt.
3. Auch Trojaner haben können kaum was mit abgehörten Codes anfangen, da sie nach einer
Minute abgelaufen sind. So sind Keylogger hier praktisch nutzlos. ⇒ R3 gilt.
4. Man-in-the-Middle/XSS Angriffe wären möglich, wo man den Benutzer auf eine falsche Webseite
führt um den Code abzufangen. Diese müsste aber dann zeitnah eingesetzt werden und dem
Benutzer kann man versuchen mit einer falschen Fehlermeldung, dass z.B. die Webseite gerade
Offline für Wartungsarbeiten ist und er sie in 30 Minuten später einfach nochmal versuchen soll.
⇒ R4 kann als ausreichend gesichert gelten, da man einen hohen Aufwand benötigt.
5. Benutzt man keinen autarken Token, sondern ein Smartphone über das ein App läuft, der den
Code ermittelt, dann könnten Viren für Smartphone Handys diese abfangen und dem Angre ifer
übermitteln. ⇒ R5 gilt, da solche Angriffe noch zu teuer (Kosten/Nutzen Verhältnis) für einen
Angreifer sind.
Kosten des RSA SercurID Token:
Benutzerfreundlichkeit:
Der Aufwand für den Benutzer den Account einzurichten oder sich darauf einzuloggen erhöht sich
insofern, dass er seinen Benutzernamen und Code nicht sofort eingeben kann, sondern vorher den
Token herausholen und dann den Code generieren muss. Auch kann er sich nicht einloggen, falls er
seinen Token vergessen sollte. Er kann sich aber mit dem Token überall einloggen und ist nicht auf
bestimmte Rechner eingeschränkt. Dafür muss er den Token immer bei sich haben. Mit der
Einführung von Smartphones und den sogenannten Apps, sind nun auch Tokens in Softwareform
verfügbar, die auf Handys laufen können. Benutzt man einen App für ein Handy, dann ist es einfacher
und unauffälliger, da man ein Handy normalerweise immer mit sich führt. Für Handybesitzer gilt
jedoch, dass man die Uhrzeit entsprechend der Winter- und Sommerzeit aktualisiert, da ansonsten
die Synchronisation mit dem Server nicht mehr stimmt.
Zeitfaktor:
Im Vergleich zum Passwortverfahren verlängert sich normalerweise die Loginphase, da er erst den
Token bereitstellen und dann einen längeren unbekannten Code eingeben muss.
TCO:


Der Benutzer muss sich einen Token kaufen oder ein Smartphone besitzen, der die Apps
unterstützt. Falls der Benutzer einen Token kaufen sollte, dann muss er den Token zwischen
einem und fünf Jahren auswechseln, wenn die Batterie leer ist.
Der Onlinedienst muss entsprechend die Tokens oder die Apps bereitstellen und eine OTPInfrastruktur (z.B. passende Serverkomponente) besitzen.
Account Recovery:
Sollte der Benutzer seinen Token verloren haben, dann muss er diesen sperren bzw. von seinem
Account entfernen lassen. Das geht entweder, wenn er sich mit einer z.B. elektronisch mit einer
Sicherheitsfrage authentisiert oder telefonisch bzw. direkt Kontakt aufnimmt. Er muss sich dann
einen neuen Token kaufen oder falls er sein Smartphone verloren hat, den App auf sein neues
Smartphone erneut installieren und registrieren.
38
3.2.2
USB-Device
USB-Sticks können auch zur Authentisierung benutzt werden, die in zwei unterschiedlichen Arten
eingesetzt werden können:
1. USB-Stick mit gehärtetem Browser und Zertifikat:
Der USB-Stick ist schreibgeschützt und es befindet sich ein Browser darauf, den man starten kann
und der sich direkt mit dem Onlinedienst verbindet. Zusätzlich erhält der USB-Stick ein
persönliches Zertifikat, das vom Onlinedienst oder einer Zertifizierungsstelle ausgestellt wurde.
Der USB-Stick soll gegen Malware (Manipulationen) schützen und dient als 2. Faktor in
Verbindung mit einem Passwort oder PIN.
2. USB-Token:
Ein USB-Token wird hier als passives Medium eingesetzt, der die Chipkarte und das Lesegerät
vereint und somit wie HBCI-1 Verfahren arbeiten soll. So wird der USB-Token für die TAN
Erstellung benutzt, wie ich sie später beim HBCI Verfahren weiter erläutere.
Die Sicherheit ist vergleichbar mit denen von HBCI-1 oder eTAN-Plus Verfahren (⇒ R1-R5 gilt), die ich
später noch näher vorstellen werde. Falsche Zertifikate könnten dabei Ansätze für Man-in-theMiddle Angriffe sein. Bei Diebstahl des USB Sticks hätte der Angreifer möglicherweise den
kompletten Zugriff, sollte der nicht mit einem Passwort oder PIN geschützt sein.
Kosten des USB-Stick:
Benutzerfreundlichkeit/Zeit:
Man kann den USB-Stick überall mitnehmen und benötigt nur einen Rechner mit USB Zugang. Es
könnte aber je nach Betriebssystem Probleme mit der Erkennung des USB-Sticks geben. Ansonsten
wäre der Vorgang mit dem USB Stick nicht länger als mit dem HBCI Verfahren.
TCO:

Der Benutzer müsste sich zusätzlich ein USB Stick anschaffen und bezahlen, falls der
Onlineprovider die Kosten nicht übernehmen sollte.
 Der Onlineprovider müsste die USB-Sticks bereitstellen und die dafür nötige Infrastruktur
(Serverkomponenten, eventuell Zertifikate usw.).
Account Recovery:
Falls der USB Stick verloren gehen sollte, dann müsste der Benutzer den Verlust melden, damit der
Stick gesperrt wird. Dies könnte telefonisch geschehen und er müsste dann einen neuen Stick
bestellen und könnte sich solange nicht auf ein Account einloggen. Die Accountwiederherstellung
könnte so ähnlich sein wie bei den RSA SecurID Tokens.
3.2.3
IBM Zone Trusted Information Channel (ZTIC)
Beim ZTIC-Verfahren kommt ein USB Gerät (das sog. ZTIC Device) zum Einsatz, der die
Authentisierung vornimmt und sich direkt mit dem Onlinedienst verbindet. Das USB Gerät ist mit
einem Display ausgestattet und zwei Tasten zum Bestätigen und zum Abbrechen. Das USB-Gerät
vereint hier auch die Chipkarte und das Lesegerät ohne Tastatur aber mit Bildschirm von den HBCI-3
Verfahren. Entwickelt wurde das Verfahren vom IBM Zurich Research Laboratory [Weigold, Kramp,
Hermann, Höring, Buhler, & Baentsch, 2008]. Ursprünglich wurde es für Onlinebanking zur
39
Verhinderung von Man-in-the-Middle Angriffen entwickelt, aber es wäre damit auch eine
Authentisierung für Online Accounts denkbar.
33
Abbildung 30 : ZTIC USB Device
Ablauf:
Abbildung 31: ZTIC Benutzer Ablauf
Meldet sich der Benutzer bei einem Onlinedienst an (1), so verbindet sich der Onlinedienst mit dem
angeschlossenen USB Stick (2). Der Benutzer meldet sich dann z.B. mit seinem Logi nnamen und
Passwort an. Danach erscheint ein mit dem Onlinedienst vorher abgesprochenen Begrüßungstext,
Bild, aktuelle Zeit, Einmalpasswort o.ä. auf dem USB Stick (3). Sind die Daten korrekt, dann kann man
am ZTIC Device das Einloggen bestätigen und hat dann Zugriff auf die Daten.
Abbildung 32: Technischer Ablauf mit ZTIC Device
33
http://www.zurich.ibm.com/ztic/
40
Der ZTIC Device soll gegen Malware und Man-in-the-Middle Angriffen schützen. Dabei wird der ZTIC
Device an den PC über den USB angeschlossen und vom ZTIC Device wird ein ZTIC Proxy auf den PC
geladen (1). Dieser Proxy verbindet sich direkt mit einem vorkonfigurierter Webseite vom
Onlinedienst (2). Möchte sich der Benutzer mit dem Onlinedienst über seinen Webbrowser
verbinden, dann wird er durch den ZTIC Proxy direkt mit dem Onlinedienst verbunden (3). Der
Onlinedienst ist direkt mit dem ZTIC Device verbunden (4) und identifiziert den Benutzer durch
gespeicherte Daten auf dem ZTIC Device (z.B. mit PKI, SSL, Zertifikate...).
⇒ So würden R1-R5 gelten. Die Gefahr, dass ein Virus Probleme machen könnte gibt es beim ZTIC
Device zwar nicht, aber es sollte sichergestellt sein, dass der ZTIC Proxy, der auf dem Rechner
gespeichert ist, nicht manipuliert werden kann.
Kosten des ZTIC:
Der Aufwand der Erstellung und Benutzung des Accounts könnte die gleiche sein wie mit einem USB
Stick. Auch hier müssten Probleme vorgebeugt werden, dass vielleicht nicht alle Betriebssysteme mit
dem ZTIC Device kompatibel sind und vielleicht den ZTIC Proxy nicht installieren lässt.
TCO:
Die Kosten könnten so hoch wie die wie im vorherigen Verfahren beschriebenen USB Sticks sein.
Auch hier muss der Benutzer sich den USB Device anschaffen und der Onlinedienst entsprechende
Infrastruktur bereitstellen.
Account Recovery:
Die Accountwiederherstellung könnte analog wie beim vorherigen Verfahren mit dem USB Stick
verlaufen.
3.2.4
Fazit Besitz
Die vorgestellten Authentisierungsverfahren benötigen alle technisch weiterentwickelte Geräte.
Generell sollen durch auf Besitz basierende Authentisierungsverfahren dynamische Passwörter, d.h.
Einmalpasswörter, benutzt werden. Die Einmalpasswörter sollen die größte Schwachstelle des
Passwortverfahren kompensieren, die Weitergabe über Trojaner oder Phishing. Einer der ersten,
technisch fortgeschrittene Lösung, war das Token. Es generiert Einmalpasswörter, die für eine
bestimmte Zeit gültig sind. Es hat jedoch nicht das Passwortverfahren ablösen können. Tokens
werden aber von verschiedenen Diensten als zusätzliche Option eingesetzt, wie z.B. Google oder
Blizzard Entertainments Battle.net. Durch die große Verbreitung von IPhones und Android
Smartphones könnte der Einsatz von Authenticator Tokens jedoch zunehmen. So gibt es durch den
technischen Fortschritt mit dem Besitzfaktor viele weitere Möglichkeiten einer sicheren
Authentisierung, wie z.B. durch Zwei-Wege-Kommunikation oder auch die Zwei-Faktor
Authentifizierung. Sie basieren zwar auf dem Besitzfaktor, können aber aufgrund von besonderen
Merkmalen separat betrachtet werden, auf die ich später näher eingehen werde. Die ersten sicheren
Authentisierungsmethoden wurden für das Onlinebanking eingesetzt. Dabei setzte man zuerst auf
Hilfsmittel, die keine elektronischen Geräte benötigten: Papier. Daher ist es logisch sie einmal näher
anzuschauen und zu überprüfen, ob sie auch für Online Accounts geeignet sind.
41
4 Onlinebankingverfahren als Authentisierungsverfahren für Online
Accounts
Transaktionsnummern oder Transaktion Authentisierungsnummern (TANs) sind normalerweise
Einmalpasswörter und werden für Onlinebanking eingesetzt. Banken wollen den Kunden eine hohe
Sicherheit geben. Da aber eine Authentisierung mit Benutzername und PIN für eine Bank nicht sicher
genug ist, setzen sie auf eine Zwei-Faktor-Authentifizierung, indem man neben dem
Benutzernamen/PIN auch eine TAN braucht. Dabei stellt sich die Frage, ob man solche Verfahren
nicht auch auf Authentisierungsverfahren für Online Accounts anwenden könnte. Bei einer TAN wird
ein Auftrag, d.h. eine Transaktion in Form einer Überweisung vom Kontoinhaber authentisiert. Um
diese durchzuführen, muss er schon auf dem Account eingeloggt sein. Doch um sicherzugehen, dass
der eingeloggte Benutzer auch der ist, für den er sich ausgibt, soll es mit der zusätzlichen TAN
sichergestellt sein, dass kein Unbefugter die Überweisung tätigt. Aber im Grunde sollte das auch
beim Einloggen des Accounts schon gelten. Dann wäre eine TAN eigentlich überflüssig.
Neuere TAN-Verfahren binden Buchungsdaten bei der Berechnung mit ein oder werden nochmals
zur Bestätigung angezeigt um Man-in-the-Middle Angriffe vorzubeugen. Diese TAN-Verfahren sind
meist technisch weiterentwickelte Verfahren und sollen Manipulationen von Transaktionen
verhindern. Doch es gibt auch Ideen für Papier-Verfahren, die versuchen, mit Einbeziehung der
Transaktionsdaten, diese zu schützen. Da es bei einer Anmeldung auf ein Account keine
Transaktionsdaten gibt, die man vor Manipulationen schützen muss, kann man trivialerweise diese
Option für Authentisierungen von Online Accounts weglassen oder anstatt den Transaktionsdaten
eine zu übertragende PIN absichern, bzw. diese mit Challenge-Response ersetzen.
So kann man jedes TAN-Verfahren auch für Absicherungen für Online Accounts benutzen, wobei die
Sicherheit höchstens so hoch sein kann wie das davon abstammende TAN-Verfahren, aber
mindestens so hoch ist wie das klassische TAN-Verfahren bestehend aus Einmalpasswörtern.
4.1 Papier TAN-Verfahren für Online Account Authentisierung
Ich werde nun einige TAN-Verfahren in veränderter Form für Authentisierungen von Online Accounts
vorstellen. Dabei werde ich mit sogenannte Papier-TAN Verfahren beginnen.
4.1.1
Einmal-PIN Liste34
Die Einmal-PIN Liste basiert auf die TAN-Liste für Online Accounts. Die Authentisierung für ein Online
Account basiert dabei auf eine Liste von Einmalpasswörtern. Der Benutzer muss im Besitz der Liste
sein, damit er sich auf ein Online Account einloggen kann. Das Einmalpasswort besteht aus eine
zufällig generierte sechsstellige Nummer, einer PIN. Um sich also einzuloggen, muss der Benutzer
beispielsweise seinen Benutzernamen, seine Account PIN und die einmalige PIN eingeben.
34
Basiert auf klassisches TAN-Verfahren.
42
Ablauf:
Abbildung 33: Beispiel einer Einmal-PIN-Liste
Der Benutzer hat vom Onlinedienst eine Liste mit PINs (Abbildung 33) erhalten und befindet sich in
seinem Besitz.
Abbildung 34: Möglicher Ablauf eines Einmal-PIN Liste Verfahrens
1. Der Benutzer loggt sich nun in sein Account ein, indem er neben seinen Benutzernamen und
seine normale Account PIN eingibt.
2. Er wird dann vom Onlinedienst aufgefordert seine einmalige PIN einzugeben. So wählt er
eine PIN aus seiner Liste aus und gibt sie ein.
3. Der Onlinedienst überprüft die einmalige PIN und ist sie korrekt, dann öffnet der
Onlinedienst den Account für den Benutzer. Danach ist die PIN nicht mehr gültig und der
Benutzer muss beim nächsten Mal eine andere PIN aus der Liste nehmen, bis alle
aufgebraucht sind. Danach muss eine neue Liste mit PINs erstellt und zugeschickt werden.
Man könnte theoretisch auch den Account PIN weglassen und sich nur mit dem
Benutzernamen und einem Einmalpasswort authentisieren. Die zusätzliche Eingabe einer
Account PIN dient normalerweise nur dazu, damit man ältere Accounts mit einem zweiten
Faktor nachträglich absichern kann.
43
Die Einmal-PIN Liste ist genauso sicher wie das TAN-Verfahren und hat die gleichen Sicherheitsrisiken.
So kann man R1 und R5 als vorausgesetzt gelten, da die zufällige generierte einmalige PIN lang genug
ist und die Liste sicher aufbewahrt sein sollte.
Abbildung 35: Mögliche Sicherheitsrisikofaktoren
1. Der Benutzer kann Ziel des Angriffs werden: Bei Phishingversuchen erhält der Benutzer eine
E-Mail oder durch XSS wird er auf eine Webseite des Angreifers umgeleitet, in der er
aufgefordert wird, seine PINs einzugeben. Als ein Grund kann angegeben sein, dass die Liste
abläuft und man eine neue Liste erhält, sobald man sich mit der alten Liste verifiziert hat. ⇒
R2 gilt hier nur noch eingeschränkt, da die Weitergabe der PINs nicht mehr so einfach ist,
aber auch nicht unmöglich. Noch wäre wohl der Aufwand für einen Angreifer für einfache
Accounts zu hoch. Sie ist aber für Banken nicht mehr sicher genug und darum wenden sich
immer mehr vom TAN- bzw. iTAN-Verfahren ab.
2. Die PIN kann mit einem Trojaner abgehört werden. Aber diese Information sollte da schon
nutzlos sein, da sie dann ungültig ist. ⇒ R3 gilt.
3. Auch Replay-Angriffe sind möglich. Aber die abgefangenen PINs sind nutzlos, da sie nach
dem einmaligen Gebrauch während der Übertragung ungültig sind. Größte Gefahr geht von
Man-in-the-Middle Angriffen und Phishingversuchen über XSS aus (Abbildung 36). Bei Manin-the-Middle Angriffen kann ein Angreifer die TAN abfangen und sich damit einloggen. Dem
Benutzer gegenüber kann er mit einer Fehlermeldung vorgaukeln, dass die eingegebene PIN
ungültig sei. Bei Onlinebanking können damit Überweisungen manipuliert werden, indem sie
dem Benutzer seine normale Überweisung anzeigen, aber der Bank eine andere
Überweisung übertragen und sie mit der abgefangenen PIN bestätigen. Darum setzen
Banken immer mehr auf andere Verfahren, die solche Angriffe verhindern sollen.
Auch könnte man bei Man-in-the-Middle Angriffen mehrere PINs abfangen und sie später für
Authentisierungen benutzen. ⇒ R4 kann hier nur noch eingeschränkt gelten, da bisher der
Aufwand und der Nutzen zu groß ist für normale Online Accounts. Sie ist aber für Angreifer
machbar und wurde schon bei Onlinebanking angewandt.
44
Abbildung 36: Beispiel eines Phis hingversuchs für Onlinebanking über eine gefälschte Webseite
Kosten einer Einmal-PIN Liste:
Die Einmal-PIN-Liste muss bei der Accounterstellung über einen sicheren Weg zugeschickt werden.
Normalerweise geschieht dies über den Postweg. Sollte die Liste vollständig benutzt sein, dann muss
man eine neue Liste erstellen. Die Einmal-PIN-Liste sollte immer sicher aufbewahrt sein und
erschwert damit die Mobilität. Um sich von überall einloggen zu können, muss man die Einmal-PINListe immer mit sich führen.
Zeitfaktor:
Die Anmeldezeit kann sich erhöhen gegenüber dem Passwort-Verfahren, weil der Benutzer jedes Mal
die Liste hervorholt und eine PIN raussuchen und streichen muss. Auch die Einrichtung eines
Accounts erhöht sich (je nach Methode kann sie sich um Minuten oder Tage verlängern, weil die Liste
per Post oder E-Mail zugeschickt wird).
TCO:


Für den Benutzer sollten keine höheren Kosten wie beim PIN-Verfahren zukommen, außer
der Dienstanbieter wälzt eventuelle Versandkosten auf den Benutzer ab.
Für Login-Verfahren mit Einmal-PIN Listen kann es für den Onlinedienst teuer werden, da der
Dienstanbieter entweder eine sehr große Liste zuschicken müsste oder oft, weil nach jedem
Login eine PIN ungültig ist und die Liste schnell aufgebraucht werden kann, sollte der
Benutzer sich täglich einloggen. Er bräuchte zusätzliche Softwarekomponenten, die eine
Generierung und Verwaltung der Einmalpasswortlisten ermöglicht.
Account Recovery:
Sollte man für ein Authentisierungsverfahren bei einem Online Account die Einmalpasswortliste
verloren haben, dann muss man sich eine neue Liste zuschicken und die alte Liste sperren lassen. Das
könnte mit der Post ein bis zwei Tage dauern. Die Sperrung und der Antrag auf eine neue Liste
müssten wohl telefonisch geschehen, da man Online sich ohne die Liste nicht authentifizieren kann.
45
4.1.2
indizierte Einmal-PIN Liste35
Das Verfahren mit einer indizierten PIN-Liste ist dem Einmal-PIN-Liste-Verfahren sehr ähnlich. Der
einzige Unterschied dabei ist, dass die Einmalpasswortliste nummeriert ist. Es soll Phishingversuche
und auch Man-in-the-Middle Angriffe erschweren.
Ablauf:
Der Unterschied zwischen dem Einmal-PIN-Liste und dem indizierte Einmal-PIN-Liste besteht darin,
dass man keine beliebige PIN eingeben kann, sondern der Onlinedienst eine bestimmte nummerierte
PIN verlangt, die man anhand einer Indexnummer identifizieren kann. Nur diese PIN ist bei der
Anmeldung gültig und wird danach ungültig. Beim späteren Anmelden ist dieselbe PIN, bzw.
indizierte PIN ungültig.
Abbildung 37: indizierte Einmal-PIN-Liste
indizierte Einmal-PIN-Liste soll die Sicherheit gegenüber dem herkömmlichen Einmal-PIN-ListeVerfahren erhöhen, da der Onlinedienst nur eine bestimmte PIN anfordert und akzeptiert. So weiß
der Benutzer zum einen, dass er mit dem Onlinedienst in Verbindung steht und zum anderen genügt
dem Angreifer nicht nur eine abgefangene PIN, sondern muss ungleich viel mehr PINs abfangen,
damit er mit einer größeren Wahrscheinlichkeit einloggen kann. Aber im Grunde ist das indiziert
Einmal-PIN-Liste-Verfahren genauso anfällig auf die Angriffe wie beim Einmal-PIN-Liste-Verfahren.
Mit kombinierten Phishing und Man-in-the-Middle Angriffen kann man immer noch eine vollständige
Einmal-PIN-Liste vom Benutzer abfangen. ⇒ R1, R3 und R5 sollten daher mit der Einmal-PIN-ListeVerfahren vergleichbar sein und es erhöht sich nur sehr leicht die Sicherheit für R2 und R4, kann
aber schon fast vernachlässigt werden, da der Aufwand für einen erfolgreichen Angriff nicht viel
höher ist.
Kosten einer indizierten Einmalpasswortliste:
indizierte Einmalpasswortliste-Verfahren haben einen ähnlichen Aufwand wie die
Einmalpasswortliste. Das Verfahren ist ein wenig aufwendiger, da man keine beliebige PIN eingeben
kann, sondern nach einem bestimmten Index suchen und dann diesen bestimmten PIN eingeben
muss.
Der Zeit und Kostenfaktor (TCO) ist im Prinzip die gleiche wie beim Einmalpasswortliste-Verfahren.
Account Recovery:
Die Accountwiederherstellung bei einer verlorenen indizierten Einmalpasswortliste ist die gleiche wie
beim Einmalpasswortliste-Verfahren.
35
Basiert auf iTAN.
46
4.1.3
Indizierte Einmalpasswortliste mit Schutz vor Man-in-the-Middle Angriffe36
Das iTAN mit CAPTCHA Verfahren ist das normale indizierte TAN-Liste -Verfahren erweitert mit
CAPTCHA. Dies soll Man-in-the-Middle Angriffe erschweren, da ein Kontrollbild mit den
Überweisungsdaten vor der Eingabe der TAN eingeblendet wird (Abbildung 38).
Abbildung 38: iTAN mit CAPTCHA Beispiel
CAPTCHA steht für Completely Automated Public Turing test to tell Computers and Humans Apart.
CAPTCHA versucht überwiegend mit Challenge-Response-Tests Entscheidungen zu treffen, ob der
Gegenüber ein Computer oder Mensch ist. Dabei wird meistens ein Text mit einem Bild im
Hintergrund erschwert kenntlich gemacht. Den Text sollte man dann lesen und eingeben oder eine
Aufgabe lösen können (Abbildung 39).
Abbildung 39: CAPTCHA Beispiele
Das Ziel mit einem CAPTCHA Bild ist es sicherzustellen, die Überweisungsdaten im Hintergrund
darzustellen, so dass der Benutzer überprüfen kann, ob die übertragenen Überweisungsdaten nicht
manipuliert wurden. Dies ist bei einer Anmeldung jedoch nicht nötig und man könnte diesen Schritt
einfach weglassen. Dann wäre man wieder bei der vorher vorgestellten indizierten Einmal-PIN-Liste.
Aber man kann mit der Methode Man-in-the-Middle Angriffe insofern entgegenwirken, wenn man
eine Variante anwendet, wie sie bei Yahoo! sign-in-seal verwendet wird. Damit sollen XSS Angriffe
entgegengewirkt und sichergestellt werden, dass man mit dem Onlineprovider verbunden ist.
Mit Yahoo! sign-in-seal muss der Benutzer bei der Accounterstellung einen bestimmten Text oder
Bild hochladen und die wird dann beim Einloggen immer angezeigt (Abbildung 40). Wird Yahoo! signin-seal benutzt, so erkennt der Onlinedienst mit welchem Computer er verbunden ist und auf dem
Loginbildschirm erscheint dann entweder ein Text oder ein Bild, das man vorher vereinbart hatte.
Dabei werden die benötigten Informationen in Cookies abgespeichert.
37
Abbildung 40: Yahoo! sign-in-seal
36
Basiert auf iTANplus bzw. iTAN mit CAPTCHA.
47
Ablauf:
Der Ablauf ähnelt dem indizierten Einmal-PIN-Liste -Verfahren. Der Benutzer muss sich beim
Einloggen also mit seinem Benutzernamen und einem Account PIN authentifizieren. Danach muss er
die Eingabe zusätzlich mit einer PIN aus der indizierten Passwortliste bestätigen. Mit der Anzeige des
Index der PIN, die man eingeben muss, erscheint im Hintergrund als Bild (z.B. als Wasserzeichen) die
eingegebene vorherige PIN mit zusätzlichen Informationen, die nur der Onlinedienst kennen sollte.
Der Benutzer muss also vor der Eingabe der zweiten PIN überprüfen, ob die Daten im Hintergrund
korrekt sind. Es können aber auch andere Informationen angezeigt werden, die der Benutzer vorher
mit dem Onlinedienst vereinbart hat. So kann es der Geburtstag, ein Bild oder ein bestimmter
Begrüßungstext sein, wie es bei Yahoo! sign-in-seal der Fall ist.
Prinzipiell sind Angriffe wie beim Einmal-PIN-Liste -Verfahren immer noch möglich. Aber mit dieser
Methode möchte man sicher gehen, dass der Benutzer erkennt, wenn er mit dem Onlinedienst in
Verbindung steht oder nicht. Es soll Man-in-the-Middle Angriffe verhindern, da man damit erkennen
kann, ob man direkt mit dem Onlinedienst in Verbindung steht. Sind aber einfache Merkmale wie
Geburtstag oder Begrüßungstext vereinbart worden, dann kann es der Angreifer durch
Phishingversuche trotzdem noch herausfinden. Bei Bildern, die man hochladen muss, können
Phishingversuche erschwert werden, aber diese könnte man notfalls mit Trojaner, die Screenshots
machen, herausfinden und später für XSS Phishingversuche eingesetzt werden. Außerdem kann die
Einmal-PIN-Liste immer noch gestohlen werden indem man unaufmerksame Benutzer zur
Herausgabe der Liste durch falsche E-Mails usw. bringt. ⇒ R4 sollte gelten, da der Aufwand hier für
einen Angreifer höher ist als bei den vorherigen Verfahren. Für R1, R2, R3 und R5 ändert sich
dagegen wenig.
Kosten einer indizierten Einmal-PIN-Liste mit CAPTCHA:
CAPTCHA Kontrollbilder können schwer zu erkennen sein. Sie sind nicht Barrierefrei und
Sehbehinderte (z.B. rot-grün Blinde) können die verschwommenen Texte schwer erkennen. Im Falle
von Yahoo! sign-in seal ist man zudem nicht so flexibel, da man sich damit nur auf dem Re chner
einloggen kann, wo der Benutzer den Account erstellt hat. Sollte er auch auf dem Rechner alle
Cookies löschen bzw. den Browser, dann muss er sich erneut registrieren, da der Onlinedienst den
Benutzer nicht mehr erkennt und somit den Text oder Bild nicht anzeigt. Ansonsten ist der Aufwand
ähnlich dem Einmal-PIN-Liste -Verfahren und der Benutzer muss die Liste mitführen, wenn er sich
woanders einloggen möchte.
Zeitfaktor:
Der Benutzer sollte ähnlich lange brauchen um sich auf ein Account einzuloggen wie beim indizierten
Einmal-PIN-Liste -Verfahren. Eine unwesentliche Verzögerung könnte durch die vorherige Kontrolle
der Kontrollbilder entstehen.
TCO:

37
Für den Benutzer sollten nicht höhere Kosten wie beim Einmal-PIN-Liste -Verfahren
entstehen.
https://protect.login.yahoo.com/
48

Der Onlinedienst muss zusätzliche Softwarekomponenten besitzen, die die Kontrollbilder
erstellt bzw. verwaltet.
Account Recovery:
Die Accountwiederherstellung sollte dem des Einmal-PIN-Liste -Verfahren gleichen.
4.1.4
indirekt indizierte Einmal-PIN Liste38
Die indirekt indizierte Einmalpasswortliste39 ist eine weitere Erweiterung des Einmal-PIN-Liste Verfahrens. Man erhält eine indirekte indizierte Einmal-PIN-Liste, die aus indizierte PINs und
Buchstaben besteht. Die Eingabe der Einmal-PIN soll abhängig der PIN des Benutzers sein. Dabei
kann man das Verfahren anwenden um die PIN nicht direkt einzugeben, sondern indirekt über die
indirekt indizierte Einmal-PIN-Liste. Das darauf basierende iiTAN Verfahren bindet während der
indirekten Eingabe der TAN die Kontonummer einer Überweisung mit ein, um Man-in-the-Middle
Angriffe vorzubeugen. Da dies für Anmeldungen nicht nötig ist, kann dieser Schritt wegfallen. Aber
man kann immer noch indirekt die PIN eingeben und somit Trojaner wirkungslos zu machen.
Abbildung 41: iiTAN Liste 40
Ablauf:
Abbildung 42: Beispiel einer Anmeldeseite
Die indirekte indizierte Einmal-PIN-Liste besteht aus einer indizierten Einmal-PIN-Liste und eine Leiste
mit zufälliger Buchstabenfolge, die 10 Stellen hat (Abbildung 41). Mit dem Beispiel in der Abbildung
42 läuft die Eingabe folgendermaßen ab:
Der Benutzer gibt seinen Benutzernamen ein. Hat er dies getan, dann wird er aufgefordert die PIN Nr.
31 einzugeben (Abbildung 43). Dabei erscheint auf der Seite eine Leiste auf der alle zehn Ziffern
einmal vorkommen (0-1). Diese kann auch in einer zufälligen Reihenfolge erstellt werden.
38
Basiert auf iiTAN [Borchert, Fälschungssichere Online Transaktionen, 2009].
Abgekürzt nenne ich sie hier iiPIN.
40
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/iiTAN/
39
49
Abbildung 43: Eingabe-Beispiel einer indirekten indizierten Einmalpasswortliste
Der Benutzer kann seine Liste bis zur gewünschten PIN Nr. abknicken und sie am Monitor halten.
Seine PIN Nr. 31 lautet in unserem Beispiel "897415". Der Benutzer schaut nach, welcher Buchstabe
auf seiner PIN-Liste die "8" auf der Anmeldeseite abbildet. Dies wäre "c". Dann geht er weiter und
schaut nach, welcher Buchstabe die "9" abbildet usw. Es ergibt die Buchstabenfolge "cpswvj". Dies
wäre eine Ein-Faktor-Authentifizierung, da man dafür nur die Liste braucht. Auf die Zwei-Faktor
Variante werde ich später näher eingehen.




Mindestens so sicher wie die indizierte Einmal-PIN-Liste. ⇒ R1 und R4 bleiben gleich.
Zusätzliche Sicherheit gegenüber Trojaner, da die Einmal-PIN nicht direkt eingegeben wird. ⇒
R3 gilt.
Gegen Phishing nur bedingt sicher, da man die Liste weitergeben könnte. ⇒ R2 mindestens
so sicher wie bei den vorherigen Listen-Verfahren und könnte etwas komplizierter sein. da
die Liste komplexer ist.
Bei Verlust oder Diebstahl der indirekt indizierten Einmal-PIN-Liste hätte der Angreifer vollen
Zugriff auf den Account. ⇒ R5 ist dennoch gegeben, da der Aufwand hoch ist, damit ein
Angreifer die Liste stehlen kann. So müsste er z.B. in das Haus des Benutzers einbrechen.
Kosten einer indirekte indizierte Einmal-PIN-Liste:
Die Eingabe der PIN wird komplizierter. Es kann Kunden am Anfang überfordern.
Zeitfaktor:
Da die Eingabe komplizierter ist wie mit der normalen Einmal-PIN-Liste, wo man die PIN einfach aus
der Liste abliest, kann es länger dauern, bis der Benutzer sich eingeloggt hat.
TCO:
Für den Benutzer dürften die Kosten dem des Einmal-PIN-Liste-Verfahren ähneln und nur der
Onlinedienst braucht die spezielle Serverkomponenten für die Erstellung und Verwaltung des
indirekten indizierten Einmal-PIN-Liste in seinem System. Auf dem Onlinedienst kommen zusätzlich
noch die Portokosten hinzu.
Account Recovery:
Die Accountwiederherstellung sollte dem des Einmal-PIN-Liste-Verfahren gleichen. Die indirekt
indizierte Einmal-PIN-Liste muss bei Verlust gesperrt und eine neue zugeschickt werden.
50
4.1.5
indirekt indiziertes Bild-Einmal-PIN-Liste41
Das indirekt indizierte Bild-Einmal-PIN-Liste-Verfahren 42 ist eine Variante vom indirekt
indizierten Einmal-PIN-Liste-Verfahren. Anstelle von Buchstaben muss man Bilder eingeben,
was Phishingversuche erschwert. Die iiBild-PIN Liste besteht aus zwei Bilderreihen und die
indizierte PIN-Liste, wie sie in Abbildung 44 aussehen könnte. Bei der Onlinebanking Variante
wird dabei die Kontonummer der Überweisung mit der TAN eingebunden um Man-in-theMiddle Angriffen entgegenzuwirken.
Abbildung 44: BildTAN Karte 43
Die erste Bilderreihe ähnelt der Buchstabenliste von der indirekt indizierten Einmal-PIN-Liste (1). Sie
besteht hier aber aus Bildern, deren Anzahl und Anordnung den Ziffern auf der Anmeldeseite
angepasst sind (Abbildung 46). So kann die Eingabemaske entsprechend angeordnet sein, dass man
die Bilderliste direkt unter den Ziffern anlegen kann und somit die PIN und dazugehörigen Bilder
leichter ablesen lässt (Abbildung 47). In unserem Beispiel aus Abbildung 44 besteht die Einmal-PIN
aus sechs Ziffern (3) und sechs unterschiedliche Bilder44 (2).
Ablauf:
Als erstes möchte ich eine Ein-Faktor-Authentifizierung vorstellen. Später werde ich eine weitere
Variante vorstellen. Der Benutzer hat vom Onlinedienst die iiBild-PIN Karte erhalten und besitzt
einen Benutzernamen. Mit der iiBild-PIN Karte kann er sich authentisieren.
Abbildung 45: Beispiel eines Loginbildschirms
41
Basiert auf Bild-TAN [Borchert, Bild-TAN Verfahren].
Ich kürze es hier mit iiBild-PIN ab.
43
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/BildTAN/
44
Die Anzahl der Bilder lassen sich variieren und können auch neun sein.
42
51
Der Benutzer loggt sich zuerst ganz normal mit seinem Benutzernamen auf seinen Onlinedienst ein
(Abbildung 45). Danach muss er einen Bestätigungscode eingeben, d.h. er muss mit der iiBild-PIN
Liste beweisen, dass die Einmal-PIN ihm gehört. Es erscheint auf dem Bildschirm die Aufforderung
aus der iiBild-PIN Liste mit der PIN Nr. 7 einen Bestätigungscode einzugeben (Abbildung 46). Dabei
wird auf der Anmeldeseite die Nummer der PIN, die blauen Tastenfelder zur Eingabe der PIN und
eine Leiste mit den Ziffern 0-9 in zufälliger Reihenfolge angezeigt.
Abbildung 46: Beispiel eines Loginbildschirms für Bestätigungsschritt
Man hält die iiBild-PIN Liste unter der Eingabemaske und kann die Bilder der ersten Reihe
entsprechend mit den Ziffernfeldern vergleichen (Abbildung 47).
Abbildung 47: Anmeldebildschirm mit angelegter Bild-PIN Liste
Die PIN Nr. 7 lautet in unserem Beispiel "319 786" (1) und man schaut nach, wo die Zahl in der
Ziffernleiste auftaucht. Die "3" befindet sich über das Bild mit dem Apfel (2). Der Benutzer schaut
52
dann, wo der Apfel in der zweiten Bilderreihe auftaucht. Der befindet sich an erster Stelle der
zweiten dreier Gruppe. So kann der Benutzer den entsprechenden blauen Button (erste Stelle der
zweiten dreier Gruppe) drücken (3). Der Benutzer fährt genauso mit der "1" fort, die über dem
blauen Haus steht. Das blaue Haus ist die dritte Stelle der zweiten dreier Gruppe und man drückt den
entsprechenden Button. Hat der Benutzer die PIN komplett eingegeben und ist alles korrekt, dann
hat sich der Benutzer in sein Account eingeloggt.





R1 wäre gegeben, da man nur einmalige und zufällige PINs benutzt mit einer genügenden
Länge.
Phishing Angriffe kann es nicht verhindern, aber mit den Bildern erschweren, vor allem,
wenn man die Anzahl verschiedener Bilder auf zehn erhöht und jeder Benutzer andere Bilder
besitzt. Sie könnten personalisiert werden und der Onlineprovider könnte aus einer großen
Sammlung von Bildern verschiedene iiBild-PIN Karten erstellen. Eine einfache Weitergabe der
Bilder über den Benutzer wird dadurch verhindert. ⇒ R2 gilt.
Die Eingabe der Einmal-PIN wäre abhörsicher, da Trojaner nicht erkennen können, welche
Ziffern eingegeben werden. ⇒ R3 gilt.
Man-in-the-Middle Angriffe könnten weiterhin wie beim indirekt indizierten Einmal-PINListe-Verfahren durchgeführt werden. ⇒ R4 kann eingeschränkt als sicher gelten.
Bei Verlust oder Diebstahl der iiBild-PIN Karte könnten Angreifer sich jederzeit auf den
Account einloggen. ⇒ R5 kann noch gelten, da der Aufwand zu groß ist.
Kosten eines indirekten indizierten Bild-Einmal-PIN Verfahrens:
Die Eingabe der PIN wird komplizierter und dauert länger. Es kann manche Kunden am Anfang
überfordern und daher abschrecken.
TCO:
Die Kosten sollten für den Benutzer und Onlinedienst mit dem des indirekt indizierten Einmal-PINListe-Verfahren vergleichbar sein. Nur die Softwarekomponenten ändern sich, da man Bilder nun für
die Authentisierung benutzt und diese speichern und verwalten muss. Der Onlinedienst muss die
Karten auch drucken und verschicken lassen.
Account Recovery:
Die Accountwiederherstellung sollte dem des Einmal-PIN-Liste-Verfahren gleichen.
53
4.1.6
Linien-PIN45
Das Linien-PIN Verfahren ist eine weitere Abwandlung des vorherigen indirekt indiziertem Bild
Einmal-PIN Verfahrens. Anstatt der indirekten Eingabe der PIN über Buchstaben oder Bilder werden
hier Linien benutzt.
Abbildung 48: Linien-PIN Liste 46
Wie in Abbildung 48 zu erkennen ist, gehört zu jeder indizierten PIN Linien mit Pfeilen, die von jeder
Stelle, wo sich eine PIN befinden kann weg geht und zu einer Position führt wo in der Eingabemaske
graue Tastenfelder befinden, wie in Abbildung 49. Man kann also die Liste abknicken und sie direkt
unter dem Eingabefeld legen und damit dann vergleichen.
Abbildung 49: Eingabemaske für Linien- PIN Verfahren
Ablauf:
Der Benutzer loggt sich normal mit seinem Benutzernamen auf dem Onlinedienst an. Danach wird er
aufgefordert, seine Einmal-PIN indirekt einzugeben (Abbildung 49). In unserem Beispiel wird die
Einmal-PIN Nr. 4 verlangt. Man legt die PIN-Linie so an, dass sie direkt unter der in zufälliger
Reihenfolge angezeigten Ziffern liegt (Abbildung 50). Die PIN lautet "630751" (1). Man nimmt die "6"
und schaut in der Ziffernleiste nach der "6".
45
46
Basiert auf Linien-TAN [Rohrer, 2009].
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/studdiplLinienTAN/
54
Abbildung 50: Beispiel von Linien-PIN mit angelegter Liste
Die "6" findet sich an dritter Stelle (2) und eine Linie zeigt mit dem Pfeil auf eine der 5 grauen
Kästchen, die sich auf der linken und rechten Seite befinden (3). Auf die Schaltfläche, die die "6" führt,
wird dann als erste gedrückt (4). Dann geht verfolgt man die nächste Zahl in der PIN. Der Benutzer
drückt als nächstes auf die entsprechende Stelle auf der die "3" zeigt. Der Benutzer führt die
Prozedur solange fort, bis die PIN abgearbeitet ist. Der Benutzer muss sich in unserem Beispiel mit
der Linien-PIN Liste authentifizieren.
Die Sicherheitsrisiken sind die mit dem indirekt indizierten Bild-PIN Verfahren vergleichbar, wobei R2
noch etwas höher ist, da die Weitergabe von Linien noch schwerer ist als von Bildern.
Kosten des Linien-PIN-Verfahrens:
Benutzerfreundlichkeit/Zeit/TCO:
Die Eingabe der PIN ist komplizierter und dauert länger. Es kann manche Kunden am Anfang
überfordern. Ansonsten sollten die Kosten dem den vorherigen Verfahren ähneln.
Account Recovery:
Die Accountwiederherstellung sollte wie beim Einmal-PIN-Verfahren ablaufen.
4.1.7
Cardano-PIN47
Mit einer Cardano-PIN möchte man Trojaner oder Keylogger die Arbeit erschweren, indem man mit
Lochkarten und wechselnden Eingabefelder für die PIN arbeitet
Abbildung 51: Beispiel einer Cardano Lochkarte
47
48
48
Basiert auf Cardano-TAN [Beschke, 2009].
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/studdiplbeschke/
55
Der Onlinedienst verschickt nummerierte Lochkarten (Abbildung 51) und für die Eingabe der PIN
verwendet man das Eingabefeld und das Ziffernfeld in seiner Eingabemaske zum Einloggen
(Abbildung 52) Die linke Lochkarte aus Abbildung 51 zeigt blaue und rote Kreise. Die blauen Kreise
sind mit einem Pfeil verbunden. Dadurch lässt sich eine Ziffernfolge ablesen, wie z.B. eine
Kontonummer oder mit dem Onlinedienst vereinbarter Geheimabfrage wie Geburtstag,
Telefonnummer usw.
Ablauf:
Der Benutzer hat vom Onlinedienst einen Stapel mit Lochkarten erhalten. Für unser Ablaufbeispiel
werde ich die rechte Lochkarte aus Abbildung 51 für eine Zwei-Faktor-Authentifizierung verwenden.
Der Benutzer wird dabei einen wiederverwendbaren Account PIN benutzen. Es wäre auch eine EinFaktor Authentisierung denkbar, in der der Benutzer sich nur mit der linken Lochkarte aus Abbildung
51 einloggt, indem er die Tasten hintereinander anklickt, auf der die Pfeile mit dem blauen Kreis
anzeigen.
Abbildung 52: Beispiel einer Anmeldeseite mit Cardano PIN
Der Benutzer gibt seinen Benutzernamen auf der Anmeldeseite ein. Danach wird er nun aufgefordert
eine bestimmte Karte über das Ziffernfeld zu legen. In Abbildung 52 ist ein Beispiel einer
Eingabemaske aufgezeigt, wo man das Eingabefeld für die PIN und das Ziffernfeld für die Lochkarte
sieht.
Abbildung 53: Lochkarte wurde über das Ziffernfeld gelegt und man sieht nun die Felder für die PIN
Um nun die PIN eingeben zu können, muss der Benutzer eine indizierte Lochkarte über das
Ziffernfeld legen. Die Karten sind nummeriert und nur die richtige Lochkarte stellt die Zahlen korrekt
dar. Hat der Benutzer die Karte über das Ziffernfeld gelegt (Abbildung 53), dann kann er die Felder in
den roten Kreisen sehen, wo die Ziffern für die PIN stehen und diese dann im Eingabefeld eingeben
(Abbildung 54).
56
Abbildung 54: Die Ziffern und die PIN die hinter dem Eingabefeld stehen, wie es die Cardano Lochkarte anzeigt





R1 würde gelten, da der Angreifer nicht herausfinden kann, welche PIN er eingibt und wüsste
er das Passwort, könnte er sie ohne die Lochkarte nicht eingeben.
R2 könnte eingeschränkt gelten. So wären Phishing Angriffe erschwert, da man die
Lochkarten nicht so einfach weitergeben kann.
R3 würde gelten, da auch Trojaner und Keylogger wirkungslos sind. Man kann das
Eingabefeld nicht einsehen und die PIN somit nicht abfangen.
Man-in-the-Middle Angriffe wären komplizierter, aber weiterhin möglich. Damit der Hacker
Zugang zum Account erlangen kann, bräuchte er bei der Zwei-Faktor Variante neben dem PIN
auch noch die Lochkarten. ⇒ R4 gilt.
R5 sollte auch gelten, da der Aufwand sehr hoch sein sollte um in den Besitz der Lochkarten
zu gelangen.
Kosten der Cardano-PIN:
Die Eingabe der PIN wird komplizierter und dauert länger. Es kann manche Kunden am Anfang
überfordern. Ungenauigkeiten können zu falscher Eingabe führen. Die Kosten dürften beim Benutzer
ähnlich dem der vorherigen Methoden wie Linien-PIN sein, nur der Onlinedienst müsste
Softwarekomponenten zur Erstellung der Lochkarten und der Verwaltung und Darstellung der
Eingabefelder anschaffen.
Account Recovery:
Die Accountwiederherstellung müsste so ablaufen wie beim Einmal-PIN-Liste-Verfahren.
4.1.8
Visuelle-PIN49
Das Verfahren basiert auf Visueller Kryptographie von Moni Naor und Adi Shamir [Naor & Shamir,
1994]. Man hat dabei zwei Bilder, die jeweils ein Teilgeheimnis erhalten und alleine nur Rauschen
darstellen und man nichts erkennen kann. Sobald man aber die beiden Bilder übereinanderlegt,
erhält man mit den beiden Teilgeheimnissen ein vollständiges Bild und man kann dann darauf
Abbildungen erkennen.
49
Basiert auf vTAN [Borcher t & Reinhardt, Abhoer- und manipulationssichere Verschluesselung fuer Online
Accounts, 2008].
57
Ablauf:
Der Benutzer erhält vom Onlinedienst nummerierte Folien. Hat sich der Benutzer mit einem
Benutzernamen und Passwort eingeloggt, dann wird er aufgefordert eine bestimmte Folie über den
Bildschirm zu legen (A aus Abbildung 55). Das Bild auf dem Bildschirm und auf der Folie haben jeder
für sich nur Rauschen und keine Informationen, um daraus ein Gesamtbild erstellen zu können. Liegt
aber die bedruckte Folie über das Bild auf dem Bildschirm, lässt sich daraus Bilder oder Texte
erkennen, wie z.B. Punkte, die man dann drücken kann um sich zu authentisieren (B aus Abbildung
55).
Abbildung 55: A zeigt das Bildschirm ohne die drübergelegte Folie und B zeigt das Geheimnis, indem man die Folie über
das Bildschirm legt50
Abbildung 56: Mögliche Angriffsziele
1. Phishingversuche beim Benutzer ist nicht möglich, da man die Folien und das darauf
befindliche Bild zu fein sind um sie irgendwie kopieren zu können. So lässt sie sich bei der
Low-Tech Variante im Gegensatz zu einer TAN-Liste nicht weitergeben, wenn der Angreifer
die Folie nicht physisch in die Hände bekommt. ⇒ R1, R2 und R5 gilt.
2. Malware wie Trojaner oder Keylogger könnten mit der Low-Tech Variante keine Passwörter
oder das korrekte Bild angezeigt bekommen. Das verhindert die Tatsache, dass der passende
Schlüssel zum entschlüsseln nicht elektronisch erfasst werden kann. Der Angreifer könnte
aber versuchen einen Ciphertext-only Angriff zu starten, indem er versucht mit einer Anzahl
50
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/VisuelleKryptografie/
58
von abgefangenen verschlüsselten Bildern vom Onlinedienst Überschneidungen zu finden.
Die Bildauflösung müsste sehr hoch sein bzw. die dargestellten Bilder sehr klein, damit man
solche Angriffe erschwert. Es wäre auch möglich damit wechselnde Zifferntasten erscheinen
zu lassen, in der man dann über einen Mausklick die PIN eingeben kann. ⇒ R3 gilt, da ein
hoher Aufwand betrieben werden muss und die Folien entsprechend angepasst sind, dass
keine Überschneidungen auftreten bzw. nur einmal benutzt werden.
3. Beim Onlinebanking werden Man-in-the-Middle Angriffe erschwert, da man im
verschlüsselten Teil die Überweisungsdaten darstellt. Bei einer Authentisierung auf ein
Online Account gibt der Benutzer normalerweise keine Daten an den Onlinedienst weiter, da
müsste man für eine Nonce sorgen, die der Benutzer erfolgreich bestätigen kann. Der
Onlinedienst könnte ansonsten aber auch vorher abgesprochene Daten darstellen, wie z.B.
hochgeladene Bilder, Texte, Informationen wie Geburtstag usw. Ein Risiko für Man-in-theMiddle Angriffe würde aber weiterhin bestehen, da der Angreifer beim Login keine Daten
verändern braucht, wie es beim Onlinebanking der Fall sein kann. ⇒ R4 würde gelten, da ein
hoher Aufwand betrieben werden müsste.
Kosten des visuellen-PIN:
Die Eingabe der PIN wird komplizierter und dauert länger. Der Benutzer muss die passende Folie
finden und sie über dem Bildschirm halten. Das könnte eine gleichzeitige Benutzung der Tastatur
behindern.
TCO:


Benutzer: Für die Low-Tech Variante würden die Kosten wohl in etwa dem einen normalen
Papier PIN Verfahrens gleichen.
Der Onlinedienst müsste entweder Softwarekomponenten für die Erstellung und Verwaltung
der Bilder sowie deren Darstellung besorgen und die Folien mit der Post verschicken.
Account Recovery:
Wie beim Papier PIN Verfahren müsste man beim Verlust der Folien diese Sperren lassen und neue
zuschicken.
4.1.9
Permutations-PIN51
Beim pPIN -Verfahren gibt man die PIN nicht über die Tastatur ein, sondern man muss auf
Schaltflächen am Bildschirm mit der Maus klicken. Diese sind nicht beschriftet und die Zahlen, die
hinter den Schaltflächen stehen, verändern sich je nach der Reihenfolge auf der Liste, die zusätzlich
indiziert ist.
51
Basiert auf pPIN [Borchert, Knick- und-Klick PIN].
59
Abbildung 57: Beispiel einer indizierten Permutationsliste 52
Ablauf:
Abbildung 58: Loginbeispiel für pPIN
Der Benutzer erhält vom Onlinedienst eine Liste mit nummerierten Permutationsliste (Abbildung 57).
Darauf sind die 10 Ziffern in vertauschter Reihenfolge aufgelistet. Ist der Benutzer nun am
Loginbildschirm (Abbildung 58), so wird er aufgefordert die PIN nach der bestimmten aufgelisteten
Ziffernreihenfolge aus der Liste einzugeben. Dabei kann er die Liste entsprechend knicken, dass er
die passende Permutation direkt unterhalb des Eingabefeldes mit den weißen Feldern für die 10
Ziffern auf dem Bildschirm halten kann. Muss der Benutzer nun seine PIN eingeben, so kann er von
der Liste ablesen, wo die Ziffern seiner PIN auf den weißen Feldern steht und sie dann mit der Maus
anklicken (Abbildung 59).
Abbildung 59: Anwendungsbeispiel mit pPIN
52
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/pPIN/
60
Abbildung 60: Angriffsmöglichkeiten
1. Wie beim klassischen TAN-Verfahren ist auch pPIN anfällig für Phishingangriffe. Damit der
Angreifer sich erfolgreich aber Einloggen kann, braucht er die PIN und auch die pPIN-Liste. ⇒
R1 und R2 gelten eingeschränkt, da die PIN ohne die Liste nutzlos ist. Es erschwert ein wenig
die Arbeit, da man beides braucht.
2. Malware wie Trojaner/Keylogger haben Probleme die PIN auszuspähen, da bei der Eingabe
die Tastatur nicht benutzt, sondern auf dem Bildschirm geklickt wird. Screenshots sind da
auch nicht möglich, da die Felder leer sind. Somit können die Trojaner bei der Eingabe der
PIN diese nicht belauschen. ⇒ R3 gilt.
3. Der Angreifer könnte die Daten zwischen dem Benutzer und dem Onlinedienst mit einem
klassischen Man-in-the-Middle Angriff53 abfangen und manipulieren, so dass der Angreifer
am Ende Zugriff auf den Account hat. ⇒ R4 gilt noch eingeschränkt, da der Aufwand höher ist
als Phishingangriffe oder Trojaner einzusetzen. Für R5 gilt das gleiche wie bei den restlichen
Papierlisten-Verfahren.
Kosten des pPIN:
Benutzerfreundlichkeit/Zeit/Kosten:
Die Eingabe der PIN wird komplizierter und dauert länger. Sie könnte mit dem iiPIN-Verfahren
vergleichbar sein. Auch die Kosten wären ähnlich dem klassischen TAN-Verfahren.
Account Recovery:
Auch hier wäre die Accountwiederherstellung mit dem TAN-Verfahren vergleichbar.
53
Der Angreifer gibt sich dem Onlinedienst als Benutzer aus und dem Benutzer gegenüber als dem Onlinedienst.
61
4.1.10 Bildpasswort-PIN54
Das Bildpasswort-PIN Verfahren ist eine Variante des indirekt indizierten Bild-PIN und des pPINVerfahrens. Man verwendet da eine PIN bzw. Passwort das aus Bildern besteht.
Abbildung 61: Bildpasswort-PIN-Liste 55
Abbildung 62: Bildpasswort
Der Benutzer erhält eine vom Onlinedienst eine nummerierte Bildpasswort-PIN-Liste (Abbildung 61),
die aus zehn unterschiedlichen vertauschten Bilder- und Zifferliste von 0-9 besteht. Er erhält
zusätzlich ein Passwort, das aus einer bestimmten Reihenfolge von unterschiedlichen Bildern besteht,
die auch in der Bildpasswort-PIN-Liste auftauchen (Abbildung 62).
54
55
Basiert auf Bildpasswort-TAN [Borchert, Bildpasswort-TAN Verfahren, 2009].
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/BildpasswortTAN/
62
Ablauf:
In unserem Beispiel hat der Benutzer sich mit seinem Benutzernamen eingeloggt. Im zweiten Schritt
wird er aufgefordert sein Bildpasswort-PIN einzugeben (Abbildung 63).
Abbildung 63: Beispiel eines Überweisungsformulars
In Abbildung 68 soll er die Bild-PIN Nr. 9 eingeben. Diese PIN legt er am Bildschirm unterhalb der
Ziffernleiste von der Anmeldeseite, so dass die Bilder direkt unter der PIN und die Ziffernblöcke
unterhalb der klickbaren Kästchen liegen (Abbildung 64). Der Benutzer überprüft nun sein
Bildpasswort und schaut nach, unter welchen Ziffern sie stehen. So steht der Baum an erster Stelle
des zweiten 5er Blocks aus der Bilderliste. Darüber befindet sich die Ziffer 5 und die befindet sich an
letzter Stelle des 5er Blocks der Ziffer-Liste.
Abbildung 64: Eingabebeispiel
So klickt der Benutzer dann auf das Kästchen, das direkt über der 5 aus der Ziffer-Liste befindet. Er
fährt dann mit dem Bildpasswort fort und sucht nach dem Bären, dem nächsten Bild seines
Bildpasswortes. Der befindet sich direkt unter einer 6. Er klickt dann entsprechend auf das Kästchen
über der 6 von der Ziffer-Liste. Er fährt damit fort, bis er sein Bildpasswort abgearbeitet hat. Ist er
damit fertig, dann kann er mit "Ok" sich dann in sein Account einloggen.


R2 ist vergleichbar mit Bild-PIN/Linien-PIN, da Bilder nicht so einfach weiterzugeben sind,
wenn sie in nicht elektronischer Form wie Scans vorliegen.
R1 und R5 ist vergleichbar mit Bild-PIN/Linien-PIN und gegenüber Trojanern (R3) wie beim
pPIN. Auch hier müsste der Angreifer Liste besitzen und das Bildpasswort kennen.
63

Für R4 gilt das gleiche wie beim pPIN-Verfahren: Es ist anfällig gegenüber Man-in-the-Middle
Angriffen. Es ist aber aufwendiger als Trojaner und Phishingmails zu verbreiten.
Kosten des Bildpasswort-PIN:
Die Benutzerfreundlichkeit, Zeitfaktor und TCO könnten mit den anderen Papier-TAN-Verfahren oder
wie mit Bild-PIN, pPIN, usw. vergleichbar sein.
Account Recovery:
Auch hier muss man die alte Bildpasswortliste sperren und eine neue zuschicken, sollte man sie
verloren haben.
4.2 TAN-Generatoren für Online Account Authentisierung
Neben einer TAN-Liste und dem Verschicken von TANs kann man auch ein Gerät besitzen, welches
TANs elektronisch erstellt. Verschiedene Kreditinstitute benutzen meist ähnliche oder gleiche
Systeme, die unterschiedlich bezeichnet werden. Was sie gemeinsam haben ist, dass man die ECKarte des Kreditinstituts für die Generatoren braucht. Ich werde hier ein paar TAN-Generatoren
vorstellen, die beim Onlinebanking benutzt werden und Beispiele geben, wie man sie auch für
Authentisierungen von Online Accounts benutzen kann. TAN-Generatoren sind
Kennwortgeneratoren, dabei ist jedes generierte Kennwort einmalig. Sie können Zeitgesteuert,
Ereignisgesteuert oder Challenge-Response-gesteuert sein. Moderne Onlinebankingverfahren
versuchen Man-in-the-Middle Angriffe entgegenzuwirken, indem sie Kontodaten bei der Generierung
mit einbinden. Bei Authentisierungen für Online Accounts gibt es aber keine Transaktion, die man vor
Manipulationen schützen muss. Für einen Hacker wäre es uninteressant übertragene Passwörter zu
manipulieren. Darum wäre es möglich bei Authentisierungen von Online Accounts diesen
Zwischenschritt einfach wegzulassen. Als Alternative wäre es auch möglich, wenn man anstatt der
Kontodaten eine zufällig erstellte Nonce vom Onlinedienst benutzt. Damit könnte man ReplayAngriffe entgegenwirken.
4.2.1
eTAN / Token
eTAN Generatoren sind einfache Tokens, die durch eine Zufallszahl eine TAN erzeugen. Sie
unterscheiden sich im Prinzip vom Ablauf und Sicherheit nicht von den herkömmlichen Tokens wie
RSA SecurID. Da sie analog zum RSA SecurID sind, gehe ich hier nicht mehr näher darauf ein. Sie
funktionieren genauso für Onlinebanking.
Abbildung 65: Bankey: Token von der Volkswagenbank
64
Bankey Token wird von der Volkswagenbank benutzt, aber die Gefahr für Man-in-the-Middle
Angriffen für diese Art von Tokens ist für die meisten Banken zu groß, daher wurden verfeinerte
Verfahren erstellt. BW-Bank benutzt TAN-Generatoren der 3. Generation, die ich u.a. im Folgenden
näher beschreiben werde.
4.2.2
eTAN-Plus / BW-Bank TAN-Generator
Die neue Generation von TAN-Generatoren beziehen bei der Berechnung der TAN die Informationen
vom Empfängerkonto mit ein, damit man Man-in-the-Middle Angriffen verhindert. So können
Angreifer die Kontodaten nicht manipulieren. Die BW-Bank und auch die Volkswagen Bank benutzen
deshalb neuere Tokens, die mit Zifferntasten versehen sind, um damit aktuelle Überweisungsdaten
eingeben zu können.
Ablauf bei einer Überweisung:
Der Benutzer muss vor vorher den eTAN-Plus (in Abbildung 66 Bankey genannt) vom Onlinedienst
erhalten und für seinen Account registriert haben. Da jeder Generator einen eigenen Seed besitzt,
mit der man die TAN berechnet, muss der Onlinedienst diesen auch kennen, welche über meist über
die Seriennummer geschieht, die man registriert hat. Auch hat der Generator eine Uhr, die synchron
mit dem Server des Onlinedienstes zur Berechnung der TAN laufen muss.
56
Abbildung 66 : Beispiel von Bankey
Möchte man nun eine Überweisung tätigen (Abbildung 66), so tippt man über die Zifferntastatur des
Generators die Kontonummer des Empfängers mit ein (bzw. die letzten sechs Ziffern, sogenannter
Kontrollcode). Diese werden mit der Erstellung der TAN einbezogen, sodass diese TAN nur für die
Transaktion auf diesen Konto gültig ist. Da die TAN auch zufällig und einmalig erstellt wird, kann man
sie nicht später für Überweisungen auf dasselbe Konto benutzen, sondern muss wieder eine neue
erstellen. Bei der BW Bank TAN-Generator der dritten Generation wird für die Berechnung über eine
Formel, die einen geheimen Schlüssel verwendet auch folgende Informationen verwendet:
Seriennummer des TAN-Generators (benutzerspezifische Information), aktuelle Uhrzeit
(zeitbasierende Daten), 10-stellige Empfänger-Kontonummer (Transaktionsdaten). Für allgemeine
Login-Verfahren sind Transaktionsdaten nicht möglich, aber man könnte abgewandelte Challenge-
56
http://www.volkswagenbank.de/banking/schnupper08/index_vw.php
65
Response Methoden verwenden, indem man z.B. Zufallszahlen, die vom Onlinedienst zugeschickt
werden, eingegeben werden muss.
Als Authentisierung für Online Accounts:
Man könnte das Verfahren auch für eine Zwei-Faktor-Authentifizierung übernehmen, indem man
eine PIN (als Startcode) und einen eTAN-Plus Gerät als Einmalpasswortgenerator benutzt. Möchte
sich der Benutzer also mit einem eTAN-Plus einloggen, dann könnte er als Startcode eine PIN
eingeben. Die daraus erstellte EinmalPIN wird dann an den Onlinedienst übermittelt. Eine weitere
Möglichkeit wäre hier, für den einzugebenden Kontrollcode vom Onlinedienst eine zufällige
einmalige Nonce (z.B. die SessionID) zu erhalten und diese in das eTAN-Plus Gerät einzugeben und
damit die einmal gültige PIN zu erstellen. Dies wäre dann eine Challenge-Response Möglichkeit.
Mögliche Sicherheitsrisikofaktoren für Authentisierung:




Eine mit dem eTAN-Plus Gerät erstellte EinmalPIN wäre nutzlos, da sie nur für eine
bestimmte Zeit gültig ist. So wären Phishingversuche nutzlos und den Account PIN (der
Startcode) zu kennen wäre auch für den Angreifer nutzlos, da er nicht den Generator hat. ⇒
R1 und R2 gilt.
Malware wie Trojaner haben Probleme mit dem Abhören von der EinmalPIN, da sie nur
einmalig gültig ist. Da der Startcode im Gerät selbst eingegeben wird, kann auch ein Trojaner
das nicht abhören. ⇒ R3 gilt.
Da bei Authentifizierungen keine Datenmanipulationen zu erwarten si nd, könnten nach wie
vor Man-in-the-Middle Angriffe darauf abzielen, gefälschte Loginseiten zu erstellen um an
die einmal gültige PIN zu gelangen. Dieser Angriff müsste aber live und somit zeitnah
geschehen. ⇒ R4 gilt, da der Aufwand sehr hoch ist.
Durch Verlust wie Diebstahl des eTAN-Plus Generators hätte der Angreifer Zugang zum
Account, wenn er zusätzlich die PIN kennt. ⇒ R5 gilt, da der Aufwand sehr hoch ist.
Kosten des eTAN-Plus:
Die Einrichtung des Accounts kann länger dauern, da man den Token normalerweise erst besorgen
muss. Entweder erhält man ihn direkt beim Onlinedienst (z.B. bei der Bank) oder er wird mit der Post
verschickt. Mit dem eTAN-Plus kann man von jedem PC aus benutzt werden, doch muss man ihn bei
sich tragen. Da es ein Display und eine Zifferntastenfeld hat, ist nicht so klein wie herkömmliche
Token ohne Zifferntastenfeld, doch sie sollten noch in der Tasche passen. Die Zeit bis man eine
Transaktion durchgeführt hat könnte etwas länger dauern und komplizierter sein wie mit der
klassischen TAN-Liste, da man noch den Kontrollcode eingeben muss bevor man die TAN erhält. Doch
der Benutzer könnte sich daran schnell gewöhnen und entsprechend routiniert eine Transaktion
zügig durchführen.
TCO:

Der Benutzer muss sich den eTAN-Plus Token kaufen und darauf achten, dass die Batterie
innerhalb von 5 Jahren ausgehen kann und sich darum in regelmäßigen Abständen einen
neuen Token kaufen muss. Sonst dürften keine zusätzlichen Kosten anfallen.
66

Der Onlineprovider muss die Tokens herstellen lassen und eine passende
Softwarekomponente besitzen, damit er die TANs in Abhängigkeit von den registrierten
Tokens berechnen und vergleichen kann.
Account Recovery:
Sollte der eTAN-Plus Token verloren gehen, dann hat der Benutzer keine Möglichkeit mehr sich
einzuloggen. Der Token sollte dann gesperrt werden und er muss ein neues Token bestellen. Dies
kann telefonisch oder durch direkten Kontakt, wie z.B. der Gang zur Bank, geschehen.
4.2.3
sm@rt-TAN
Mit dem sm@rt-TAN Verfahren wird zum Faktor Besitz (den TAN Generator) einen weiteren Faktor
Besitz hinzugefügt: Die EC-Karte des Kunden. Damit der Token eine TAN generieren kann, muss man
die EC-Karte des Kunden in den Token einführen. Dann kann man mit einem Knopfdruck eine TAN
anzeigen lassen. Es gibt auch die Möglichkeit mehrere TANs generieren zu lassen, z.B. fünf
gleichzeitig.
Abbildung 67 57: sm@rt-TAN Generator in der die Karte oben eingefügt wird.
Bevor der Benutzer eine Transaktion betätigen kann, muss er den sm@rt-TAN Token und auch eine
Chipkarte vom Onlinedienst besitzen. Im Falle einer Überweisung gibt der Benutzer die
Überweisungsdaten in das Formular auf der Webseite ein und schiebt dann die Chipkarte in den
Token. Auf Knopfdruck berechnet der Generator im Token in Abhängigkeit der eingeführten
Chipkarte eine TAN, die der Benutzer dann zur Bestätigung der Überweisung eingibt.
Im Grunde könnte es wie beim RSA SecurID Token in Verbindung mit einem wiederverwendbaren
Passwort eingesetzt werden: Der Benutzer gibt seinen Benutzernamen und Passwort ein und wird
danach aufgefordert ein Einmalpasswort einzugeben. Der Benutzer erzeugt mit dem Token und der
Chipkarte einen Einmalpasswort und gibt sie dann ein. Als Alternative kann er nur den sm@rt-TAN
Generator zur Authentisierung benutzen: Der Benutzer gibt seinen Benutzernamen ein. Danach wird
er aufgefordert den Einmalpasswort einzugeben. Der Benutzer legt die Chipkarte in das Token ein
und erzeugt damit das Einmalpasswort. Dies gibt er dann auf die Webseite ein.


57
Mit diesem Verfahren erstellt der Benutzer eine einmalige PIN, die er vorher nicht kennt.
Daher sind Brute-Force Angriffe wirkungslos. ⇒ R1 gilt.
Der Benutzer könnte über Phishing Angriffe ausgetrickst werden, gültige TANs
weiterzugeben. ⇒ R2 gilt nicht, da sie einfach generiert und weitergegeben werden können.
http://de.wikipedia.org/wiki/Transaktionsnummer
67



Trojaner könnten mit den eingegeben TANs während der Loginphase bzw. bei der
Überweisung nichts mehr anfangen, da sie nach einmaliger Verwendung nicht mehr gültig
sind. ⇒ R3 gilt.
Es wären Man-in-the-Middle, da man TANs auf Vorrat generieren kann. Die erstellten
Einmalpasswörter haben also keine begrenzte Gültigkeitsdauer. ⇒ R4 gilt eingeschränkt, da
keine aufwendigen Man-in-the-Middle Angriffe notwendig sind.
Der Token ist in diesem Fall nicht wichtig und der Angreifer kann sich einfach eines vom
Onlinedienst besorgen. Aber der Angreifer muss die Karte besitzen bzw. die Information
darauf, mit der die TAN für den Benutzer generiert wird. Sollte der Benutzer die Karte
verlieren und ein Angreifer wäre in Besitz der Karte, dann könnte er sich damit immer
authentisieren, da sie nicht durch eine PIN geschützt ist. ⇒ R5 gilt, da der Aufwand eine Karte
zu beschaffen für den Angreifer groß ist.
Kosten des sm@rt-TAN:
Der Aufwand wäre ähnlich wie mit den vorherigen Verfahren, die einen TAN-Generator benötigen.
Der Benutzer muss aber zusätzlich noch einen weiteren Gegenstand, die Chipkarte, mit sich führen
und jedes Mal den Generator und Karte zusammen benutzen, damit er sich authentisieren kann. Es
kann auf die Dauer etwas lästig sein, wenn man sich oft authentisieren muss und dabei jedes Mal
den Generator und die Chipkarte herausholen muss. Ansonsten ist die Anwendung recht einfach.
TCO:


Für den Benutzer fallen ähnliche Kosten wie beim vorherigen Verfahren an. Nur muss er
zusätzlich noch eine Chipkarte besorgen.
Auch für den Onlinedienst dürften die Kosten neben der zusätzlichen Chipkarte nicht viel
weiter steigen, wie beim vorherigen Verfahren.
Account Recovery:
Sollte der Benutzer seinen Generator verlieren, dann müsste er sich eine neue besorgen, aber eine
Sperrung des Accounts wäre nicht nötig, solange er die Chipkarte noch besitzt. Sollte der Benutzer
aber die Chipkarte verlieren, dann müsste diese gesperrt werden und bis er eine neue erhalten hat,
kann er seinen Account nicht mehr benutzen. Die Accountwiederherstellung könnte genauso
ablaufen wie beim vorherigen Verfahren.
4.2.4
sm@rtTAN-Plus/chip TAN manuell
sm@rtTAN-Plus bzw. chip TAN Verfahren ist eine Kombination aus sm@rt-TAN und eTAN-plus. Dabei
wird ein Generator benötigt, der nur mit einer EC-Karte funktioniert und gleichzeitig die aktuellen
Transaktionsdaten für die TAN Generierung benötigt. Damit sollen Manipulationen von
Überweisungsdaten verhindert werden.
Möchte man eine TAN generieren, dann muss man die EC-Karte in das Lesegerät einführen. Danach
muss man z.B. wie bei der Volksbank die Kontonummer (Startcode), BLZ des Empfängers und Betrag
der Überweisung in das Lesegerät über die Ziffertaste eingeben. Danach wird dann eine TAN für die
Überweisung generiert. Damit kann er dann die Transaktion durchführen lassen.
68
Abbildung 68: ChipTAN Generator genannt tanJack® optic SR von der Kreissparkasse Freudenstadt
Hier wäre der Ablauf der gleiche wie für die Authentisierung mit einem eTAN-Plus. Nur das man hier
noch zusätzlich eine Chipkarte in das Lesegerät einführen muss, damit er den Einmalcode erstellt.


Die Sicherheit R1-R4 gegenüber der TAN, Phishing, Trojaner und Man-in-the-Middle
Angriffen ist mit der vom eTAN-Plus vergleichbar.
R5 wäre auch mit sm@rt-TAN vergleichbar: Nur wenn der Angreifer in Besitz eines
Lesegeräts und der Chipkarte ist, kann er Einmalpasswörter ohne Probleme generieren. Man
könnte die Sicherheit erhöhen, wenn man vorher eine PIN auf dem Generator eingeben muss,
die die Chipkarte schützt.
Kosten des sm@rtTAN-Plus:
Die Eingabe der TAN ist ähnlich umständlich (mehrmalige Eingabe nötig) wie beim eTAN-Plus. Das
kann die Dauer verlängern, bis man sich authentifiziert hat. Der Aufwand dürfte sich dem des eTANPlus und sm@rt-TAN ähneln.
TCO:
Die Kosten für Benutzer und Dienstanbieter dürften ähnlich dem des sm@rt-TAN Verfahren sein.
Account Recovery:
Für die Accountwiederherstellung beim Verlust der Chipkarte und dem Lesegerät sollte es keinen
Unterschied wie beim sm@art-TAN oder vergleichbaren Verfahren geben.
4.2.5
sm@rt optic (Flickering)/chipTAN comfort
Bei der Volksbank wird dieses Verfahren auch einfach sm@rtTAN-Plus58 genannt oder gehört auch
bei der Kreissparkasse zum chipTAN59 . Die manuelle Eingabe ist eine Alternative, die sie anbieten, da
das Ablesen eines flackernden Bildschirms in manchen Situationen nicht möglich ist (z.B. über zu
kleine Bildschirme wie bei einem Handy). Das optische Verfahren soll die Generierung komfortabler
gestalten, da man nicht mehr die benötigten Transaktionsdaten mit der Hand eingeben muss. Von
der Sicherheit her sollte sie nicht größer als beim sm@rtTan-Plus sein. Der TAN-Generator besitzt
einen Display, Ziffern- und Funktionstasten, optische Sensoren und einen Scanner zum Einlesen einer
EC-Karte.
58
59
http://www.smart-tan-plus.de/
https://www.ksk-fds.de/module/fds_bookmark/tangen/index.php?IFLBSERVERID=IF@@021@@IF
69
60
Abbildung 69 : Sm@rt-TAN plus Gerät der Volksbank
Hat der Benutzer alle Daten für eine Überweisung eingegeben, erscheint auf dem Bildschirm eine
blinkende Animation bestehend aus 5 weißen Balken auf schwarzem Hintergrund.
Abbildung 70 61: Erzeugung eines TANs einer Sparkasse mittels chipTAN comfort
Die optischen Sensoren müssen nun zum Einlesen schräg an die Animation gehalten werden. Durch
die Lichtsignale werden die Transaktionsdaten (Kontonummer des Empfängers, Überweisungsbetrag)
und ein Startcode bzw. eine verschlüsselte TAN übertragen. Die Transaktionsdaten werden auf dem
Display angezeigt und müssen bestätigt werden. Danach wird die TAN berechnet und angezeigt, die
man dann eingeben muss, damit die Buchung durchgeführt wird.
Für eine Authentisierung mit einem Einmalpasswortgenerator in Kombination mit einem
Flackercodelesegerät wäre eine Challenge-Response Erstellung denkbar:
Der Benutzer loggt sich z.B. mit einem Benutzernamen und Passwort ein. Dann erscheint eine
Bestätigungsseite mit einem Flackercode und der Benutzer muss sein Lesegerät an den Monitor
halten. Davor setzt er seine Chipkarte in das Lesegerät und aktiviert es mit der PIN für die Chipkarte.
Der Flackercode kann neben verschiedene Informationen wie die IP Adresse, Zeit/Datum usw. auch
eine Nonce enthalten, die als einmaliger Startcode dient. Das Lesegerät liest die Informationen ab
und kann sie auf ein Display darstellen. Hat der Benutzer die dargestellten Informationen bestätigt,
dann erscheint ein Einmalpasswort, den er als Bestätigung eingeben muss. Danach ist er auf sein
Account eingeloggt.
60
61
70
Mögliche Sicherheitsrisikofaktoren für Authentisierungen:






R1 gilt, da ein Einmalpasswort erzeugt wird. Dies kann kein Angreifer erraten.
R2 gilt, da Phishingversuche in dem Fall kaum möglich wäre: Bei einer Generierung eines
Einmalpasswortes wird jedes Mal der Flackercode benötigt. Auch wären Einmalpasswörter
nur für eine bestimmte Zeit gültig, bzw. die Nonce, die man vom Onlinedienst benötigt. Das
einzige was ein Angreifer vom Benutzer herausfinden könnte, wäre die PIN für die Chipkarte.
Und sie wäre ohne die Chipkarte nutzlos.
Trojaner könnten die PIN für die Chipkarte nicht abhören, da sie nicht am PC sondern direkt
am Lesegerät eingegeben wird. Den Einmalpasswort könnte man abhören, wäre aber nach
der einmaligen Anwendung bereits ungültig. ⇒ R3 gilt.
Zeitgleiche Man-in-the-Middle Angriffe wären nach wie vor denkbar. ⇒ R4 gilt, da solche
Angriffe mit hohem Aufwand verbunden sind.
Sollte ein Angreifer die Chipkarte in seinen Besitz bekommen, dann könnte er damit und
einem Lesegerät Einmalcodes generieren. So ist R5 genauso sicher wie beim vorherigen
Verfahren. Sie kann erhöht werden, wenn die Chipkarte zusätzlich mit einer PIN geschützt
wird.
Die Sicherheit sollte aber mindestens so hoch wie bei einer iTAN- Listen sein und ist mit dem
des sm@rtTAN-Plus vergleichbar.
Kosten des sm@rt optic:
Vom Aufwand, Zeit und TCO her könnte sie mit den vorherigen Verfahren ähnlich sein. Man muss die
Chipkarte und das Lesegerät bei sich führen und diese dann am Monitor zum Ablesen davor halten.
Probleme kann es geben, wenn das Lesegerät den Code nicht ablesen kann (z.B. bei kleinen
Bildschirmen wie Handys usw.). Ansonsten ist das Verfahren für den Benutzer in der Hinsicht
einfacher, da er die Transaktionsdaten nicht eingeben muss, aber sie trotzdem eingeben kann und
die TAN davon abhängig ist.
Account Recovery:
Die Accountwiederherstellung ist auch hier mit den vorherigen Verfahren vergleichbar.
4.3 Fazit Onlinebankingverfahren als Authentisierungsverfahren für
Online Accounts
Wie wir gesehen haben, lassen sich alle TAN-Verfahren auch für Authentisierungsverfahren für
Online Accounts umwandeln.. Es macht eigentlich keinen Unterschied, ob man eine Transaktion oder
ein Account bzw. Benutzername authentisieren möchte. Modifizierte Methoden, die auch die
Transaktionsdaten mit einbeziehen, können auch für Accounts genutzt werden, z.B. in Form einer
Nonce. Ansonsten kann man diese auch ignorieren, da man für Authentisierungen von Online
Accounts keine Transaktionen absichern muss. Im Gegensatz zu Geldüberweisungen, bringt es einem
Angreifer nicht, wenn er das Passwort manipuliert. Das Ziel des Angreifers ist es, das für den
Zeitpunkt gültiges Passwort zu finden. Und das wird mit Hilfe des Besitzfaktors erschwert. Dabei
haben die Verfahren alle gemeinsam, dass der Benutzer eine einmalige Antwort in Form eines
Einmalpassworts beantworten kann. Der Unterschied zwischen den Verfahren ist, wie sie diese
Antwort erstellen. Ein weiterer Unterschied zwischen den einzelnen Besitzfaktoren ist die benutzte
71
Technik: Low-Tech und High-Tech. Dabei sind die Low-Tech Verfahren Methoden, die z.B. mit Listen
auf bedrucktem Papier basieren und High-Tech Verfahren basieren auf elektronische Geräte.
Die Papier-TAN Verfahren gehören also zu den Low-Tech Verfahren und besitzen folgende Merkmale:


Gemeinsamkeiten:
o Liste von endlichen Einmalpasswörtern
Unterschied:
o Passwortauswahl, wie z.B. PIN, Bilder usw.
o Abfrageart:
 Direkt
 Mit oder ohne Index
 Indirekt
 Über eine Permutationsliste
Was die Verfahren angeht, die auf der indirekten Passworteingabe basieren62 , so ist die Grundidee
dabei, dass das eigentliche Einmalpasswort permutiert und abhörsicher eingegeben wird, sei es über
andere Zeichen wie Bilder oder nicht angezeigten Zifferntasten. Bei den TAN-Verfahren, mit der man
das Passwort indirekt eingibt, ist es auch möglich sie von einem Ein-Faktor-Verfahren in ein ZweiFaktor-Verfahren umzuwandeln. Dabei kann man seinen wiederverwendbaren Account Passwort nur
mit der Liste korrekt eingeben, die das Passwort entsprechen korrekt permutiert und umwandelt. So
ist die Liste ohne den Account Passwort nutzlos und auch der Account Passwort alleine kann ohne die
Liste nichts machen. Da die Eingabe des wiederverwendbaren Passworts jedes Mal anders ist und
somit das eingegeben Passwort beim nächsten Mal nicht mehr gültig ist, ist es mindestens so sicher
wie ein einfaches TAN-Verfahren mit einer iTAN-Liste. Dabei lassen sich die Zwei-Faktor-Verfahren
wieder in feinere Gruppen einteilen. Darauf werde ich aber später eingehen.
Sicherheit von Low-Tech Verfahren:



Die Einmalpasswörter sind gegen Trojaner insofern sicher, da sie zwar abgehört werden
können, aber im Prinzip dann nicht mehr gültig sind.
Man kann mit den Low-Tech Verfahren Phishingangriffe nur erschweren, aber nicht
verhindern. Der Grund liegt darin, dass die Einmalpasswörter, in welcher Form auch immer,
in gedruckter Form, z.B. auf einer Liste, vorhanden sind. Mit großem Einfallsreichtum können
Benutzer immer noch dazu gebracht werden umständlich 100 Einmalpasswörter einzugeben
oder sogar eine Liste zu scannen und dann weiterzugeben.
Erfolgreiche Man-in-the-Middle Angriffe sind in einigen Fällen nur mit einigem Aufwand
verbunden.
Eine höhere Sicherheit versprechen die High-Tech Lösungen. Durch den technischen Fortschritt ist
man nun auch in der Lage tragbare Geräte herzustellen, die in Echtzeit Einmalpasswörter generieren
können. Dabei basieren sie auf Einmalfunktionen, d.h. man kann mit Hilfe eines Geheimnisses schnell
etwas berechnen, aber ohne das Geheimnis die Umkehrfunktion nur schwer herausfinden. Der
Vorteil von Einmalpasswörtern, die in Echtzeit erstellt werden und dann nur für kurze Zeit gültig sind
ist der, dass sie für Phishingangriffe uninteressant sind. Man kann sie nicht weitergeben. Auch
Trojaner könnten mit den abgefangenen Passwörtern nichts anfangen und nur Angriffe, die große
62
iiPIN, iiBild-PIN, Cardano-PIN, Linien-PIN, vPIN, pPIN, BildpasswortPIN
72
technisches Können voraussetzen, wie Echtzeit Man-in-the-Middle Angriffe, wären da erfolgreich.
Der Nachteil aller Low-Tech und High-Tech Authentisierungen ist, dass man etwas herumtragen und
dabei haben muss, um sich überall authentisieren zu können. Die Benutzerfreundlichkeit der
Authentisierungsverfahren ist dabei unterschiedlich und je sicherer man sie machen möchte, desto
Benutzerunfreundlicher können sie werden. Sie sind deshalb meistens eine optionale Lösung für
Onlinedienste und werden nicht verpflichtend für Authentisierungen eingesetzt. Jedoch entstehen
durch den technischen Fortschritt und deren Verbreitung, wie z.B. Handys oder Smartphones, neue
Einsatzmöglichkeiten. So könnten in der Zukunft günstige und einfache Verfahren entwickelt werden.
Die Verfahren an sich ähneln sich meistens und benötigen z.B. gleiche Hardwarevoraussetzungen
(Abbildung 71) oder sie bauen z.T. aufeinander auf und werden verbessert, damit sie bestimmte
Angriffe (z.B. Man-in-the-Middle) entgegenwirken können. Sie können sich dadurch unterscheiden,
mit welcher Technik (z.B. Chipkarte oder Handy) und welchem Verschlüsselungsverfahren sie sich
authentifizieren (z.B. symmetrisch oder Public Key). Verfahren wie RSA SecurID Tokens sind bisher in
der Praxis nicht so leicht zu knacken, so dass nun auch verstärkt die Server, wo die sogenann ten
Seeds gespeichert sind, Ziele von Angriffen sind.
73
Abbildung 71: Hardwarev oraussetzungen von Authentisierungsverfahren
74
5 Zwei- Wege-Kommunikation Authentifizierung
Hier werden ein paar Authentisierungsverfahren vorgestellt, die eine Zwei -Wege-Kommunikation
benutzen. Dabei wird nicht nur über eine gleiche Verbindung kommuniziert, sondern auch mit einer
anderen, damit man sie nicht so leicht belauscht werden kann. Dies wurde mit der großen
Verbreitung von Handys erleichtert, da in Deutschland die Handynetze sehr gut ausgebaut wurden.
5.1 mTAN, smsTAN
mTAN (Mobile TAN) oder smsTAN benutzt keine TAN-Liste mehr, sondern sendet pro Überweisung
eine TAN mit einer SMS an ein Handy. So wird in Echtzeit über einen zweiten Weg zwischen einem
Benutzer und seinem Onlinedienst kommuniziert. Es ist eine Kombination aus Zwei-Faktor und ZweiWege Authentifizierung. Man benötigt neben einer PIN auch ein Handy und es werden
unterschiedliche Kommunikationswege, dem Internet- und die Handykommunikationsweg via SMS
benutzt. Das Verfahren wird bereits für Authentisierungen von Online Accounts von SMS PASSCODE63
angeboten. Sie unterscheidet sich vom Prinzip her nicht vom mTAN-Verfahren. Der Unterschied
zwischen den Verfahren ist, dass beim mTAN noch zusätzlich neben der TAN auch
Überweisungsdaten per SMS geschickt werden. Auch Google unterstützt das Verschicken von zeitlich
begrenzten Passwörtern und ich werde später bei der Vorstellung des Google Anmeldeverfahrens
den Ablauf nochmals näher für Online Accounts beschreiben. Neben SMS PASSCODE bieten auch
eKaay64 und CrontoSign von Cronto Limited65 ein vergleichbares Verfahren an, um Angriffe zu
verhindern. Dabei wird auch ein 2D Bild über ein Smartphone mit einer Fotokamera (mit dem
installierten App) oder dem CrontoSign Optical Device gescannt und es erscheint danach dann eine
TAN und die Buchungsdaten der Überweisung auf dem Display des Gerätes. Man kann dann die
Überweisung bestätigen, indem man die TAN vom Handy auf die Webseite eingibt. Der Unterschied
zwischen eKaay und Cronto ist, dass die TAN bei Cronto angezeigt und dann auf die Webseite
eingegeben werden muss. eKaay dagegen erstellt keine Einmalpasswörter in Form einer TAN,
sondern benutzt einen geheimen Schlüssel um mit einer Response auf eine Challenge zu antworten.
CrontoSign ist eine Mischung zwischen mTAN und eKaay und da die Sicherheit und der Ablauf mit
sm@rtTAN optic ähnlich ist, werde ich auch nicht auf CrontoSign näher eingehen. eKaay werde ich
später vorstellen. mTAN ist eines der ersten praktischen Anwendungen für Zwei-WegeKommunikation und werde es hier vollständigkeitshalber kurz vorstellen.
63
http://www.smspasscode.com/
http://www.ekaay.com/TAN/
65
http://www.cronto.com/
64
75
Ablauf:
Abbildung 72: Möglicher Kommunikationsablauf mit mTAN
Beim Onlinebanking wird nachdem Einloggen mit einer Benutzer ID und dem PIN (1) eine
Überweisung betätigt (2). Er wird aufgefordert eine TAN einzugeben. Es erscheint dann eine SMS mit
den Überweisungsdetails und einer TAN auf dem Handy (4). Dies geschieht über einen anderen
Kommunikationskanal, mit dessen Provider der Onlinedienst verbunden ist (3). Der Benutzer muss
man dann die erhaltene TAN eingeben um die Buchung durchzuführen (5).
Der Verlauf um sich damit einzuloggen wäre sehr ähnlich: Der Benutzer würde sich wie gewohnt mit
einem Benutzernamen einloggen (1). Der Benutzer wird dann aufgefordert ein Einmalpasswort
einzugeben. Der Onlinedienst findet über den Benutzernamen die Handynummer heraus und sendet
ein Einmalpasswort an die Handynummer über seinen GMS/UMTS Provider (3). Der GMS/UMTS
Provider verschickt das Einmalpasswort auf das Handy (4) und der Benutzer gibt das empfangene
Einmalpasswort in den Browser ein um den Loginvorgang abzuschließen (5).
Mögliche Sicherheitsrisikofaktoren bei Authentisierungen:
R1 gilt, da ein Angreifer ein einmal gültiges zufällig erstelltes Passwort normalerweise nicht
rechtzeitig herausfinden kann.
Abbildung 73: Risiken beim mTAN
76
1. Der Benutzer selber kann das Einmalpasswort normalerweise nicht bei einem
Phishingversuch weitergeben, da sie vom Onlinedienst nur verschickt wird, wenn er sie
benötigt und keine auf Vorrat gespeichert hat. ⇒ R2 gilt.
2. Sollte das Einmalpasswort über einen Trojaner abgefangen worden sein, dann ist sie
normalerweise nicht mehr zu gebrauchen, da sie nur einmal verwendet werden kann. Manin-the-Middle Angriffe über manipulierte und vorgetäuschte Webseiten (XSS) müssten
zeitgleich und parallel ablaufen, da die SMS über einen anderen Kanal verschickt wird und
nur eine begrenzte Zeit gültig ist. ⇒ R3 und R4 gilt, da Man-in-the-Middle Angriffe hier sehr
aufwendig sind.
3. Mit einem gestohlenen oder verlorenen Handy könnte der Angreifer ohne Probleme sich auf
ein Account einloggen. Ein Verlust des Handys wird aber normalerweise vom Benutzer
schneller erkannt, wie z.B. der Verlust einer Einmalpasswort Liste oder Generators. Auch
Viren für Smartphones oder Handys könnten Einmalpasswörter abfangen und so dem
Angreifer ein zeitnahes einloggen ermöglichen. Es würde auch die Gefahr bestehen, wenn
man z.B. es in der Accountverwaltung schafft, die Handynummer zu verändern. Angreifer
könnten auch versuchen an die SIM Karte zu kommen, indem sie beim Mobilfunkanbieter
sich als den Handybenutzer ausgeben und eine neue SIM Karte anfordern. ⇒ R5 gilt, da es
normalerweise einen hohen Aufwand braucht um an ein Handy zu gelangen.
Kosten der mTAN:
Man braucht keine TAN-Liste mitzuführen, ein Handy hat mein meistens immer dabei und ist somit
flexibler was die Orte angeht, wo man sich einloggen kann. Je nach Empfangsleistung könnte es sein,
dass man eine SMS aber nicht erhält oder verloren geht.
Zeitfaktor:
Die Zeit zum Einloggen kann aber etwas länger dauern, da man auf die SMS warten muss.
Kostenbereich TCO:


Es können keine zusätzlichen Kosten für den Benutzer auftreten, außer dass er ein SMSfähiges Handy besitzen muss. Falls die SMS Kosten an den Benutzer weitergeleitet wird, dann
können die mit der Anzahl des Einloggens und des Aufenthaltes (wenn man im Ausland ist)
schwanken.
Für den Onlinedienst müssen zusätzliche Strukturen und Serverkomponenten bereitgestellt
werden um TANs zu generieren und sie als SMS abzuschicken. Zusätzlich fallen die SMS
Kosten für den Versand an.
Account Recovery:
Bei Verlust von Handy oder Änderung der Handynummer müsste man diese zuerst sperren lassen
und dann eine neue Nummer dem Onlinedienst weitergeben. Bis dahin könnte man sich nicht auf
den Account einloggen.
77
5.2 eKaay
Mit dem eKaay Loginverfahren [Borchert, eKaay - Mit dem Handy einloggen, statt mit Passwort]
verwendet man anstatt Benutzernamen und Passwort ein Handy bzw. ein IPhone/Android
Smartphone mit einem eKaay App zur Authentisierung. Das Passwort bzw. der Schlüssel66 wird dabei
auf dem Smartphone abgelegt. Es wurde an der Universität Tübingen entwickelt und wird seit 2011
auch vom Webmaildienst der Universität Tübingen67 genutzt. Der Name ist vom friesischen "Kaay"
abgeleitet und bedeutet Schlüssel. Außerdem bedeutet eKaay auf Chinesisch ausgesprochen "leicht
zu öffnen".68 eKaay soll den Benutzer das Einloggen vereinfachen, da der Benutzer kein Passwort
und Benutzernamen (d.h. seine verschiedene Identitäten für alle Accounts) mehr merken muss. Das
Verfahren wurde so entwickelt, dass es die Methode der Authentisierung z.B. über ein Passwort
ersetzen soll und richtet sich hauptsächlich an Accounts für Webseiten. So kann es auf beliebige
bereits existierenden Architekturen mit eingebunden und auch bei Single Sign On Verfahren
eingesetzt werden. Das Verfahren könnte man als Authentifizierung über Zwei-WegeKommunikation ansehen, da das Handy einen zweiten unabhängigen Kommunikationsweg benutzt
um sich mit dem Onlinedienst bzw. dem Account-Server oder eKaay-Server zu verbinden. Dabei wird
nur vorausgesetzt, dass man ein Handy besitzt, auf der die eKaay App läuft. Unter anderem werden
IPhones und Android Smartphones unterstützt. Muss man für die Verwendung des Apps vorher eine
PIN/Passwort eingeben, dann könnte man auch von einer unabhängigen Zwei-FaktorAuthentisierung sprechen, wobei das Handy mit dem App und dem dort gespeichertem geheimen
Schlüssel der Besitz wäre und die PIN/Passwort das Wissen. Müsste man eine PIN/Passwort im Handy
eingeben um die App freizuschalten, dann wäre es eine weitere Form69 der Zwei-FaktorAuthentifizierung, bei der nicht der Account sondern der Schlüssel geschützt wird. Würde man den
geheimen Schlüssel auf einer RFID-Karte abspeichern und sie muss mit einer PIN über ein NFCfähiges Handy abgerufen werden, dann wäre es eine Kombination aus Zwei-Faktor und Zwei-WegeKommunikation Authentifizierung (RFID Schlüsselkarte als Besitz und PIN als Wissen sowie Handy als
zweiter Kommunikationsweg). Da zurzeit der Schlüssel auf dem Handy gespeichert ist und man sich
nur mit dem Handy einloggen kann, mit dem man sich für sein Account registriert hat, ist es ein
Verfahren, dass vom Besitz (dem Handy des Benutzers) abhängt, jedoch auch einen zweiten
Kommunikationsweg benutzt.
66
In AES Verfahren verschlüsselt.
http://www.zdv.uni-tuebingen.de/dienstleistungen/Sonstiges/Anleitungen/eKaay-Login/
68
http://www.ekaay.com/
69
Eine abhängige Zwei-Faktor-Authentifizierung, auf die ich später näher eingehen werde.
67
78
Ablauf:
Der Benutzer muss vorher bereits einen Account auf dem Onlinedienst besitzen und dort die
Möglichkeit sich mit eKaay anzumelden in seinem Account aktiviert haben. Während der Aktivierung
von eKaay wird einmalig ein geheimer Schlüssel zwischen dem App und dem eKaay-Server vereinbart
und ausgetauscht. Das Verfahren basiert also auf eine symmetrische Verschlüsselung (AES Verfahren).
Der vereinfachte Ablauf in Abbildung 74 (Onlinedienst ist zugleich eKaay- bzw. Accountserver) kann
folgendermaßen aussehen und hat das Challenge-Response Verfahren als Grundlage: Der Webserver
stellt eine Challenge, die der Benutzer anhand seines geheimen Schlüssels mit einer Response
antwortet.
Abbildung 74: Funktionsablaufbeispiel mit eKaay
1. Der Onlinedienst stellt den 2D Code auf seiner Loginseite. Möchte sich der Benutzer mit dem
Browser auf seinem Rechner einloggen, dann sieht er den 2D Code. Im 2D Code steht der
Name des Accountservers und eine Session-ID.
2. Der Benutzer nimmt nun sein Smartphone und startet die App eKaay. Das Programm scannt
den 2D Code ein und berechnet mit einem geheimen Schlüssel des Benutzers, der im
Smartphone abgespeichert ist, und der Session-ID ein Codewort.
3. Das eKaay App verschickt dann die Session-ID, Benutzernamen und Codewort über das
Handy per Internet an den Accountserver, der dann die Daten überprüft und dann die
Webseite freischaltet, falls alles korrekt ist.
79
Abbildung 75: eKaay Funktionsablaufbeispiel mit SSO
In Abbildung 75 wird der Ablauf nun mit der getrennten Darstellung eines eKaay-Servers und einem
Account-Server dargestellt, die die Authentifizierung vornehmen und der Onlinedienst, der nur den
Webserver bereitstellt.
1a. Der Onlinedienst bietet auf seiner Webseite den Rahmen für die Anmeldung auf seiner
Anmeldeseite an.
1b. Der eKaay-Server stellt den 2D Code usw. für die Authentisierung auf der Anmeldeseite
bereit.
2. Mit dem eKaay App auf dem Smartphone fotografiert der Benutzer den 2D Code ein.
3. Der eKaay App authentisiert sich am eKaay-Server.
4. Der eKaay-Server authentifiziert den Benutzer und autorisiert es beim ID Server.
5. Der ID Server teilt es dem Onlinedienst mit, der dann den Benutzer einloggen lässt.




Der Schlüssel ist sicher, da er im AES Verfahren mit mindestens 128 Bit verschlüsselt ist.
Damit würden Brute-Force Angriffe zu lange dauern. ⇒ R1 gilt.
Phishingangriffe wären nutzlos gegen den Benutzer, da der Benutzer kein Geheimnis, wie z.B.
ein Passwort weitergeben kann. ⇒ R2 gilt.
Viren und Trojaner auf Smartphone können gefährlich werden. Sie könnten u.a. versuchen
den gespeicherten Schlüssel zu stehlen oder Anfragen und Antworten umleiten bzw. abhören.
⇒ R3 gilt, da der Aufwand zurzeit sehr hoch wäre.
Eine Mischung aus XSS und Man-in-the-Middle Angriffen könnten gefährlich werden, indem
man ein falsches 2D Bild mit veränderten Daten auf der Loginseite einfügt und wenn der
Benutzer sein Handy nimmt und den veränderten 2D Code einscannt, dann somit den
falschen Account freischaltet. Der Benutzer muss das nicht merken, falls dann eine
Fehlermeldung vom Angreifer auf der Webseite erscheint. ⇒ R4 gilt, da der Aufwand sehr
hoch wäre und der Angreifer nicht den Schlüssel erhält.
80


Je nachdem, wie sich das Handy in das Internet verbindet, kann es zu weiteren Risiken führen.
Sollte sich das Handy über ungesichertem WLAN in das Internet verbinden, dann könnte man
die Kommunikation abhören. Daher sollte eine sichere Verbindung zwischen dem App und
dem Server aufgebaut sein.
Verlust des Handys: Verliert der Besitzer sein Handy und ist die App nicht geschützt, dann
kann der Finder sich damit auf alle seine Accounts einloggen. Man kann das Risiko verringern,
indem man die App mit einer PIN schützt oder den geheimen Schlüssel auf einer Smartcard
abspeichert, der von einem NFC-fähigem Handy ausgelesen werden kann. ⇒ R5 gilt, da der
Aufwand sehr hoch wäre.
Kosten eines Verfahren:
Wurde in der Accountverwaltung die Verwendung aktiviert, dann ist die Benutzerfreundlichkeit hoch,
da man keine Passwörter und Benutzernamen mehr merken muss. Der Benutzer muss nur das
Smartphone bei sich haben um sich zu registrieren. Und normalerweise führt man ein Handy immer
mit. So kann man sich an beliebigen Orten einloggen ohne sich vor Trojaner fürchten zu müssen.
Zeitfaktor:
Bis man das Smartphone und die App aktiviert hat, kann es länger dauern, als wenn man in der
Zwischenzeit das Passwort eingibt. Auch kann es von der Fähigkeit des Handys abhängen, wie schnell
man den 2D Code einscannt und die Daten verschickt. Es sollte aber mindestens genauso schn ell sein,
wie die Authentisierung über eine iTAN-Liste.
TCO:


Vom Benutzer her braucht es keine zusätzlichen Kosten, sofern er ein Handy besitzt, auf dem
die eKaay App läuft.
Der Anbieter muss neben seinen bisherigen Authentifizierungssystemen zusätzlich noch
einen eKaay Server und eKaay Proxyserver anschaffen.
Account Recovery:
Verliert der Benutzer sein Smartphone, dann kann er sich damit nicht mehr einloggen. Unterstützt
der Onlinedienst noch die Loginmöglichkeit über Benutzername und Passwort, dann kann sich der
Benutzer darüber einloggen und sein Smartphone dann in der Accounteinstellung sperren, indem er
die eKaay Möglichkeit deaktiviert. Es kann auch die Accountwiederherstellungsmethode des
Passwortverfahrens bzw. des mTAN Verfahren angewandt werden.
5.3 Google Sesame
Im Dezember 2011 hat Google ein experimentales Projekt mit dem Namen Google Sesame getestet,
die am 17. Januar wieder abgeschaltet wurde [Eikenberg, "Sesam öffne dich" statt Passwort, 2012].
Die Idee dabei war, dass man sich auf fremde Rechner abhörsicher einloggen kann.
81
Ablauf:
Abbildung 76: Kommunikationsablauf mit Google Sesame
Der Benutzer geht über den Browser des PCs auf die Loginseite und sieht dort ein QR Code (1).
Diesen Code kann der Benutzer anhand eines Barcodescanner oder QR Scanner Apps mit seinem
Kamerahandy abfotografieren und auf dem Handy wird dann eine Anmeldeseite geöffnet (2), in der
sich der Benutzer dann mit seine Anmeldedaten eingeben kann (3). Diese Daten werden dann über
das Handy Auf dem Rechner übertragen (4) und auf dem Rechner wird dann eine Seite geöffnet in
der er eine Sicherheitsabfrage beantworten muss (5). Danach gelangt der Benutzer dann auf seine
gewünschte Seite, z.B. Google-Mail70 .




70
R1 gilt eingeschränkt sicher, da der Account nach wie vor mit einem Passwort abgesichert ist.
Daher hängt die Sicherheit von der Stärke des Passworts ab.
R2 gilt nicht, da die Benutzerdaten leicht durch Phishingangriffe weiterge geben werden
können. Gelangt das Passwort z.B. über Phishing in die Hände des Angreifers, dann kann er
sich ohne Probleme einloggen.
Die Passwortsicherheit wird eigentlich nicht erhöht, sondern nur verlagert. Anstatt die
Eingabe der Anmeldedaten direkt am Rechner geschehen zu lassen, werden sie indirekt auf
das mobile Gerät eingegeben. Der einzige Vorteil ist, dass die Anmeldedaten nicht über einen
Keylogger auf dem Rechner abgehört werden kann. So wären die Anmeldedaten vor Trojaner
geschützt. Aber sie könnten weiterhin eventuell mit einem Trojaner auf dem Smartphone
abgehört werden. Daher gilt R3 eingeschränkt, da bisher die Gefahr von Handyviren nicht so
hoch sind, wie auf PCs.
Über XSS und Man-in-the-Middle Angriffe wäre es möglich, den Benutzer über falsche QR
Codes auf eine Seite des Angreifers zu führen, wo der Angreifer dann die Anmeldedaten vom
Benutzer erhalten kann. Der Aufwand würde sich für normale Accounts normal nicht lohnen.
Daher würde R4 hier eingeschränkt gelten, aber mit einem erfolgreichen Angriff hätte man
die kompletten Daten.
http://www.golem.de/1201/89109.html
82

R5 gilt, da das Passwort entweder auf dem Server gespeichert oder normalerweise vom
Benutzer auswendig gelernt wurde. Die Sicherheit des Passworts ist nicht vom Handy
abhängig. Man kann jedes Fotohandy benutzen, die entsprechend den QR Code ablesen
können.
Der Benutzer muss eigentlich nichts machen. Er braucht nur ein Handy, auf dem ein App läuft, der
den QR Code ablesen kann.
Zeitfaktor:
Die Anmeldung würde im Vergleich eines TAN Verfahrens oder eKaay bzw. mTAN Verfahrens länger
dauern, da der Benutzer zuerst auf einen nicht gerade großen Handydisplay sich anmelden und
danach noch auf dem PC die Sicherheitsabfrage beantworten muss.
TCO:


Vom Benutzer her braucht es keine zusätzlichen Kosten, sofern er ein Handy besitzt, auf dem
ein passendes App läuft.
Der Onlinedienst müsste die Anmeldeseite anpassen und Software hinzufügen, die die
Anmeldungen über Handys erkennen können und die Sicherheitsabfrage dann hinzufügt.
5.4 eKaayPIN mit Zwei-Wege-Kommunikation Authentifizierung
In Kapitel 6 stelle ich das zurzeit verwendete eKaayPIN Verfahren als Zwei-Faktor-Authentifizierung
vor, in der das Handy als Besitzfaktor angesehen werden kann, da dort der geheime Schlüssel
gespeichert ist und die PIN als Wissensfaktor eingesetzt wird. Da diese Variante eine Registrierung
voraussetzt in der der geheime Schlüssel ausgetauscht wird, stelle ich hier eine Möglichkeit vor, in
der man keine Registrierung bzw. geheimen Schlüssel benötigt. Da man hierfür jedes beliebige Handy
benutzen kann, auf der das eKaay App läuft, ist es keine Zwei-Faktor-Authentifizierung mehr, da man
sich auf dem Account nur noch mit der PIN authentisiert. Aber die Grundidee, die PIN abhörsicher
auf dem PC eingeben zu können, bleibt erhalten. Diese Möglichkeit ist nur eine Idee und wurde nicht
verwirklicht. Sie soll aber aufzeigen, dass eine Benutzerfreundlichkeit erhöht werden kann, in der
keine spezielle Registrierung notwendig ist. Das eKaay App benötigt für eine Authentisierung
folgende Informationen: Benutzername, SessionID und die URL des Onlinedienstes bzw. wohin das
App Benutzername, SesssionID und die zufällig permutierte Reihenfolge der Ziffern 0-9 senden kann.
Es wird aber kein Challenge-Response Verfahren ausgeführt, wie es im ursprünglichen eKaayVerfahren der Fall ist.
83
Ablauf:
Abbildung 77: Datenfluss von eKaayPIN als Zwei-Wege-Kommunikation
1. Der Benutzer geht mit seinem Browser auf die Webseite des Onlinedienstes. Dort loggt er
sich mit seinem Benutzernamen ein. Danach erscheint ein 2D Code.
2. Der Benutzer fotografiert mit seinem Fotohandy und dem eKaay App das Bild ab und auf
dem Handy wird zufällig eine permutierte Ziffernreihenfolge 0-9 generiert.
3. Das Handy sendet die permutierte Reihenfolge, Benutzername und SessionID an den
Onlinedienst.
4. Der Benutzer gibt seine PIN indirekt ein, indem er die Ziffernfelder auf dem Handy abliest
und sie auf dem Browser auf den leeren Nummernfelder anklickt.





R1 gilt, da die PIN nicht durch einfaches ausprobieren herausgefunden werden kann. Der
Angreifer sieht nicht, welche Ziffern er eingibt und Ziffernfelder ändern sich.
R2 gilt jedoch nicht, da der Account nur durch die PIN abgesichert wird. Gegen
Phishingversuche wäre diese Methode anfällig, da mit Wissen der PIN und dem
Benutzernamen der Angreifer sich über jedes beliebige Handy einloggen kann.
Die Eingabe der PIN auf dem PC ist abhörsicher, da der Angreifer nicht sehen kann, welche
Ziffern er eingibt. ⇒ R3 gilt.
Es muss eine sichere Verbindung zwischen dem Handy und dem Onlinedienst aufgebaut sein,
damit man die permutierte Reihenfolge nicht abhören bzw. abfangen kann. Alternativ
könnte man eine PKI Methode benutzen, indem man die Informationen mit einem
öffentlichen Schlüssel vom Onlinedienst verschlüsselt und zuschickt. Dann kann nur der
Onlinedienst die Informationen mit seinem geheimen Schlüssel entschlüsseln. ⇒ Mit
entsprechenden Sicherheitsvorkehrungen könnte R4 gelten.
Falls man einen Ablauf verfolgen möchte auf der keine Daten auf dem Handy gespeichert
werden, dann müssen notwendige Daten wie Benutzername und Onlinedienstidentifikation
über das 2D Code an das App übermittelt werden, die dann mit anderen Daten über den
zweiten Kommunikationsweg vom Handy zurückgesendet wird. Man muss daher sichergehen,
dass keine kombinierten XSS und Man-in-the-Middle Angriffe stattfinden, die gefälschte 2D
Codes unterjubeln, damit man die Permutationsreihenfolge abfängt.
84

Das Handy könnte ansonsten auch den Benutzernamen gespeichert haben, der dann
automatisch weitergeleitet wird. Damit wäre das Handy für einen Angreifer nutzlos, da keine
Schlüssel oder so abgespeichert sind. Ohne die PIN kann er sich nicht einloggen. Trojaner
könnten daher gezielt versuchen Handys auszuspähen, damit man die
Permutationsreihenfolge herausfindet. Für einen erfolgreichen Angriff wäre dann ein
kombinierter bzw. zeitnaher Angriff notwendig. ⇒ R5 gilt, wenn entsprechende
Vorkehrungen getroffen werden.
Die Benutzerfreundlichkeit/Aufwand, Zeitfaktor und TCO wären mit dem eKaayPIN in Kapitel 6
vergleichbar, auf die ich dort näher eingehen werde.
5.5 Fazit Zwei-Wege-Kommunikation
In der Zeit, als das Handy als ein Mittel zur Authentifizierung eingeführt wurde, konnte man Man-inthe-Middle und Phishing Angriffe verhindern. Doch mit der Weiterentwicklung der Handys zu
Smartphones , steigt das Risiko, dass auch Trojaner sich auf Handys einnisten und empfangene SMS
oder sonstige Daten abfangen und an den Angreifer weiterleiten. So gab es schon erfolgreiche
Versuche bei Android Smartphones Telefonnachrichten aufzunehmen um sie dann weiterzuleiten
[Robertson, 2011]. Ein Argument für die zusätzliche Sicherheit ist, dass die Kommunikation nicht über
die Internetverbindung vom Webbrowser auf einem PC abläuft, sondern über den
Übertragungskanal SMS oder dem GSM/UMTS-Netz. Dabei müsste sich das Smartphone bei einer
Internetverbindung direkt mit dem Identitätsprovider in Verbindung stehen und nicht mit dem
gleichen Server wie mit dem Webbrowser. Sollte sich ein Smartphone über WLAN sich in das Internet
verbinden, dann wäre das wieder eine Schwachstelle, da öffentliche WLANs oft ungesichert und
abgehört werden können. Der Benutzer sollte sich dabei tatsächlich durch ein anderes Netz wie
GSM/UMTS und auf einen anderen Server verbinden, damit eine Zwei-Wege-Kommunikation
stattfinden kann.
Abbildung 78: Authentisierung wird über einen Browser und ein Handy auf zwei unterschiedliche Wege vorgenommen.
Die Zwei-Wege-Kommunikation gehören zur Familie der Besitzauthentisierungsverfahren, können
jedoch aufgrund des separaten Kommunikationsweg von anderen Besitzauthentisierungsverfahren
unterschieden und als eigene Unterklasse angesehen werden.
85
6 Zwei-Faktor-Authentifizierung
Bei einer Zwei-Faktor-Authentifizierung werden zwei Methoden der Authentisierung kombiniert.
Klassischerweise ist es eine Kombination von Wissen und Besitz. Dabei soll der Account besser
geschützt werden, da bei Verlust von eines der beiden Methoden der Account immer noch mit der
anderen Methode geschützt ist. Die klassische Kombination ist eine EC-Karte und eine PIN. Dabei
muss der Benutzer im Besitz der Karte sein und sie ist durch eine PIN geschützt, die der Benutzer
wissen muss. Es wird bei der Zwei-Faktor-Authentifizierung nicht unterschieden, ob man durch
Wissen den Besitz schützt mit dem man sich authentifiziert (d.h. man kann die Chipkarte nur
benutzen, wenn man die PIN kennt) und dem Wissen, den man nur kennen kann, wenn man im
Besitz eines Gegenstandes ist (z.B. eine TAN-Liste oder eines Authenticator Tokens). Man kann also
Verfahren auch Zwei-Faktor-Authentifizierung nennen, wenn man z.B. einen Account mit einem
Benutzernamen und Passwort und zusätzlich noch mit einem Token oder einem Handy schützt. So
könnte jedes vorher beschriebene Authentisierungsverfahren, die auf Besitz beruht, mit einem
Passwort/PIN kombiniert, als Zwei-Faktor-Authentifizierung verwendet werden. Die Zwei-FaktorAuthentifizierungen werde ich später nochmals verfeinert einteilen, z.B. in Verfahren klassifizieren,
wo ein Faktor (z.B. Besitz) durch einen anderen Faktor (z.B. Wissen) geschützt wird oder zwei
kombinierte Faktoren zusammen einen Account schützen.
Abbildung 79: Mehr-Faktor-Authentifizierung durch Kombinationen
86
6.1 HBCI-1, HBCI-2, HBCI-3 (Secoder)
Homebanking Computer Interface ist eine standardisierte Schnittstelle für das Homebanking. Das
System benutzt eine spezielle Software, normalerweise eine Onlinebanking Software (z.B. StarMoney
8.0 für elektronische Signatur mit Chipkarte), ein Kartelesegerät und eine Chipkarte. Beim
Onlinebanking erzeugt das Lesegerät mit der Chipkarte eine TAN für die Überweisung. Der
Unterschied zwischen den verschiedenen Versionen besteht aus den zusätzlichen Funktionen, die das
Lesegerät besitzt.
Abbildung 80 71: HBCI-1 Kartenlesegerät
So ist der HBCI-1 ein reines Lesegerät, wo man eine Chipkarte einfügen kann und die PIN über die
Software am PC eingeben muss. Der HBCI-2 besitzt eine Zifferntaste, mit der man die Karte
authentisieren kann und der HBCI-3 besitzt zusätzlich ein Display, wo die Überweisungsdaten
angezeigt werden.
Neben der PIN/TAN Authentifizierung wurden Transaktionen mit einer digitalen Signatur gegen nicht
autorisierte Änderungen geschützt. Dabei befindet sich der Schlüssel auf der Chipkarte (DES oder RSA,
d.h. mit einem symmetrischen oder asymmetrischen System). Von der Methode ähnelt es dem
neuen Personalausweis, der später auch noch näher analysiert wird.
71
72
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml
87
Ablauf:
In meinem Ablaufbeispiel werde ich HBCI als ein Authentisierungsverfahren für Online Accounts
vorstellen, anstatt eine Überweisung damit tätigen:
Abbildung 83: Benutzer aktiviert die EC-Karte über ein Lesegerät mit einer PIN. Die Software erstellt mit der EC-Karte und
Lesegerät eine TAN, die man dann dem Onlinedienst zuschickt.
Möchte sich der Benutzer auf ein Account einloggen, dann benutzt er dafür eine bestimmte Software
vom Onlinedienst, die sich mit dem Kartenlesegerät und dem Onlinedienst verbindet. Befindet sich
die Chipkarte im Lesegerät, so muss der Benutzer je nach Version die PIN in das Lesegerät oder am
PC eingeben. Ist damit die Karte freigeschaltet, dann kann die Software zusammen mit der Karte und
dem Lesegerät eine einmalige PIN erstellen oder dem Onlinedienst eine Authentisierung zusenden.
So kann der Benutzer auf sein Account mit der erstellten PIN einloggen oder die Software verbunden
mit dem Onlinedienst ermöglicht ihm den Zugang auf sein Account.
73
88
Abbildung 84: Mögliche Sicherheitsrisiken wie PIN, Lesegerät, Software und die Verbindung zum Onlinedienst
1. Die PIN kann nach wie vor mit Phishingangriffen oder Trojaner abgehört werden, wenn sie
über dem PC mit HBCI-1 eingegeben wird. Verliert der Benutzer die Chipkarte, dann kann der
Angreifer sie nicht ohne weiteres benutzen. Er braucht dafür die PIN. ⇒ R1-3 gilt, da ohne die
Chipkarte die PIN nutzlos ist.
2. Die weitere Sicherheit hängt auch von der Software ab, die als Schnittstelle zwischen der
Karte, dem Lesegerät und dem Onlinedienst dient.
3. Man-in-the-Middle oder Replay Angriffe sind auch abhängig davon, wie die Software mit
dem Onlinedienst kommuniziert. Malware könnte versuchen die Software zu verändern oder
Daten abzufangen und zu verfälschen. Hat das Lesegerät ein Display, könnten
Manipulationen zusätzlich erschwert werden. ⇒ R4 und R5 gilt, da die Angriffe sehr
aufwendig sein müssten.
Kosten von HBCI:
Der Benutzer benötigt ein Lesegerät, eine Chipkarte und eine spezielle Software. Aufgrund des
Lesegeräts, welches an dem PC angeschlossen werden muss und der Software kann sich der Benutzer
nicht an beliebige Orte verbinden. Ansonsten dürfte es recht einfach sein, die Chipkarte in das
Lesegerät einzulegen und mit der Software die PIN einzugeben und die Transaktion durchzuführen.
Dabei muss er danach normalerweise keine weiteren Eingaben mehr betätigen, sondern nur die
Daten höchstens nochmal bestätigen.
Zeitfaktor:
Die Zeitdauer einer Transaktion oder dem Einloggen dürfte sich nicht viel von denen mit anderen
TAN Generatoren unterscheiden.
TCO:


Auf den Benutzer kommen zusätzliche Kosten zu, wenn er für das Lesegerät, die Chipkarte
und die Software bezahlen muss.
Der Onlinedienst benötigt neben herkömmliche Webserver die für das System benötigte
Plattform zur Authentifizierung und im Falle des Onlinebanking ein E-Banking System. Auch
89
müssen sie die Chipkarte und Lesegeräte und die Software, die die Schnittstelle zwischen der
Karte und dem Onlinedienst ist, bereitstellen.
Account Recovery:


PIN: Sollte der Benutzer die PIN vergessen haben, dann muss er die alte sperren lassen und
eine neue beantragen. Dies muss er normalerweise telefonisch oder persönlich wie z.B. bei
seiner Bank machen. Ohne seine neue PIN kann er solange nichts machen.
Chipkarte: Sollte der Benutzer seine Chipkarte verlieren, dann muss er diese Karte sperren
lassen und eine neue beantragen. Bis er die neue Karte nicht hat kann der Benutzer keine
weiteren Transaktionen machen.
6.2 2-step verification
Google hat seit 2011 eine Zwei-Faktor-Authentifizierung eingeführt, die sie Bestätigung in zwei
Schritten [Google, Bestätigung in zwei Schritten, 2011]. Dabei ist der zweite Faktor ein Handy oder
ein Smartphone, der einen App namens "Google Authenticator" benutzt. Dieser Authenticator kann
zeitbasiert oder zählerbasiert sein [Google, google-authenticator - Two-step verification, 2011]. Bei
einer zählerbasierten HOTP wird ein sogenannter HMAC OTP 74 erstellt. Dabei basiert der
Algorithmus auf einen steigenden Wert und einem statischen symmetrischen Schlüssel, den in
diesem Fall nur der Google Authenticator und der Google Authentifizierungsserver kennen.
Zeitbasierte Tokens75 sind nur für 30 Sekunden gültig und, basierend auf HOTP, statt dem steigenden
Wert ein Zeitindex benutzt [VeriSign Inc., Deversinet Corp., Portwise Inc., 2010]. Die Anmeldung mit
einem Google Authenticator ist vergleichbar mit dem vom RSA SecurID Softwaretoken und wurde
bereits näher behandelt. Darum werde ich hier nur auf die sogenannte "Bestätigung in zwei
Schritten" Anmeldung für ein Google Konto eingehen. Richtet man das Google Konto für eine
"Bestätigung in zwei Schritten" ein, so erhält man Liste mit zehn nummerierten Ersatzcodes, die mit
einer iTAN Liste zu vergleichbar ist. Jeder Ersatzcode ist nur einmal anwendbar. Diese kann man
eingeben, wenn man das Telefon oder den Google Authenticator nicht benutzen kann. Es gibt auch
die Möglichkeit Anwendungsspezifische Passwörter zu erstellen. Diese sind nur für bestimmte
Anwendungen gültig (z.B. Google Mail und Google Kalender über Smartphones) und müssen nur bei
der ersten Anmeldung eingegeben werden. Danach sind sie gespeichert und man wird über das
Gerät bzw. die Anwendung automatisch angemeldet. Da diese nicht für Online Accounts verwendet
werden, werde ich hier nicht näher auf Anwendungsspezifische Passwörter eingehen.
74
75
Hashed Message Authentication Code One Time Password
TOPT - Time-based One-Time Password
90
Ablauf:
Abbildung 85 76: Anmeldung an ein Google-Konto
Hat man den Google Account vorher für die 2-step verification aktiviert und möchte man sich in ein
Google Account einloggen, dann muss der Benutzer zuerst sein Benutzernamen (1) und Passwort (2)
eingeben. Er kann zusätzlich die Einstellung Eingeloggt bleiben aktivieren (3).
Abbildung 86 77:Zweiter Bestätigungsschritt
Es erscheint dann eine neue Seite und wird aufgefordert einen Bestätigungscode (4) einzugeben.
Diese erhält er über eine SMS an sein Handy und hat er sie eingegeben und bestätigt, dann kann er
sich auf die Webseite einloggen. Der Benutzer hat hier auch die Möglichkeit den Code für 30 Tage zu
speichern und erst danach erneut nach einem neuen Bestätigungscode abgefragt zu werden (5). Falls
er keine SMS erhalten sollte, dann kann er sich auch mit einem Ersatztelefon anmelden (6).
R1, R3-R5 sind dem des mTAN Verfahrens ähnlich. R1 gilt, da das Passwort ohne den SMS Code
nutzlos ist. R2 ist aber ein wenig schwächer, da zusätzlich bei Google Konten die Gefahr besteht, dass
Angreifer durch Phishingangriffe an die Erstatzcodes und das Passwort gelangen möchten. Das
könnte z.B. mit Hilfe von XSS bzw. Man-in-the-Middle Angriffen passieren, die die Anmeldung nicht
weiterleiten und somit keine SMS ankommt und ihn dann verleitet die Ersatzcodes einzugeben. R3 R5 gilt ebenfalls, da Angriffe mit hohem Aufwand verbunden wären.
76
77
http://www.google.com/support/accounts/bin/static.py?page=guide.cs&guide=1056283&topic=1102160
http://www.google.com/support/accounts/bin/static.py?page=guide.cs&guide=1056283&topic=1102160
91
Kosten der 2-step verification:
Der Aufwand und die Dauer bis man sich in das Account eingeloggt hat müsste dem des mTAN
Verfahren entsprechen. Dabei ist die Dauer auch abhängig, wie schnell die SMS ankommt.
TCO:
Normalerweise muss der Benutzer die SMS nicht bezahlen. Ansonsten sollte die TCO so hoch sein wie
beim mTAN Verfahren.
Account Recovery:
Sollte man sein Handy verloren haben, dann kann man sich entweder über die Ersatzcodes, die beim
Aktivieren der Bestätigung in zwei Schritten erstellt werden, anmelden und dann in der
Accountverwaltung die Handynummer ändern oder sich über ein Ersatztelefon einloggen. Sollte man
die Ersatzcodes verlieren, dann kann man in der Accountverwaltung neue Codes erstellen lassen und
somit die alten ungültig machen.
6.3 Internetpassport
Der AXSionics Internetpassport ähnelt dem Sm@rt-TAN-optic-Verfahren und wird AXSionics78
angeboten. Es kombiniert Authentifizierungsverfahren aus Fingerabdruck und Flickercode-Erkennung.
Der Internetpassport soll eine Drei-Faktor-Authentifizierung verwirklichen, indem man eine PIN,
Internetpassport und Fingerabdrücke benötigt. Der Internetpassport ist ein Gerät mit einer Anzeige
und der Möglichkeit Fingerabdrücke darauf abspeichern und ablesen zu können. Er verfügt auch
optische Sensoren mit denen man den Flickercode an einem Bildschrim ablesen kann. Der
Flickercode ist eine optische Datenübertragung von Nachrichten, die verschlüsselt ist.
Abbildung 87: Das Internetpassport 79
78
79
http://www.axsionics.ch/
http://www.theinternetpassport.com/
92
Ablauf80:
1. Der Benutzer gibt die Passportnummer, die hinter
dem Internetpassport steht, als Login ID beim
Onlinedienst ein. Er kann auch ansonsten einfach ein
Login ID und PIN oder Passwort zum Anmelden
benutzen.
2. Der Onlinedienst stellt am Bildschirm ein
Flackercode dar. Der Benutzer hält die optischen
Sensoren vom Internetpassport am Bildschirm um den
Code abzulesen.
3. Der Benutzer muss sich am Internetpassport mit
seinen Fingerabdrücken authentifizieren.
4. Auf der Anzeige des Internetpassports werden im
Falle Überweisung die Überweisungsdaten angezeigt.
Es kann aber auch ein Code angezeigt werden.
5. Ist alles korrekt, dann kann der Benutzer die TAN
bzw. den Code eingeben.
Die Sicherheit R1-R4 dürften mindestens so hoch liegen wie mit dem sm@rt optic Verfahren mit der
die Chipkarte durch eine PIN abgesichert ist. Der Unterschied liegt darin, dass man den
Internetpassport nur mit einem Fingerabdruck aktivieren kann und nicht mit einer PIN. So wäre R5
sicherer, da Fingerabdrücke nicht ohne weiteres weitergegeben werden können und daher das
Internetpassport vor Diebstahl und Verlust abgesichert ist. Die Gefahr ist allerdings, dass der
Fingerabdruck nicht richtig erkannt wird. Gewöhnlich ist da eine 20%ige Fehlertoleranz mit dabei, d.h.
ist der Abdruck mindestens 80% korrekt, dann kann man sich einloggen. Dadurch ist aber der
Internetpassport bei einem Verlust geschützt. Jedoch könnte eine Chance von 1:5 ein Ansatz sein zu
versuchen, die Abdrücke zu fälschen. Auch müssen drei Fingerabdrücke gespeichert sein, d.h. man
könnte von drei Personen die Fingerabdrücke speichern lassen.
Kosten von Internetpass:
Der Aufwand und die Dauer könnten in etwa so wie mit der sm@rt optic sein. Nur muss der Benutzer
anstatt mit einer EC Karte mit einem Fingerabdruck den Internetpassport freischalten. Das könnte
komfortabler sein, als eine PIN sich merken und eingeben zu müssen.
80
http://www.axsionics.ch/tce/frame/main/441.htm
93
TCO:
Im Vergleich zu sm@rt optic ist wohl der Anschaffungspreis für einen Internetpassport viel höher für
den Benutzer. So können beim Benutzer und Onlinedienst die Kosten höher liegen, weil die Kosten
für den Kauf und die Bereitstellung des Internetpassport höher sind.
Account Recovery:


Internetpassport: Sollte der Benutzer den Internetpassport verlieren, dann bleibt ihm nur die
Möglichkeit diese sperren zu lassen und sich dann einen neuen zu besorgen. Die
Accountwiederherstellung könnte so ähnlich ablaufen, wie bei den anderen vergleichbaren
Verfahren.
Fingerabdruck: Für den unwahrscheinlichen Fall, dass die Fingerabdrücke vom Benutzer sich
verändert haben oder nicht mehr benutzen kann, so muss er sich ein neues Internetpass port
bestellen und ihn ersetzen, da die Fingerabdrücke nicht mehr ersetzt werden können.
6.4 nPA
Der neue Personalausweis (nPA) wurde am 01.11.2010 eingeführt und soll den vorherigen
Personalausweis ersetzen. Der Begriff neuer Personalausweis wird im Gesetz nicht explizit erwähnt
und am Anfang wurde die Bezeichnung elektronischer Personalausweis (ePA) verwendet. Es hat sich
aber wohl der Begriff nPA eingebürgert und darum wird er im Folgenden so genannt [Borges,
Schwenk, Stuckenberg, & Wegener, 2011]. Der neue Personalausweis ist nach wie vor in erster Linie
ein Personalausweis, deren besondere Stellung durch die Ausweispflicht nach §1 des
Personalausweisgesetzes (PAuswG) hat. Aber der neue Personalausweis hat nun auch die zusätzliche
Aufgabe, eine Verbesserung der Identifikationssicherheit im Bereich der elektronischen
Kommunikation herbeizuführen. Für diesen Zweck wurde der Personalausweis mit einer Chipkarte
ausgestattet, mit der man einen elektronischen Identititätsnachweis (eID) und elektronische
Signaturen durchführen und biometrische Daten speichern kann. Das Auslesen geschieht kontaktlos
über ein NFC-fähiges Lesegerät und der Middleware AusweisApp81. Interessant dabei ist, dass durch
die Ausweispflicht jeder deutsche Bürger einen neuen Personalausweis l angfristig besitzen sollte und
somit ein Standard zur Authentisierung in Deutschland werden könnte. So gibt es Anbieter wie
idOnDemand82 und One Web One Key (OWOK) von Reiner Kartengeräte GmbH & Co. KG83 , die über
Apps für Smartphones oder Scheckkarten und Lesegeräte vergleichbare Dienste anbieten. Und da der
nPA ein hoheitliches Dokument ist, ist es auch gesetzlich verboten ihn zu manipulieren, zu kopieren,
zu fälschen usw. So ist es ein Unterschied, ob jemand versuchen sollte den nPA zu manipulieren, zu
kopieren, zu stehlen usw. oder ein Authenticator Token, Handy oder andere nicht hoheitliche
Dokumente. Einsatzbereiche für die eID Funktionen sollen im eCommerce als auch in eGovernment
sein [Borges, Schwenk, Stuckenberg, & Wegener, 2011]:
1. E-Commerce:




Handel (Alterskontrolle, Onlineeinkauf im Internet, VoD,..)
Banken (Onlinebanking, Onlinekontoeröffnung,...)
Versicherungen (Onlineantrag, Schadensmeldung,...)
Wirtschaft allgemein (Hotelanmeldungen, Vertragsabschluss,...)
81
Man kann sie unter https://www.ausweisapp.bund.de/ runterladen.
http://www.idondemand.com/
83
http://www.reiner-sct.com/owok/
82
94
 Sonstiges (Soziale Netzwerke, wie z.B. Facebook)
2. E-Government:
 Soziales (ELENA, BAFÖG-Online, ...)
 Verkehr (Auskunft aus dem Verkehrszentralregister, ...)
 Umzug (Melderegister, ...)
 Finanzen (Abgabe der Einkommensteuererklärung, ...)
 Arbeit (Onlineantrag für polizeiliches Führungszeugnis)
 Justiz (Antragstellung im gerichtlichen Mahnverfahren, ...)
Für uns ist nur der Bereich der eID Funktion interessant, in der man sich für Online Accounts
anmelden muss. Auf andere Funktionen wie elektronische Signatur oder Speicherung der
biometrischen Daten wird in dieser Arbeit nicht näher eingegangen. Die in Tabelle 4 dargestellten
Daten sind im nPA gespeichert und können für die eID Funktionen genutzt werden (z.B. beim
Erstellen eines Online Accounts können Name und Nachname übertragen werden). Dabei werden
DG13-16 und DG19-21 im nPA nicht genutzt [Borges, Schwenk, Stuckenberg, & Wegener, 2011].
Nummer (Datengruppe)
DG1
DG2
DG3
DG4
DG5
DG6
DG7
DG8
DG9
DG10
DG11
DG12
DG17
DG18
Inhalt
Dokumententyp (immer "ID")
Aussteller (Staat)
Ablaufdatum
Vorname
Nachname
Künstler- bzw. Ordensname
Akademischer Titel
Geburtsdatum
Geburtsort
Nationalität
Geschlecht
Optionale Daten
Adresse
Gemeindekennzahl
Änderbar
nein
nein
nein
nein
nein
nein
nein
nein
nein
nein
nein
nein
ja
Ja
Tabelle 4: Gespeicherte eID-Datengruppen für eID-Funktionen
Ablauf:
Um sich mit dem nPA auf ein Account einloggen zu können benötigt man folgende Komponenten:


nPA: Wird vom Bürgeramt ausgegeben und von der Bundesdruckerei in Scheckkartenformat
hergestellt. Die Bundesdruckerei verschickt zusätzlich den PIN-Brief (Transport-PIN inkl. PUK,
Sperrkennwort) an den Benutzer/Bürger. Auf der Außenseite befinden sich zusätzlich zu den
üblichen Ausweisdaten lesbar ausgedruckt die Card Access Number (CAN) und die
maschinenlesbare Zone. In der Karte befindet sich ein RF-Chip (Radio-Frequency-Chip, FunkChip), der einen Mikroprozessor enthält und in der Lage ist die kryptografischen Protokolle
[BSI TR-03112-7, 2011] durchzuführen, geheime Schlüssel, Zertifikate und persönliche Daten
speichern und weitere Schlüssel erzeugen kann.
NFC-fähiger Chipkartenleser für kontaktlose Verbindungen: Diese werden von verschiedenen
Herstellern [BSI, 2011] aus der Privatwirtschaft angeboten. Dabei kann man sie in drei
Versionen erwerben: Klasse-1-Leser (ohne eigenes Display und Tastatur), Klasse-2-Leser
95



(ohne Display und eigene Tastatur) oder Klasse-3-Leser (eigenes Display und eigene Tastatur).
Die sicherste und vom BSI empfohlene Klasse sind die Klasse-3-Leser.
AusweisApp: Eine Softwarekomponente die als Middleware dient um die Authentifizierung
zwischen nPA und Server zu gewährleisten und wird von einem vom Bund beauftragtem
Unternehmen für verschiedene Betriebssysteme und Browser entwickelt und gepflegt.
eID-Serverkomponenten: Von der Privatwirtschaft sollen verschiedene Lösungen für
Serverkomponenten der eID-Server anbieten, wie z.B. die Bundesdruckerei, die einen
Identity Provider und Relying Party mit SAML-Token zur Verfügung stellt. Abhängig von den
Serverkomponenten ist auch ein SSO möglich.
PKI-Architektur: Diese Komponenten werden vom Bund gestellt und sind zur Ausstellung der
Zertifikate und Sperrdienst zuständig.
Hat der Benutzer nun seinen Online-Ausweisfunktion freigeschaltet und die Transport-PIN der
Bundesdruckerei durch die eigene PIN ersetzt und den AusweisApp auf seinem Computer installiert,
dann kann er sich damit auf ein Online Account anmelden, wenn diese den nPA unterstützt. Dafür
sollte er am Loginbildschirm einen entsprechenden Link zur Verfügung stellen, dass er sich dort damit
anmelden bzw. einen Account erstellen kann.
Abbildung 88: Anmeldebeispiel mit dem nPA
1. Der Benutzer möchte sich mit dem nPA auf dem Onlinedienst anmelden.
2. Der Onlinedienst leitet die Authentisierungsanfrage auf dem eID-Server weiter. Gleichzeitig
wird der AusweisApp beim Benutzer gestartet.
3. Eine sichere Verbindung wird zwischen dem eID-Server, AusweisApp, Lesegerät und dem nPA
aufgebaut und die Authentizität des Dienstanbieters sowie Authentizität und Integrität des
Ausweises überprüft. Dabei führt der AusweisApp lokal mit dem nPA das PACE-Protokoll [BSI
TR-03110, 2010](Chip- und Terminalauthentisierung) durch.
4. Der AusweisApp zeigt dem Benutzer das Berechtigungszertifikat des Onlinedienstes. Sollte
der Onlinedienst Daten vom Benutzer anfragen, so werden diese angezeigt und der Benutzer
kann entscheiden, welche Daten freigegeben werden soll.
96
5.
6.
7.
8.
Der Benutzer gibt die Daten frei indem er die PIN eingibt.
Die Authentisierungsantwort bzw. Daten werden an den eID-Server gesendet.
Der eID-Server sendet die Authentisierungsantwort bzw. Daten an den Onlinedienst.
Der Onlinedienst überprüft die Antwort und öffnet dem Benutzer den Account, falls die
Antwort korrekt war.
Abbildung 89: Kommunikationsablauf zwischen Benutzer, Onlinedienst, Lesegerät, nPA und CA (Certification
Authority), PKD (Public Key Directory)
Um die Sicherheitsrisiken besser zu verstehen, schauen wir nochmals genauer den Ablauf des eIDs an ,
wie sie in Abbildung 89 angezeigt ist [BSI, 2010]:
1. Der Benutzer wählt beim Onlinedienst die Authentisierung mit Hilfe des eIDs.
2. Der Webserver des Onlinedienstes übermittelt die für den Aufbau der Verbindung
notwendigen Parameter.
3. Der Browser ruft die lokale AusweisApp auf.
4. Die AusweisApp baut einen sicheren Kanal zum eID-Server des Onlinedienstes auf und die
Authentisierung beginnt.
5. Sichere Verbindung zwischen AusweisApp, Lesegerät und nPA wird aufgebaut und PACE
Protokoll in Verbindung mit PIN Eingabe, Terminal Authentication, Chip Authentication und
Passive Authentication soll Berechtigung des Lesegeräts, Onlinedienst, Echtheit des nPA (RFChip) und der ausgelesenen Daten sicherstellen.
6. Mit Hilfe von CA, PKD und dem Sperrmanagement (d.h. über eine PKI) sollen mit Hilfe von
Zertifikaten die in 5. gemachten Überprüfungen durchgeführt werden.
97
Abbildung 90: Sicherheitsrisiken beim nPA
Die Risiken R1 bis R5 sind etwa so hoch wie beim HBCI-Verfahren. Mit hohem Aufwand könnte ein
Angreifer mit Identitätsdiebstahl versuchen auf ein fremden Account einzuloggen. In Abbildung 90
können wir die Sicherheitsrisiken nochmals genauer betrachten:
1. Angreifer kann die Eingabe der PIN über Malware/Trojaner/Keylogger mitlesen, falls das
Lesegerät kein integriertes Ziffernfeld besitzt. Ein Angreifer kann mit einer PIN alleine nichts
anfangen und benötigt noch das nPA bzw. die gespeicherten Informationen vom nPA.
2. Man-in-the-Middle Angriff, Phishingversuche84 und Umleitungen (XSS) sind möglich während
Kommunikation zwischen Browser und Webserver. Erschwert könnten Man-in-the-Middle
Angriffe durch Kontrollanzeigen auf dem Display des Lesegeräts werden. Die direkte
Kommunikation zwischen dem AusweisApp und dem eID-Server wäre nicht möglich, es sei
denn die AusweisApp Software wäre verändert worden.
3. Die Spezifikation zur Authentifizierung zwischen AusweisApp und eID-Server ist noch unklar
[Borges, Schwenk, Stuckenberg, & Wegener, 2011]. Darum wären Ansätze für das Abhören
bzw. Abfangen der Kommunikation oder Replay Angriffe möglich.
4. Versuch der Umleitung auf einen unbefugten Server während der Kommunikation zwischen
dem Browser und dem AusweisApp abhängig vom AusweisApp. Möglichkeit der
Manipulation durch Malware könnte eine Gefahr sein.
5. Gefahr von Manipulation des AusweisApp möglich, vor allem, falls NFC-fähige Smartphones
in der Zukunft eingesetzt werden sollten und dort auch AusweisApps laufen sollten.
6. Manipulation von Lesegeräten wäre denkbar, ähnlich dem Skimming bei Bankautomaten. Es
existieren bisher nur zertifizierte Komfort-Lesegeräte. Ansonsten sind sie alle nicht zertifiziert.
Der Aufwand wäre jedoch größer als herkömmliche Identitätsklauversuche. Falls man NFCfähige Smartphones in Zukunft benutzen könnte, wären diese durch Malware ein
zusätzliches Sicherheitsrisiko.
84
SSL Verbindungen sind nicht mehr sicher.
98
7. Der nPA ist für 10 Jahre ausgelegt und es ist nicht vorherzusehen, ob die Kryptoanalyse in der
Zeit nicht Schwachpunkte und Fehler findet. So konnten kryptografische Systeme mit festen
Parametern in der Vergangenheit zwischen 10 und 20 Jahre ihre Sicherheit bewahren85 .
8. Hier werden über einer PKI mit Zertifikate die Berechtigungen usw. überprüft. Wie die Fälle
der Zertifikataussteller DigiNotar [Kremp, 2011] und Comodo [Stöcker, 2011] zeigen, können
auch durch falsche Zertifikate seriöse Webseiten vorgetäuscht werden. Ein Angriff über XSS
und falsche Zertifikate sind daher denkbar. Auch können Betrüger versuchen ein Zertifikat
bei der Vergabestelle für Berechtigungszertifikate beim Bundesverwaltungsamt (VFB)
beantragen, mit deren positives Bescheid er dann bei einem
Berechtigungszertifikateanbieter (BerCA) das elektronische Berechtigungszertifikat erhält86 .
Hacker könnten versuchen die Anträge zu fälschen bzw. durch gefälschte positive Bescheide
versuchen Zertifikate zu erhalten. Daher ist es wichtig, sowas zu verhindern und regelmäßig
und in kurzen Abständen die Zertifikate zu überprüfen und zu aktualisieren.
Kosten für nPA:
Der Benutzer kann aufgrund des Lesegeräts und der Middlewaresoftware AusweisApp nicht so
flexibel und überall auf Online Accounts einloggen. Zurzeit gibt es auch nur eine Windows Version
und keine für Mac oder Linux. Ansonsten hat man normalerweise einen Personalausweis immer
dabei.
Zeitfaktor:
Die eigentliche Dauer für das Einloggen sollte mit den anderen Zwei-Faktor-Authentifizierungen wie
mit einem Passwort und Token ähnlich sein.
TCO:


Der Benutzer müsste neben dem nPA, dem Freischalten des eID auch noch das Lesegerät
bezahlen, wenn er nicht das Standardgerät Klasse-1 benutzen möchte, welches nicht wirklich
empfehlenswert ist. Für das sicherste Gerät Klasse-3 muss man am meisten bezahlen.
Der Onlineanbieter muss neben einer eID-Server Infrastruktur (neu einrichten, auf bereits
existierende anbinden oder einen eID-Service-Provider auswählen) auch einen
Berechtigungszertifikat beim Bundesverwaltungsamt beantragen und die eID-Anbindung
vom Dienst zum eID-Server implementieren.
Account Recovery:


85
86
PIN: Hat der Benutzer die PIN vergessen, dann kann er eine neue eID-PIN von der
Personalausweisbehörde gegen eine Gebühr neu setzen lassen. Ansonsten hat der Benutzer
drei Chancen seine PIN einzugeben. Beim dritten Mal muss er vorher aber noch die
Zugangsnummer, die auf der Vorderseite des nPA aufgedruckt ist, eingeben. Danach wird die
PIN gesperrt, die der Benutzer mit der PUK bis zu zehn Mal entsperren lassen kann.
nPA: Hat der Benutzer sein nPA verloren, dann muss er telefonisch oder bei der
ausstellenden Personalausweisbehörde den Verlust melden. Falls man der Benutzer dies
telefonisch (über eine Sperrnotrufnummer) meldet, muss er den Sperrkennwort, den er von
Z.B. gab es Kollisionen bei Hash-Funktionen (MD4, MD5, SHA-1) ber eits nach 5-13 Jahren.
Zur Zeit D-Trust GmbH und Signtrust.
99
der Bundesdruckerei erhalten hat, angeben. Wurde die Unterschriftsfunktion aktiviert, dann
muss er diese separat beim gewählten Signaturanbieter sperren lassen. Ist der Verlust
gemeldet, dann muss der Benutzer einen neuen Personalausweis beantragen, was Kosten
und Wartezeit mit sich bringt.
6.5 eKaayPIN
Bei dem eKaayPIN Verfahren authentisiert man sich auf einem Account indirekt mit einer PIN über
den eKaay App und dem dazugehörigen Smartphone mit einer Fotokamera [Borchert, eKaay PIN].
Das Verfahren ähnelt dem eKaay-Verfahren in Kapitel 5, das auf eine Challenge vom Webserver mit
einer Response antwortet, die der Benutzer mithilfe des geheimen Schlüssels beantworten kann.
Beim eKaayPIN wird zusätzlich noch eine permutierte Reihenfolge der Ziffern 0-9 mitgeschickt, die
auch vom geheimen Schlüssel abhängt.
Ablauf:
Um den sich mit dem eKaayPIN einloggen zu können, muss der Benutzer vorher das App auf seinem
Handy installiert und dann entsprechend in seiner Accountverwaltung das Verfahren aktiviert haben.
Es wird dabei wie beim eKaay-Verfahren ein geheimer Schlüssel vereinbart und ausgetauscht, der auf
dem eKaay-Server und auf dem Smartphone gespeichert ist. Es ist der gleiche Vorgang beim eKaayVerfahren in Kapitel 5. Möchte sich nun der Benutzer auf einen Onlinedienst anmelden, dann muss
er wie beim eKaay-Verfahren nur noch mit dem eKaay App einen 2D-Code mit dem Smartphone auf
dem Bildschirm (Abbildung 91) abfotografieren. Er erhält dann über das eKaay App eine Darstellung
des Nummernfeldes mit vertauschten Ziffern. Das App sendet die benötigten Informationen wie
Benutzername, Session ID und den vertauschten Ziffern an den eKaay-Server.
Abbildung 91 87: Eingabemaske für die PIN
Der Benutzer liest die Ziffern auf dem Smartphone ab, die hinter dem leeren Nummernfeld stehen
(Abbildung 92), die auf der Webseite auf dem Browser seines PCs dargestellt werden. Er kann dann
die PIN eingeben, indem er auf die leeren Nummernfeldern mit der Maus klickt.
87
http://www.ekaay.com/PIN/
100
Abbildung 92 88: Darstellung des Nummernfeldes auf dem Smartphone





Die PIN kann ausreichend sicher sein, wenn sie lang genug ist und die Anzahl der
Fehlversuche eingeschränkt ist. Zusätzlich werden die Ziffernfelder nicht angezeigt und
permutieren. Darum benötigt der Angreifer auch das Handy mit dem Schlüssel. ⇒ R1 gilt.
Es kann aber immer noch die Gefahr vom Benutzer ausgehen, wenn durch Phishingversuche
der Angreifer an seine PIN gelangt. Der Angreifer würde aber immer noch das Smartphone
mit dem gespeicherten geheimen Schlüssel benötigen. Somit wäre die PIN nutzlos. ⇒ R2 gilt.
Das Verfahren ist Trojanersicher, da auf dem PC des Benutzers ein Keylogger nicht erkennen
kann, was für eine PIN eingegeben wird. ⇒ R3 gilt.
Falls es Sicherheitslücken auf der Webseite gibt, könnte durch ein Man-in-the-Middle Angriff
die Gefahr bestehen, dass der Angreifer dem Benutzer einen manipulierten 2D Code
unterschiebt und mit einer falschen Session ID so auf den Account einloggen kann.
Zusätzliche Gefahr könnte vom Handy ausgehen. Bei Verlust könnte der Angreifer mit dem
Handy ohne Probleme einloggen bzw. neue Viren für Handys könnten Angriffe auf das App
starten bzw. belauschen um die Zifferndarstellung zu erhalten oder den geheimen Schlüssel
zu finden, der vom eKaay App benutzt wird um sich gegenüber dem Onlinedienst zu
authentisieren. Damit ein Angriff auf ein Handy funktioniert um die Zifferndarstellung
herauszufinden, bedarf es aber ein kombinierter zeitgleicher Angriff auch auf dem PC des
Benutzers, bzw. auf die gültige Session. Die Sicherheit könnte erhöht werden, wenn der
Schlüssel nicht direkt auf dem Handy, sondern z.B. auf einer Smartcard abgespeichert wäre,
der dann über ein NFC-fähiges Handy abgerufen werden kann. ⇒ R4 und R5 gilt, da ein
Angriff mit großer Aufwand verbunden ist.
Kosten des eKaayPIN:
Das Verfahren könnte schneller und einfacher wie vergleichbare Low-Tech Verfahren sein, wo man
sich mit einer indirekten PIN Eingabe gegen Trojaner absichert. Ansonsten könnte es genauso lange
dauern wie Verfahren die z.B. den RSA SecurID Token benutzen.
88
http://www.ekaay.com/PIN/
101
TCO:


Der Benutzer benötigt ein Android Smartphone oder IPhone bzw. ein Handy mit eingebauter
Kamera, die das eKaay App unterstützt. Er muss das kostenlose App dann auf sein Handy
installieren.
Der Onlineprovider muss neben seinen bisherigen Authentifizierungssystemen zusätzlich
noch einen eKaay Server und eKaay Proxyserver anschaffen, die darauf aufbauen.
Account Recovery:
Sollte der Benutzer sein Handy verlieren, so könnte er sein Account wie beim mTAN oder eKaay
Verfahren wiederherstellen lassen.
6.6 NFC-Foto-TAN
Mit dem NFC-Foto-TAN Verfahren [Borchert, Fotohandy-TAN mit NFC, 2009] sollen die Schlüssel zur
Authentisierung nicht mehr auf dem Smartphone, sondern auf einer RFID-Chipkarte gespeichert
werden. Mit der Radio-Frequency-Identification (RFID) Chipkarte kann man über Near-Field
Communication (NFC) Smartphones kabellos Daten speichern und ablesen. Das Verfahren ist noch im
Entwicklungsstadium und soll neue Techniken wie NFC-fähige Smartphones einbinden um die
Sicherheit von eKaay PIN zu erhöhen, indem man die Speicherung der Schlüssel zur Authentisierung
vom Handy auf eine Chipkarte auslagert.
Ablauf:
Abbildung 93 89: NFC-Foto-TAN Verfahren
Im Fall für eine Authentisierung auf ein Account loggt sich der Benutzer mit seinem Benutzernamen
ein. Es erscheint dann ein 2D Bild auf dem Bildschirm. Das Smartphone liest den 2D-Code ab und
erhält so eine Nonce (eine Challenge, die eine zufällig generierte Zufallszahl sein kann) und
entsprechende Accountdaten (z.B. Benutzername usw.). Sind die dargestellten Daten auf dem
Smartphone in Ordnung, dann kann der Benutzer seine RFID-Chipkarte an das Smartphone legen und
er sendet die Nonce an die RFID-Chipkarte, die eine Antwort mit dem auf der Chipkarte
gespeicherten Schlüssel erstellt und sie an den Smartphone zurückschickt. Mit der Antwort wird die
Authentisierung bestätigt und auf dem Smartphone kann die permutierten Ziffern auf dem
Nummernfeld dargestellt werden. Der Benutzer kann dann korrekt seinen Account PIN auf dem
89
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/NFC-Fotohandy-TAN/
102
Bildschirm durch das Anklicken der leeren Nummernfelder in der Eingabemaske eingeben. Die
Chipkarte könnte zusätzlich noch mit einer PIN abgesichert sein, falls sie verloren gehen sollte. So
muss man die PIN vor der Antwortgenerierung auf dem Smartphone eingeben.
Abbildung 94 90: NFC-Foto-TAN Informationsfluss
Sollte das Verfahren realisiert werden, dann sollte man darauf achten, dass Viren über das
Smartphone nicht an die Schlüssel auf der Scheckkarte zugreifen, abhören oder manipulieren können.
Das Verfahren wäre ansonsten gegen Trojaner sicher und auch gegen Man-in-the-Middle Angriffe
vom PC aus. Es sollte aber sichergestellt werden, dass es nicht möglich ist auf dem Smartphone
eventuell Man-in-the-Middle Angriffe zu starten und beispielsweise die App zu manipulieren. Die
RFID-Chipkarte sollte zusätzlich mit einer PIN abgesichert sein. ⇒ So würde R1-R5 hier gelten.
Kosten des NFC-Foto-TAN:
Der Aufwand und Zeit sich auf einen Account einzuloggen oder eine Überweisung durchzuführen
würde sich etwas vergrößern im Vergleich zum eKaayPIN Verfahren, da man jetzt noch zusätzlich die
Scheckkarte herausnehmen und sie mit dem Handy benutzen muss. Ansonsten wäre der Benutzer
damit genauso flexibel und könnte sich von beliebigen PCs aus einloggen.
TCO:
Die Kosten für den Benutzer und Onlinedienst würde sich im Vergleich zum eKaay Verfahren um die
zusätzliche RFID-Chipkarte erhöhen, die man jetzt zur Speicherung der Schlüssel braucht. Auf das
eKaay Verfahren werde ich später näher eingehen.
Account Recovery:
Sollte man die RFID-Chipkarte verloren haben, dann muss er sie auch gestohlen melden, damit man
die abgespeicherten Schlüssel sperrt. Die Accountwiederherstellung kann genauso ablaufen wie bei
den anderen eKaay Verfahren.
90
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/NFC-Fotohandy-TAN/
103
6.7 Sichere Fenster
Das Sichere Fenster Verfahren [Borchert, Fouquet, Niedermayer, & Reinhardt, 2008] ist eine
technische Variante des visuellen PIN Verfahrens basierend auf visueller Kryptografie. Das Verfahren
sieht vor, dass die Informationen auf dem Bildschirm verschlüsselt übertragen werden. Man kann auf
dem Bildschirm nichts als ein rauschendes Bild sehen. Eine Darstellung des korrekten Bildinhalts
erhält man, wenn man ein Entschlüsselungsgerät zwischen dem PC und Monitor anschließt. Das
Entschlüsselungsgerät kann zusätzlich ein Lesegerät für RFID- oder Smartcard-Chipkarten sein, damit
man mehrere Accounts damit verwalten kann. Zurzeit ist dieses Verfahren in der Praxis noch nicht
verwirklicht worden.
Ablauf:
Abbildung 95 91: Sicheres Fenster Verfahren
Der Benutzer erhält vom Onlinedienst ein Entschlüsselungsgerät und eine Smartcard, welche an das
Entschlüsselungsgerät reingesteckt werden kann. Das Entschlüsselungsgerät ist dabei zwischen dem
Computer und dem Monitor angeschlossen. Loggt sich nun der Benutzer beim Onlinedienst mit
seiner Login ID ein, so werden vom Onlinedienst verschlüsselte Bilder zugeschickt, welche nur
rauschen darstellen. Sobald der Benutzer jedoch seine Smartcard an das Entschlüsselungsgerät
angeschlossen hat, werden die Bilder damit entschlüsselt und er sieht die Eingabemaske für die
Eingabeaufforderung seiner PIN mit vertauschten Nummernfeldern. Der Benutzer kann dann durch
Mausklicks seine PIN eingeben und dann einloggen.
In der Theorie wäre dieses Verfahren gegen Trojaner sicher, da die PIN nicht abgehört werden kann.
Die Bildsignale werden verschlüsselt zum Bildschirm gesendet und werden vom Gerät, dass zwischen
dem PC und dem Bildschirm geschaltet ist, entschlüsselt. Daher würden auch Trojaner, die einen
Screenshot machen, nur rauschen erkennen. Auch könnte das Verfahren gegen Man-in-the-Middle
Angriffe sicher sein, wenn man z.B. den kompletten Inhalt des Online Accounts verschlüsselt
angezeigt wird und man nur mit der passenden Smartcard den Inhalt erkennen kann. So we rden
zwischen dem Benutzer und dem Onlinedienst keine direkten Passwörter ausgetauscht und der
Angreifer kann nur verschlüsselte Signale abfangen. Die Signale werden durch die Smartcard
entschlüsselt, die den Schlüssel dafür nicht preisgibt. Dabei sollte man beachten, dass das
91
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/SichereFenster/
104
Entschlüsselungsgerät und die Smartcard nicht manipulierbar sind. Um beim Verlust der Smartcard
einen Missbrauch vorzubeugen, sollte sie mit einer PIN geschützt werden. Diese könnte der Angreifer
aber mit Hilfe eines Trojaners bzw. Keyloggers ausspähen. Verhindern kann man sowas, wenn man
die PIN direkt am Entschlüsselungsgerät eingeben müsste, wie bei den Klasse-3 Lesegeräten für die
nPAs oder HBCI-3, die ich später vorstellen werde. Die Schlüsselübergabe zwischen der Chipkarte und
dem Onlinedienst sollte auch sicher sein, falls man sie über offene Kanäle verschicken muss.
Ansonsten könnten die Schlüssel bereits auf der Karte gespeichert sein und der Onlinedienst kann sie
anhand der Seriennummer identifizieren, die der Benutzer in seiner Accountverwaltung angeben
müsste. ⇒ R1-R5 könnte also bei einer korrekten Umsetzung gelten.
Kosten des Sicheren Fenster Verfahren:
Mit dem Verfahren könnte der Benutzer bequem und einfach von zu Hause aus auf seinen Online
Account einloggen. Da aber dafür ein Entschlüsselungsgerät und eine Smartcard benötigt werden, ist
er nicht so flexibel und kann dies nur von PCs aus machen, die solche Entschlüsselungsgeräte
angeschlossen haben. Dabei müsste der Benutzer aber sichergehen können, dass solche Geräte nicht
manipuliert sind.
TCO:


Der Benutzer müsste neben einer RFID-Chipkarte auch ein Entschlüsselungsgerät besorgen.
Das könnte teurer sein als Verfahren, die nur einen Gegenstand benutzen, wie z.B. RSA
SecurID Tokens.
Der Onlineprovider müsste neben der entsprechenden Software (z.B.
Authentifizierungsserver und Verschlüsselungssoftware) auch die Entschlüsselungsgeräte
und RFID-Chipkarten bereitstellen.
Account Recovery:
Sollte der Benutzer seine Chipkarte verlieren, so müsste er sie auch sperren lassen und könnte die
Accountwiederherstellungsmethode, wie bei den anderen Verfahren mit Tokens, z.B. RSA SecurID,
eKaay oder mTANs, benutzen.
6.8 Schlüsselkarte
Die Schlüsselkarte [Borchert & Reinhardt, Vorrichtung und Verfahren zur Abhör- und
Manipulationssicheren Verschlüsselung für Online-Accounts, 2009] erinnert an das sichere Fenster
Verfahren, indem man ein codiertes Bild auf dem Bildschirm mit Hilfe eines Lesegerätes dekodiert.
Das Entschlüsselungsgerät, die Smartcard und der Bildschirm werden mit einer sogenannten
Schlüsselkarte kombiniert. Der Benutzer erhält eine Schlüsselkarte mit Fotosensoren auf der
Rückseite, eine Anzeige auf der Vorderseite, eine Recheneinheit und Speicher, in der der geheime
Schlüssel gespeichert ist. Auch dieses Verfahren existiert wie das Sichere Fenster bisher nur in der
Theorie.
105
Ablauf:
Abbildung 96 92: Beispiel einer Darstellung der Schlüsselkarte und des Monitors bei einer Überweisung
Der Benutzer loggt sich beim Onlinedienst mit seinem Benutzernamen und Passwort ein und es
erscheint ein kodiertes Bild auf dem Bildschirm (Abbildung 96). Hält der Benutzer seine
Schlüsselkarte vor dem kodierten Bild, dann tasten die Fotosensoren das Bild ab und die
Informationen können mit Hilfe des abgespeicherten Schlüssels dekodiert und auf der Anzeige der
Schlüsselkarte dargestellt werden. Man kann darauf z.B. den Accountnamen, Benutzernamen oder
Bilder usw. sehen und eine PIN als ein Einmalpasswort, die er dann in die Eingabemaske auf dem
Computer eingibt (Abbildung 97).
Abbildung 97 93: Dekodierte Darstellung des Monitors mit einer drüber liegenden Schlüsselkarte
Das Verfahren könnte mindestens so sicher sein wie das sm@rtTAN optic Verfahren mit dem
Flickercode. Auf das Verfahren werde ich auch später näher eingehen. Dabei ist sozusagen das
kodierte Bild bei der Schlüsselkarte der Flickercode beim sm@rtTAN optic. Sie ähneln sich vom
92
93
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml#Schluesselkarte
http://www-ti.informatik.uni-tuebingen.de/~borchert/Troja/Online-Banking.shtml#Schluesselkarte
106
Ablauf her und unterscheiden sich nur von der Methode, wie man den Code auf den Bildschirm
sendet. ⇒ R1-R5 könnten hier bei einer korrekten Umsetzung gelten.
Kosten der Schlüsselkarte:
Der Aufwand und die Dauer sowie die Kosten für den Benutzer und dem Onlinedienst könnten mit
dem sm@rtTAN optic Verfahren vergleichbar sein.
Account Recovery:
Beim Verlust der Schlüsselkarte müsste man ein ähnliches Accountwiederherstellungsverfahren wie
bei eKaay oder sm@rtTAN optic anwenden.
6.9 Fazit Zwei-Faktor-Authentifizierung
Bei einer Zwei-Faktor-Authentifizierung soll es ein Angreifer schwerer haben sich erfolgreich auf ein
Account einloggen zu können. Sie benötigen dafür beispielsweise nicht nur ein Passwort, sondern
zusätzlich noch einen Gegenstand. Dabei kann man einen feinen Unterschied bei der Zwei-FaktorAuthentifizierung für Online Accounts feststellen.
So kann man am Anfang versuchen eine Authentisierung sicherer zu machen, in dem man zwei
Schritte dafür benötigt. Angefangen z.B. mit einer zweimaligen Passwortabfrage. Eine
Authentisierung in zwei Schritten müsste also zwangsläufig nicht über zwei Faktoren ablaufen
(Abbildung 98).
Abbildung 98: 2-Schritte-Authentisierung innerhalb eines Faktors
Doch erhöht sich die Sicherheit jedoch nicht, wenn man eine Authentisierung in zwei Schritten mit
dem gleichen Faktor durchführt. Es werden keine Angriffsarten dadurch verhindert. Ähnlich wie in
der Kryptologie, wo man auch durch Hintereinanderausführungen die Sicherheit nur erhöhen kann,
wenn entsprechende Bedingungen94 erfüllt sind, lässt sich eine tatsächliche Erhöhung der Sicherheit
nur mit zwei verschiedenen Faktoren verwirklichen. So lassen sich theoretisch alle Online Accounts
mit einer zwei Schritte Authentisierung in eine Zwei-Faktor-Authentisierung in zwei Schritten (in
Abbildung 99 Unabhängige Zwei-Faktor-Authentifizierung genannt) modifizieren: Der Benutzer
benötigt dabei neben dem Faktor Wissen auch den Faktor Besitz für eine Authentisierung auf sein
Account. Er muss sich also auf dem Account zweimal einloggen, jeweils mit einem anderen Faktor.
Dies wäre eine einfache Art. um bestehende Accounts mit einem zweiten Faktor aufzurüsten.
94
So ist z.B. Nichtlinearität eine Voraussetzung oder man sollte beachten, dass eine dreifache DES
Verschlüsselung wie 3DES zwar eine Schlüssellänge von 168 Bit, jedoch effektiv nur 112 Bit hat [Hauck, 2003].
107
Beispiele wären mTANs und RSA SecurID Tokens. Auch die älteren EC-Karten mit Magnetstreifen
arbeiten damit. Die PIN und die Karte wird Online beim Provider auf die Korrektheit überprüft. Damit
lassen sich Sicherheitsrisiken in der jeweiligen Authentisierungsmethode abschwächen. So wird der
Account bei einem Diebstahl eines Passwortes mit einem Token abgesichert bzw. der Verlust des
Tokens durch ein Passwort. Da man aber im Grunde zwei unabhängige Verfahren verwendet, nenne
ich sie unabhängige Zwei-Faktor-Authentifizierung. Jede Ein-Faktor-Authentifizierung könnte man so
in eine Zwei-Faktor-Authentifizierung modifizieren.
Abbildung 99: 2-Faktor-Authentisierung in 2 Schritten
Die andere Möglichkeit einer Zwei-Faktor-Authentifizierung wäre, wenn man z.B. den Besitzfaktor
mit einem Wissenfaktor schützt (Abbildung 100). So kann man eine erfolgreiche Authentisierung nur
durchführen, indem man beides einsetzt. So wie man eine PIN benötigt um mit der EC-Chipkarte
Geld abzuheben. Im Chip der EC-Karte wird die PIN auf Korrektheit überprüft. Damit sichert man den
Besitzfaktor ab, falls man es verlieren sollte. Klassisch sichert man den Besitz mit einer PIN, einem
Wissensfaktor ab. Aber es wäre auch ein Persönlicher Merkmal als zweiter Faktor möglich, da man
praktischerweise sowas immer mitführt und im Besitzfaktor könnte eine Kamera, Mikrofon, Scanner
usw. eingebaut sein, damit man z.B. ohne Problem die Stimme, Gesicht, Fingerabdruck usw.
überprüfen kann.
Abbildung 100: Klassische 2-Faktor-Authentisierung
Da ein Faktor von dem anderen abhängig ist, nenne ich sie abhängige Zwei-Faktor-Authentifizierung.
Wie man die zwei Faktoren für eine Authentisierung für ein Online Account einsetzt, macht aber
eigentlich keinen großen Unterschied auf die Sicherheit des Accounts. In beiden Fällen braucht man
beide Faktoren, wenn ein Angreifer sich erfolgreich auf ein Account einloggen möchte . Einen kleinen
Sicherheitsvorteil hätten aber Verfahren, in der man z.B. die PIN abhörsicher in einen
Einmalpasswortgenerator für die Authentisierung eingeben kann. Am Beispiel des Internetpassport
wäre der Generator ein autarkes System bei der man einen Fingerabdruck zur Aktivierung eingeben
108
muss. Es wären aber auch andere biometrische Merkmale denkbar, wie Unterschrift, Stimme, Iris
oder Gesichtserkennung. So bietet Android 4.0 mit dem Samsung Galaxy Nexus eine
Gesichtserkennung zur Aktivierung des Smartphones an. Sie bietet aber geringe Sicherheit, da man
das Smartphone auch mit Fotos oder ähnliche Gesichter aktivieren kann [Beiersmann & Poessneck,
2011].
Außer für Onlinebanking oder beim Geldautomaten, wo man die Chipkarte und PIN, ein Handy für
SMS Nachrichten oder TAN-Listen benutzt, haben sich bisher Zwei-Faktor-Authentifizierungen nicht
groß durchgesetzt. Es werden einige Accounts mit Tokens geschützt oder mit Smartphones, auf
denen Authenticator Apps laufen. Doch sie werden nach wie vor nur optional unterstützt. Neue
Versuche wie z.B. den nPA für eine sichere Authentifizierung zu benutzen sind bisher gescheitert, da
es noch zu wenige Unterstützungen in der Industrie bzw. Firmen gibt95. Extra Lesegeräte und
Software anzuschaffen könnte, neben der Inflexibilität, einer der Gründe zu sein, warum sich solche
Verfahren nicht durchsetzen. Durch die Verbreitung von Smartphones und der Tatsache, dass man
diese normalerweise immer mitführt, könnten Verfahren, die auf Apps basieren und kostenlos sind,
auf breitere Zustimmung stoßen. Doch sollte man die Weiterentwicklung beobachten, da sich auch
Viren für Smartphones nicht lange auf sich warten lassen. Aber zurzeit müssten Angreifer große
Kosten und Mühen auf sich nehmen, wenn sie nPAs oder mTANs knacken möchten. Damit sich der
Aufwand für einen Angreifer lohnt, müsste der Gewinn für ihn ziemlich hoch sein.
7 Symbiotische Zwei-Faktor Authentisierung
Im vorherigen Kapitel hatte ich die Zwei-Faktor Authentisierung in unabhängige Zwei-Faktor
Authentisierungen in zwei Schritten bzw. abhängige Zwei-Faktor Authentisierungen unterteilt. Eine
dritte Variante einer Zwei-Faktor Authentisierung werde ich in diesem Kapitel vorstellen: Die
symbiotische Zwei-Faktor Authentisierung in einem Schritt.
Abbildung 101: Symbiotische Zwei-Faktor Authentisierung in einem Schritt
Die Gemeinsamkeit aller drei Varianten ist: Man benötigt Wissen und Besitz um sich auf ein Account
zu authentisieren.
Der Unterschied ist die Beziehung zwischen den beiden Faktoren untereinander: Sie besitzen
95
Bisher unterstützen 20 Unternehmen und Institutionen den nPA und nach einem Jahr wurden über 8 Mio.
nPAs ausgegeben. Bei der Deutschen Rentenversicherung sind 52 Mio. angemeldet und erst 300 haben dort die
eID-Funktion freischalten lassen [Sawall, 2011].
109
entweder keine Beziehungen untereinander96 , der Besitz ist abhängig vom Wissen97 oder Wissen und
Besitz gehen untereinander eine Art symbiotische Beziehung ein, indem beide Faktoren sich
gegenseitig benutzen bzw. benötigen. Beispiele , die ich schon vorgestellt habe, wären z.B. die
Permutation-PIN, Cardano-PIN oder den eKaay-PIN, Schlüsselkarte, Sichere Fenster oder das NFCFoto-TAN.
Die Grundidee für eine symbiotische Zwei-Faktor Authentisierung ist, dass man das Wissen
abhörsicher in das PC eingeben kann, d.h. Trojanersicher ist. Dafür wird ein zweiter Faktor Besitz in
Kombination mit dem Wissen benutzt. So lassen sich unter bestimmte Bedingungen jedes auf Besitz
beruhendes Authentisierungsverfahren in eine symbiotische Zwei-Faktor Authentisierung
modifizieren. In diesem Kapitel werde ich dabei speziell die im vorherigen Kapitel vorgestellten
Onlinebanking Verfahren modifizieren.
Idee: Wissen wird indirekt bei der Authentisierung eingeben.
Voraussetzung: Wissen kann indirekt über Symbole eingegeben und über einen Besitzfaktor
permutiert dargestellt werden.
Erhöht werden kann die Sicherheit wenn das Wissen neben der Permutation auch substituiert
werden kann. Die Passwortsicherheit bleibt aber nur bei einer bijektiven Abbildung erhalten, nicht
bei einer surjektiven, d.h. wenn verschiedene Symbole auf ein gleiches abgebildet werden.
Somit lässt sich jede Ein-Faktor Authentisierung durch eine permutierte Darstellung der Symbole von
Wissen in eine Zwei-Faktor Authentisierung modifizieren.
Dies lässt sich am einfachsten mit PIN-Verfahren verwirklichen. Man kann sie auch mit Passwörtern
modifizieren, aber da könnte es dann komplizierter werden oder die Passwortsicherheit vermindern.
Dies werde ich nun in den folgenden Beispielen erörtern.
7.1 Passwörter
7.1.1
Low-Tech Verfahren
Es ist möglich mit einer Abwandlung der Papier-TAN Verfahren wie man es mit der indirekten
Eingabe der PIN macht, wie beim pPIN Verfahren, dies auch für Passwörter zu benutzen. Doch
würden dann solche Eingabelisten sehr lang werden und die Eingabe zu unübersichtlich. Würde ein
Passwort aus Groß-und Kleinbuchstaben und Zahlen bestehen können, dann müssten 62 anklickbare
Felder auf dem Loginbildschirm erscheinen und entsprechend so viele permutierte Buchstaben und
Zahlenreihenfolge auf der Papierliste stehen. Auch würde die Liste sehr lang werden, wenn man 100
permutierte Reihenfolgen auf einer Liste abdrucken müsste.
96
97
Unabhängige Zwei-Faktor Authentisierung in zwei Schritten.
Klassische abhängige Zwei -Faktor Authentisierung.
110
Abbildung 102: Anwendungsbeispiel einer permutierte n Eingabeliste und Anmeldebildschirm
7.1.2
High-Tech Verfahren
Man könnte auch anstatt Permutationslisten auch Generatoren verwenden, die zufällig und zeitlich
begrenzt, wie etwa zeitgesteuerte Tokens, die Buchstabenreihenfolge auf einem Display anzeigen.
Dies wäre durch einen App auf einem Smartphone wahrscheinlich am besten darstellbar. Aber wie
beim Papierverfahren wäre die Eingabe zu kompliziert, da zu viele anklickbare Felder dargestellt
werden müssten.
7.1.3
Surjektive Substitution
Neben bijektive Verfahren für Passwörter, die umständlich handzuhaben sind, könnte man jedoch
auch eine surjektive Substitution der Buchstaben für die Passwörter umsetzen. Der Vorteil wäre, dass
man damit die Darstellung einfacher wäre und die Eingabe schneller vonstattengehen könnte. Dies
wäre z.B. bei Smartphones über Apps möglich. Dabei werden dann die Buchstaben einer Ziffertaste
zugeordnet, die dann am Bildschirm auf dem PC eingegeben werden kann.
Abbildung 103: Anwendungsbeispiel einer App für indirekte Eingabe des Passworts und Anmeldeseite.
Der Nachteil wäre, dass damit aber die Passwortsicherheit kleiner wird. So würden sich bei einem
achtstelligem Passwort bestehend aus 26 Buchstaben und 10 Ziffern die Kombinationsmöglichkeiten
von
auf
verringern. Sie wäre im Grunde dann so sicher
wie eine achtstellige PIN. Im Grunde müsste man da auch die Fehlversuche auf drei einschränken,
sonst würde ein Brute-Force Angriff um ein vielfaches schneller zum Erfolg führen.
111
7.2 Papier-TAN Verfahren als symbiotische Zwei-Faktor Authentisierung
Unter der Voraussetzung, dass man PINs für die Authentisierung benutzt, könnte man Onlinebanking
Verfahren in symbiotische Zwei-Faktor Authentisierungsverfahren umwandeln. Ich werde hier einige
Beispiele vorstellen, die man schon vom vorherigen Kapitel als Verfahren kennengelernt hatte, die
auf Besitz beruhen. Sie werden von mir so modifiziert sein, dass die Authentisierung nun nur
zusammen mit einem PIN, also einem zweiten Faktor, erfolgreich verläuft. Anders wie beim
klassischen Zwei-Faktor Authentisierung wird das Wissen nicht dazu benutzt, um den Besitz zu
authentisieren, sondern um sich in den Account einzuloggen.
7.2.1
indirekt indizierte Einmal-PIN Liste
Eine weitere Möglichkeit wäre eine Zwei-Faktor-Authentifizierung, bei der man neben der Liste auch
eine PIN benutzt.
Abbildung 104: Anmeldung mit PIN und PIN-Liste
Mit der Zwei-Faktor-Authentifizierung wird anstatt eines Einmal-PIN ein Account PIN benutzt. Dabei
wird die PIN nicht direkt, sondern über die Buchstaben eingegeben, die auf der Liste steht und über
die Ziffern, die über die Anmeldeseite auf die Buchstaben der PIN-Liste abgebildet werden. So muss
er in Abbildung 104 die PIN Nr. 31 eingeben. Seine Account PIN lautet dabei "749027" und die "7"
wird als "s" eingegeben. Die "4" als "w" usw. So lautet der Bestätigungscode am Ende "swpgbs". Am
Ende wird die PIN nicht direkt, sondern indirekt über die Buchstaben eingegeben, die sich bei jeder
Anmeldung ändert.
Neben der PIN wäre es aber auch möglich den Index der PIN indirekt abzugeben. In unserem Beispiel
sollte man die PIN mit der Nr. 31 eingeben. Anstatt die 31 nun auf dem Bildschirm anzuzeigen,
könnte man es indirekt machen, sodass man z.B. eine TAN Liste mindeste ns zweimal benutzen
könnte. Dabei werden Zahlen zufällig bis auf zwei Stellen (Abbildung 105) angezeigt. Es sind die zwei
Stellen, auf die die PIN-Liste mit Pfeilen drauf zeigt.
112
Abbildung 105: Indirekte Anzeige der PIN Nr.
Abbildung 106: Indirekte Anzeige der PIN Nr. mit Liste
Der Benutzer legt seine PIN-Liste unterhalb der Leiste mit den Zahlen an und zwei Pfeile auf seiner
Liste zeigen auf die zu benutzende PIN Nr. an. In unserem Beispiel auf Abbildung 106 wären es die
Zahlen 3 und 1, also die PIN Nr. 31. Diese Möglichkeit der PIN Nr. Anzeige wäre auch für die
nachfolgenden Papier-TAN Verfahren denkbar.




Ist die PIN auseichend lang und die Anzahl der Fehlversuche begrenzt, dann kann sie als
sicher gelten. Auch ist die PIN ohne die Liste nutzlos. Man braucht beide kombiniert. ⇒ R1
gilt.
Gegen Phishingversuche nur bedingt geschützt, da der Account PIN und die Liste
weitergegeben werden könnten. ⇒ R2 gilt eingeschränkt, da mit mittlerem Aufwand die
Weitergabe gelingen könnte.
Die PIN ist gegen Trojaner geschützt, da sie nicht direkt eingegeben wird und sie zusätzlich
nur einmal in Verbindung der Liste gilt. ⇒ R3 gilt.
R4 ist mindestens so sicher wie die Ein-Faktor Variante, aber bei Verlust oder Diebstahl der
indirekt indizierten Einmal-PIN-Liste wäre sie ohne den Account PIN nutzlos. Der Hacker muss
die PIN kennen und die Liste besitzen um sich einloggen zu können. ⇒ R5 gilt, da der
Aufwand höher ist, da er die Liste und die PIN stehlen muss.
113
7.2.2
indirekt indizierte Einmal-Bild -Liste
Hier stelle ich eine Zwei-Faktor Variante von der indirekt indiziertes Bild-Einmal-PIN-Liste vor :
Man könnte anstatt der Einmal-PIN Liste auch einen Account PIN benutzen (Abbildung 107).
Abbildung 107: Abhörsichere PIN Eingabe
Der Ablauf wäre sehr ähnlich. Der Benutzer erhält entweder seine persönliche Bild-PIN Karte oder
einen Stapel durchnummerierte iiBild-PIN Karte, wo jede Karte unterschiedliche Bilderanordnungen
bzw. Bilder haben kann. Der Benutzer schaut dann auf der Anmeldeseite nach den Ziffern und
vergleicht sie mit der Karte und der ersten Bilderreihe (1). In unserem Beispiel ist seine Account PIN
"394184" und er schaut nach, wo die "3" abgebildet ist. In unserem Beispiel ist es der Apfel und er
befindet sich an erster Stelle der zweiten dreier Gruppe. Er geht dann mit seiner PIN weiter und
schaut an welcher Stelle die anderen Bilder seiner PIN stehen und gibt sie dann ein. Hat er alle
korrekt eingegeben, dann wird er in sein Account eingeloggt.




7.2.3
Der Benutzer braucht die PIN und die iiBild-PIN Karte um sich zu authentifizieren. Somit
könnte der Angreifer sich nicht einloggen, falls er nur die PIN kennt oder die iiBild-PIN Karte
besitzt. Damit ein Angreifer sich erfolgreich einloggen kann, benötigt er beides gleichzeitig. ⇒
R1und R5 gilt, da man beides braucht und die Karte nur mit einigem Aufwand zu besorgt
werden kann.
Wie bei der Ein-Faktor-Authentifizierung wären Phishingversuche durch die Bilder erschwert.
⇒ R2 gilt.
Die Eingabe der PIN wäre abhörsicher, da Trojaner nicht erkennen können, welche Ziffern
eingegeben werden. ⇒ R3 gilt.
Die Gefahr von Man-in-the-Middle Angriffen besteht weiterhin. ⇒ R4 gilt daher
eingeschränkt.
Linien-PIN
Mit dem Linien-PIN Verfahren wäre auch eine Zwei-Faktor Variante möglich: Anstatt von Einmal-PINs
könnte man einen Account PIN anwenden, den man jedes Mal eingeben muss. Dabei befinden sich
114
auf der indizierten Liste Linien die auf die graue Kästchen zeigen. Jeder Index hat dabei andere Linien,
die auf andere Kästchen zeigen.
Abbildung 108: Linien-PIN als Zwei-Faktor Authentifizierung
Die Sicherheitsrisiken wären mit der indirekt indizierten Einmal-Bild-Liste Verfahren vergleichbar.
7.2.4
Visuelle-PIN
Bei einer Zwei-Faktor Variante des viusellen-PINs wäre es auch möglich, dass der Benutzer bei der
Eingabe des Benutzernamens aufgefordert wird, die entsprechende Folie vor dem verschlüsselten
Bild zu legen um z.B. ein Eingabefeld für die PIN zu sehen und sie dann damit eingeben kann
(Abbildung 109).
Abbildung 109: Mögliche Anzeige der PIN Eingabe
Die Sicherheit R1-R5 von vPIN erhöht sich entsprechend der Ein-Faktor Variante gegenüber Diebstahl
und Verlust, da man nur mit der Kombination mit dem Account PIN in der Lage ist sich einzuloggen.
115
7.3 TAN-Generatoren als symbiotische Zwei-Faktor Authentisierung
Eine Variante um z.B. RSA SerurID Token, sm@rt-TAN, sm@rtTAN plus oder sm@rtTAN optic in eine
symbiotische Zwei-Faktor Authentisierung umzuwandeln, wäre, wenn man anstatt einer TAN die
Ziffernfolge 0-9 für die Eingabe permutiert darzustellen. Wie in Abbildung 110 dargestellt, zeigt das
Token kein Einmalpasswort an, sondern jedes Mal die Ziffern an, die auf der Anmeldeseite verdeckt
angezeigt wird. Der Benutzer kann dann darüber indirekt seinen Account PIN eingeben.
Abbildung 110: Token zeigt die Zifferdarstellung an, die man bei der Anmeldeseite für die PIN anklicken muss.
Solche Anzeigen wie in Abbildung 110 könnte man auch mit den anderen Generatoren darstellen.
Wichtig dabei ist, dass die Darstellung einzigartig ist und vom Gerät abhängt. So muss man sie als
entsprechend registrieren und benötigt die passende Chipkarte. Die Reihenfolgendarstellung ist also
abhängig vom jeweiligem Gerät und der PIN.
Die Sicherheit R1-R5 erhöht sich, da man neben dem Besitz auch die PIN braucht und die Eingabe
gegen Trojaner sicher ist.
7.4 Fazit Symbiotische Zwei-Faktor Authentisierung
Die Unterschiede zwischen den verschiedenen Zwei-Faktor Authentifizierungen sind gering und sie
unterscheiden sich nur in Kleinigkeiten: Was das Wissen authentisiert, den Account oder den Besitz,
und wie. Der Vorteil einer symbiotischen Zwei-Faktor Authentisierung wäre, dass man den PIN
indirekt eingibt und somit gegen Trojaner abhörsicher ist.
Der Nachteil wäre, dass die Eingabe mit Passwörtern bei Low-Tech Verfahren sehr kompliziert und
langwierig wäre, wenn man die Passwortsicherheit beibehalten möchte.
Benutzt man PINs dann ist die Eingabe leichter und die Passwortsicherheit kann auch erhalten
bleiben. Die PIN selbst kann man nicht durch einen Trojaner abhören, da man auf nicht markierte
Felder mit der Maus klickt. Angreifer könnten da höchstens erkennen, ob eine Ziffer mehrmals
vorkommt bzw. Hintereinander die gleiche Ziffer angeklickt wird.
Die Kosten dürften sich nicht verändern, wenn man Ein-Faktor Authentisierungen in symbotische
Zwei-Faktor Authentisierung ändert.
8 Klassifizierung von Authentisierungsverfahren
In diesem Kapitel möchte ich die vorher vorgestellten Authentisierungsverfahren für Online Accounts
anhand ihrer Gemeinsamkeiten und Unterschiede versuchen zu klassifizieren. Dabei strukturiere ich
die Authentisierungsverfahren entsprechend nach den Methoden, die man für die Authentifiz ierung
anwendet. Der Klassenbaum in Abbildung 111 ordnet dabei nicht die einzelnen Verfahren den
Klassen zu.
Ich teile die Authentisierungsverfahren in Oberklassen, Hauptklassen und Unterklassen ein. Zu den
116
Oberklassen gehören: No-Tech, Low-Tech oder High-Tech. Dabei gehören unter No-Tech die
Authentisierungsverfahren, die keinerlei Hilfsmittel von Seiten des Benutzers benötigen, um sich zu
authentisieren. Unter Low-Tech ordne ich Verfahren ein, für die der Benutzer keine elektronischen
Hilfsmittel benötigt, um sich zu authentisieren. So würden alle Verfahren, die auf Wissen beruhen,
unter der Kategorie No-Tech gehören, da der Benutzer sein Passwort usw. merken kann. Einige
Verfahren, die auf Besitz beruhen, wie z.B. Papierlisten, werden unter Low-Tech kategorisiert. Unter
High-Tech ordne ich die Verfahren ein, die elektronische Hilfsmittel (Hardware, Software) für eine
Authentisierung benötigen. So gehören alle Verfahren, die Persönliche Merkmale einsetzen, zu HighTech, da sie ohne technisch hoch entwickelte Hilfsmittel nicht überprüft werden können (Scanner,
Software usw.).
Die nächste Unterscheidung wäre klassischerweise die Einteilung nach der angewandten Methode.
Die Hauptklassen wären: Wissen, Besitz und Persönliche Merkmale.
Wobei Wissen aus Symbolen besteht, deren korrekte Reihenfolge der Benutzer kennen muss. So
kann man die Hauptklasse Wissen nach den Symboltypen unterscheiden. Sie können z.B. aus Bildern
oder auch aus einem Passwort aus der Menge aller Groß- und Kleinbuchstaben inkl. Zahlen und
Sonderzeichen bestehen. Oder auch aus deren Untermenge wie die PIN, die nur aus Zahlen besteht.
Die Klasse Besitz kann weiter in weitere Unterklassen unterschieden werden, abhängig davon mit
welchem Gegenstand man sich authentisiert.
Auch kann die Klasse Persönliche Merkmale weiter in Unterklassen nach den Merkmalen, die man für
eine Authentisierung benötigt, unterteilt werden. Das wären z.B. Fingerabdrücke, Iris, Gesicht,
Stimme oder Unterschriften. Denkbar wären aber auch z.B. die Tastatureinschläge des Benutzers, die
sich auch unterscheiden können. Sie wären aber eher geeignet um si ch damit Zugang zu Räumen zu
verschaffen oder als Sicherheitssystem für Geräte zu benutzen.
Eine Unterklasse vom Besitzfaktor wäre auch die Zwei-Wege-Kommunikation-Authentifizierung. Sie
unterscheidet sich von den anderen Besitzfaktoren dadurch, dass sie mehrere Kommunikationswege
für eine Authentisierung benötigt.
Eine weitere Unterklasse wäre eine Kombination von zwei Klassen (Besitz, Wissen, Persönliche
Merkmale): Die Zwei-Faktor-Authentifizierung. Diese lässt sich in weitere Unterklassen unterteilen,
die sich danach unterscheiden, wie die zwei Faktoren zur Authentisierung angewandt werden:
Unabhängige Zwei-Faktor-Authentifizierung (Authentisierung in zwei Schritten), Abhängige-ZweiFaktor-Authentifizierung (Ein Faktor als Sicherheitssystem für den zweiten Faktor) oder
Symbiotische-Zwei-Faktor-Authentisierung (beide Faktoren werden kombiniert zur Authentisierung
des Online Accounts benutzt). Entsprechend diesen Merkmalen kann man die vorher vorgestellten
Authentisierungsverfahren dann näher kategorisieren.
Ich werde in Kapitel 10 die Authentisierungsverfahren miteinander vergleichen und dabei diese
Klassifizierung benutzen und sie danach einteilen.
117
Abbildung 111: Klassifizierung von Authentisierungsverfahren
118
9 Single Sign On
Als nächstes möchte ich ein paar Single Sign On Verfahren vorstellen, d.h. man kann sich z.B. mit dem
gleichen Benutzernamen und Passwort auf mehrere verschiedene Accounts einloggen. Bevor ich
aber auf diese Verfahren eingehe, möchte ich zuerst ein paar Grundbegriffe einführen. Ich werde
danach Techniken für SSO Verfahren und Kerberos vorstellen und im Anschluss einige SSO Verfahren
näher anschauen.
9.1 Identity Management
Der Oberbegriff für Single Sign On (SSO) ist das Identitätsmanagement (IdM) [IdM, 2011]. Dabei soll
das IdM Identitäten, auch anonyme, verwalten. Dabei kann es zu unterschiedlichen Anforderungen
an das IdM kommen, je nachdem wo es eingesetzt werden soll: In einem Unternehmen oder im
Internet. So kann im Unternehmen die Verwaltung der Zugriffsrechte einer Person und im Internet
die Verwaltung von verschiedene Identitäten einer Person wichtig sein. Wie in der realen Welt,
möchte man auch im virtuellen Internet nicht alles von sich preisgeben. So können enge Freunde die
eigene Telefonnummer und Adresse erfahren, aber dem Supermarktverkäufer gibt man ungern
persönliche Einzelheiten weiter, die nicht unbedingt für die Kaufabwicklung nötig sind. So gibt es
auch im Internet für die gleiche Person verschiedene Identitäten, je nachdem welchen Onlinedienst
man benutzt. Und selbst bei gleichen Onlinediensten kann es zu verschiedenen Identitäten kommen.
Bei eBay kann man als Käufer oder als Verkäufer auftreten. Auch die Käuferidentität kann
unterschiedlich sein, ob man als Privatperson oder Angestellter einer Firma einkauft [ULD, 2008] .
9.2 Identität
Unter der Identität einer Person versteht man im Allgemeinen eine Menge von Daten, durch die eine
Person in einem bestimmten Zusammenhang eindeutig von anderen Personen unterschieden
werden können. Der Datensatz mit dem man eine Person definiert nenne ich hier Identitätsdaten.
Mit diesen Identitätsdaten lässt sich normalerweise ein Account einrichten und eine Person
identifizieren. Normalerweise gibt es unterschiedliche Arten von Identitätsdaten, die man
miteinander verknüpfen könnte: So kann eine soziale Identität (z.B. eine Privatperson mit folgenden
Daten: Name, Adresse, Geburtsdatum, usw.) durch technische Maßnahmen mit weiteren
Identitätsdaten (in Software und Hardware) gebunden werden [Borges, Schwenk, Stuckenberg, &
Wegener, 2011]: Benutzername/Passwort, E-Mail-Adresse, Telefonnummer usw.
Beispiele für eine Bindung mit technischen Maßnahmen sind z.B. eine Bestätigungsmail in der ein
Passwort an die E-Mail-Adresse gesendet wird. Oder auch Zertifikate bzw. ein Single-Sign-On-Token:
Die Aussage einer Identität wird von einem Authentifizierungsserver an den Onlinedienst übermittelt
(SAML/OAuth).
In der Praxis ist eine Verkettung von Identitäten üblich. Dabei ist der Ausgangspunkt die soziale
Identität. Diese wird mit einem juristischen Vertrag an eine erste technische Identität gebunden, die
mit Hilfe von technischen Maßnahmen an weitere technische Identitäten gebunden werden. So ist
z.B. der neue Personalausweis (nPA) eine erste technische Identität. Beispielsweise könnte eine
Verkettung so aussehen:

Ein Benutzerkonto eines Internetproviders, bei der Benutzername und Passwort die
Identitätsdaten sind. Das Benutzerkonto ist durch einen Vertrag mit dem Internetprovider an
die Rechnungsadresse (die soziale Identität und damit der Ausgangspunkt) gebunden. Durch
119

das Benutzerkonto erhält der Benutzer auch eine E-Mail-Adresse (eine weitere technische
Identität).
Die E-Mail-Adresse mit einem Passwort geschützt ist nun eine weitere Identität. Damit kann
der Benutzer nun bei einem anderen Onlinedienst einen Account eröffnen, der durch eine
Bestätigungsmail an die angegebene E-Mail-Adresse gebunden und verifiziert wird.
Für einen Account reicht normalerweise die Identitätsdaten Benutzername und Passwort. Damit
kann ein Angreifer auf ein Account zugreifen und er benötigt weitere Identitätsdaten wie z.B. die
soziale Identität nur, wenn der Angreifer mehr als nur Zugang zu einem Account haben möchte, wie
z.B. bei Kreditkartenbetrug.
9.3 Techniken für SSO
Single Sign On (SSO) Systeme können eine technische Umsetzung von Identitätsmanagement sein.
Dabei steht das Ziel im Vordergrund, dass sich der Benutzer auf ein System nur einmal Einloggen
muss und dann verschiedene Dienste benutzen kann, ohne sich auch für diese jeweils authentisieren
zu müssen. Das bedeutet die einfache und schnelle Bedienbarkeit steht im Vordergrund. Ein
Benutzer muss im Internet viele Identitäten verwalten und es würde sonst viel Zeit kosten, sich für
jeden unterschiedlichen Dienst einen Benutzerkonto erstellen zu müssen und sich damit dann
einzuloggen. SSO wird für das Internet interessant, da man mit der Zeit viele Accounts besi tzen kann,
deren Verwaltung kompliziert sein kann. So müsste man sich beispielsweise viele Benutzernamen
und Passwörter merken. SSO bietet da eine Lösung an, wie man nur mit einem Benutzernamen und
Passwort sich auf verschiedene Onlinedienste anmelden kann. Das würde neben den
Authentisierungen auch Accounterstellungen erleichtern. Bisher hat sich SSO noch nicht durchgesetzt
und meistens bietet jeder Onlinedienst eine eigene Authentisierung an. SSO wird eher in
geschlossenen Systemen angewandt und daher gibt es Insellösungen, die nicht kompatibel zu
anderen Systemen sind. Das könnte sich in Zukunft ändern und neben der Einfachheit sollte auch die
Sicherheit eine höhere Bedeutung gewinnen. Dabei wurden Protokolle wie OAuth [Hueniverse, 2011]
und SAML [OASIS, 2008] entwickelt, die einen Standard und die nötige Sicherheit schaffen sollen. So
können verschiedene Dienste mit dem Standard untereinander kommunizieren.
Damit ein Dienst feststellen kann, ob jemand schon eingeloggt ist und somit nicht nochmal überprüft
werden muss, wird im Intranet gerne Cookies benutzt. Der Webbrowser speichert somit bei sich ein
Cookie ab, über die ein Dienst feststellen kann, ob er schon eingeloggt ist. Bei Domainübergreifenden
Diensten wie es im Internet üblich ist, stoßt man auf ein Problem. Der Zugriff auf ein Cookie über den
Webbrowser ist von der Domain abhängig und unterschiedliche Domains können nicht auf den
gleichen Cookie zugreifen. Dennoch greifen viele SSO Dienste auf ein Cookie zurück um festzustellen,
ob ein Benutzer bereits eingeloggt ist. Dies kann durch ein sogenanntes Cross Domain Cookie
verwirklicht werden. Dabei können Informationen, die eine Domain über einen Cookie abgespeichert
hat, beispielsweise über die URL Parameter, an eine andere Domain übergeben werden. Dies
funktioniert über miteinander kooperierende Netzwerke. Die Authentifizierung übernimmt also beim
SSO Verfahren nicht der Onlinedienst selber, sondern ein Identitätsprovider, mit dem er kooperiert,
und der eine Session im Cookie im Browser ablegen und weitergeben kann. Viele Browser
akzeptieren sogenannte Third Party Cookies oder man kann sie entsprechend einstellen.
120
9.3.1
Kerberos
Kerberos ist eines der ältesten SSO tauglichen Protokolle und wurde vom MIT entwickelt, für eine
sichere Anmeldung über ein offenes und unsicheres Netzwerk. Ursprünglich sollte es
Netzwerkdienste für das Projekt Athena schützen, also ein geschlossenes Netzwerk, aber es kann
auch für das Internet genutzt werden. Projekt Athena begann 1983 und war ein
Gemeinschaftsprojekt von MIT, Digital Equipment Corporation und IBM um eine Campusweite
Rechnerumgebung für Lehrzwecke zu erstellen. Steve Miller und Clifford Neuman entwickelten das
Kerberos Protokoll, basierend auf das symmetrische Needham-Schroeder-Protokoll und erst an
Version 4 wurde es außerhalb vom MIT benutzt [Kerberos, 2011]. Die Sicherheit des Protokolls wurde
gut untersucht und man hat bisher keine großen Schwachstellen gefunden [Borges, Schwenk,
Stuckenberg, & Wegener, 2011]. Das Protokoll wird u.a. auch in Microsoft Windows 2000 für die
Benutzerauthentifizierung benutzt (Active Directory). Das Kerberos Protokoll basiert auf
symmetrische Verschlüsselung wie DES, 3DES und mit Kerberos 5 wird auch AES unterstützt.
Ablauf:
Für das Kerberos Protokoll benötigt man drei Parteien: der Client (Benutzer), der Server
(Onlinedienst) bei dem sich der Benutzer einloggen möchte, und der Kerberos Server. Der Kerberos
Server ist eine vertrauenswürdige dritte Partei, auch Key Distribution Center (KDC) genannt. Der KDC
verwaltet eine Datenbank mit geheimen (symmetrischen) Schlüsseln: Jede Einheit im Netzwerk,
entweder der Benutzer oder der Onlinedienst, teilen einen geheimen Schlüssel, den nur sie selber
und der KDC kennen. Der KDC besteht dabei aus zwei logisch getrennten Teilen: Dem Authentication
Server (AS) und einem Ticket Granting Server (TGS) [Kerberos, 2011]. Um Man-in-the-Middle Angriffe
vorzubeugen, authentifiziert sich der Kerberos Dienst sowohl den Onlinedienst gegenüber dem
Benutzer und auch den Benutzer gegenüber dem Onlinedienst. Auch der KDC authentifiziert sich
gegenüber dem Benutzer und dem Onlinedienst und verifiziert deren Identität. Das Protokoll
verwendet dabei verschlüsselte und nur für kurze Zeit gültige Tickets zur Authentifizierung. Dabei
wird vom KDC Session Key zur Kommunikation generiert, welche man auch zur verschlüsselten
Kommunikation verwenden kann. Der grobe Verlauf sieht folgendermaßen aus:
Der Benutzer authentifiziert sich beim AS und erhält einen Ticket mit einem Zeitstempel. Der
Benutzer kontaktiert dann den TGS um einen Dienst (z.B. einen Onlinedienst) anzufordern. Er benutzt
dabei das Ticket um sich zu identifizieren. Darf der Benutzer den Dienst benutzen, dann erhält er ein
weiteres Ticket. Der Benutzer meldet sich dann beim Onlinedienst an und benutzt das zweite Ticket
um zu beweisen, dass er für den Dienst die Erlaubnis hat.
SSO mit Kerberos Protokoll:
Im Folgenden erläutere ich das Protokoll durch Authentifizierung mit einem Passwort näher.
121
Abbildung 112: Ticket Granting Ticket
1. Der Benutzer möchte ein Ticket Granting Ticket (TGT) und gibt schickt seinen Benutzernamen als
Klartext an den KDC (bzw. AS). Es wird weder das Passwort oder den geheimen Schlüssel
übertragen.
2. Der AS überprüft in der Datenbank, ob der Benutzer existiert und holt den Benutzerpasswort (z.B.
kann man einen geheimen Schlüssel generieren indem man das Passwort hasht, wie Active
Directory in Windows Server [Kerberos, 2011]) und den KDC-Serverkey (bzw. den geheimen
Schlüssel vom TGS). Er generiert eine TGS Sessionkey.
3. Der KDC schickt eine Antwort mit 2 Nachrichten, die folgende Informationen enthalten:
 Nachricht A enthält den Schlüssel: TGS Sessionkey für Benutzer+ ServerID von KDC. Die
Nachricht A wird mit dem Benutzerpasswort verschlüsselt.
 Nachricht B ist das TGT und wird später benötigt, um beim TGS Tickets für Onlinedienste
zu erhalten. Es enthält u.a dem TGS Sessionkey für Benutzer und die BenutzerID vom
Benutzer (es kann auch die IP vom Benutzer, Gültigkeitsdauer des Tickets enthalten). Die
Nachricht B wird mit dem TGS Serverkey verschlüsselt.
4. Der Benutzer gibt sein Passwort ein und kann damit Nachricht A Entschlüsseln. Damit ist er im
Besitz des TGS Sessionkeys zwischen dem Benutzer und dem TGS. Dies dient als geheimer
Schlüssel für die zukünftige Kommunikation mit dem TGS. Nachricht B (TGT) kann er nicht
entschlüsseln.
5. Das TGT wird im Ticket Cache für spätere Verwendung gespeichert. Ab diesem Zeitpunkt hat er
genug Informationen um sich beim TGS zu authentisieren und es ist keine Passworteingabe mehr
nötig.
Nun möchte sich der Benutzer auf einen Onlinedienst einloggen und benötigt ein Ticket vom TGS
dafür:
122
Abbildung 113: Anmeldung auf einem Onlinedienst
1. Benutzer verlangt vom KDC (TGS) ein Ticket für einen bestimmten Onlinedienst mit der Vorlage
des TGT. Die Anforderung kann zwei Nachrichten enthalten:
 Nachricht C: Erstellt aus dem TGT von Nachricht B und der IP für den Onlinedienst.
 Nachricht D: Authenticator (z.B. BenutzerID und einem Zeitstempel), welches mit dem
TGS Sessionkey aus Nachricht A verschlüsselt wurde.
2. TGS sucht den Benutzer- und den Serverschlüssel in der Datenbank und generiert eine
Sessionkey für Benutzer und Onlinedienst. Dabei entschlüsselt der TGS mit seinem TGS Serverkey
die Nachricht B aus der Nachricht C und erhält so den TGS Sessionkey mit dem Benutzer. Damit
kann der TGS die Nachricht D entschlüsseln.
3. Der TGS nun zwei Nachrichten an den Benutzer:
 Nachricht E enthält den Schlüssel: Sessionkey für Benutzer und Onlinedienst, welche mit
dem TGS Sessionkey zwischen Benutzer und TGS verschlüsselt wird.
 Nachricht F enthält das Ticket zur Vorlage gegenüber dem Onlinedienst (also das
Benutzer-Onlinedienst Ticket): Es enthält die Benutzer ID und die Sessionkey für
Benutzer und Onlinedienst. Es kann auch die Benutzer IP und Gültigkeitsdauer enthalten
und wird mit dem Serverschlüssel vom Onlinedienst verschlüsselt.
4. Der Benutzer entschlüsselt die Nachricht E mit dem TGS Sessionkey und ist so im Besitz des
Sessionkeys zwischen dem Benutzer und dem Onlinedienst. Die Nachricht F ist das Ticket und
wird im Ticket Cache gespeichert.
5. Der Benutzer hat nun genug Informationen um sich gegenüber dem Onlinedienst zu
authentisieren und verschickt 2 Nachrichten (ein sog. Authentication credentials, gebildet aus
Ticket und Authenticator):
 Das Ticket für den Onlinedienst (d.h. die Nachricht F, welche mit dem geheimen
Serverschlüssel des Onlinedienstes verschlüsselt wurde).
 Nachricht G: Ein neuer Authenticator, welches die BenutzerID, Zeitstempel enthalten
kann und mit dem Sessionkey zwischen dem Benutzer und dem Onlinedienst
verschlüsselt wurde.
123
6. Der Server kann das Ticket (Nachricht F) nun entschlüsseln und ist im Besitz der Sessionkey
zwischen dem Benutzer und dem Onlinedienst. Mit diesem Sessionkey ist nun die verschlüsselte
Kommunikation zwischen Benutzer und Onlinedienst nun möglich. Damit kann er den
Authenticator (Nachricht G) entschlüsseln und wenn nötig auch den Zeitstempel vom Benutzer
bestätigen lassen um zu überprüfen, ob der Benutzer den Onlinedienst trauen kann.






R1-R5 sind mindestens so gut wie beim Passwortverfahren.
Der Benutzer ist wie beim Passwortverfahren ein Sicherheitsrisikofaktor: Phishing und
Keylogger bei Passwörtern.
Es muss weiterhin wie beim Passwortverfahren sichere Passwörter verwendet werden.
Speicherorte (KDC und Ticket Cache) müssen gut geschützt.
Der KDC sollte abgesichert sein, denn ist er down, dann ist kein Login mehr möglich.
Das auf Needham-Schroeder Protokoll basierende Authentifizierungsdienst an sich wurde
bereits gut untersucht und es sind keine größeren Lücken bekanntgeworden.
9.4 SSO Verfahren
Kerberos dient als Grundlage für die meisten SSO Verfahren. Ich werde nicht alle auf den Markt
befindlichen SSO Verfahren näher vorstellen, da der eigentliche Loginvorgang sich meist ähnelt und
nur der jeweilige Anbieter des Identity Provider, mit dem man die Authentifizierungsinformationen
austauscht bzw. zu der man sie weiterleitet, unterschiedlich ist. Es werden dabei Tickets, Tokens,
Assertions etc. ausgetauscht, je nachdem welches Protokoll da zugrundeliegt.
9.4.1
OpenID
OpenID wurde 2005 durch eine Open Source Community entwickelt um Probleme wie zu viele
Passwörter und Benutzerprofile für verschiedene Accounts zu lösen. Es sollte dem Benutzer
ermöglichen, nur einen Wunschbenutzernamen zu erstellen und sie für alle möglichen Accounts zu
benutzen. An eine Erhöhung der Sicherheit wurde dabei nicht gedacht, sondern an eine
Vereinfachung der Anmeldung an einer Webseite. Es wurde als offener Standard entwickelt und die
Software besteht ausschließlich aus Open Source Lizenzen und das Protokoll ist offengelegt, so dass
die Implementierungen in vielen Programmiersprachen existieren [OpenID, 2011]. Eine OpenID oder
ein OpenID Provider sollte kostenlos und frei sein, ohne eine überwachende Organisation [OpenID
Foundation, 2006-2011]. Es ist ein dezentrales Authentifizierungssystem und jeder kann ein OpenIDProvider werden und einen OpenID-Server betreiben. Es gibt also keinen zentralen Server wie bei
Microsoft Passport. Es soll die Anmeldungen auf Webseiten vereinfachen und das Konzept ist eine
URL oder XRI (Extension Resource Identifier)-basierte Identität. Man kann sich also mit einer URL auf
verschiedene Accounts einloggen. Zusätzlich kann man bestimmen, wieviel Information (Name, EMail Adresse usw.) jede Webseite erhalten soll. Nur der Identity Provider (OpenID Provider) kennt
dabei das Passwort und dieser Provider bestätigt die Identität des Benutzers, wenn er eine
bestimmte Webseite aufsucht. Man braucht also nur eine BenutzerID (d.h. die URL des Identity
Providers, sog. OpenID-URL) und ein Passwort für unterschiedliche Accounts zu merken. OpenID wird
von einigen Diensten benutzt, wie Google, Yahoo!, flickr, myspace98 .
98
http://openid.net/get-an-openid/
124
Ablauf:
Abbildung 114: OpenID Datenfluss 99
1. Möchte sich der Benutzter auf einer Webseite anmelden, die OpenID unterstützt, so
erscheint auf der Webseite des Onlinedienst (Relying Party) die Möglichkeit sich mit der
OpenID über eine Anmeldeform anzumelden.
Abbildung 115: Anmeldeform mit OpenID 100
In diese Anmeldeform gibt er nur seine OpenID, die in Form einer URL dargestellt wird. In
unserem Beispiel ist die OpenID bobsmith2000.myopenid.com. Man gibt dabei nur die
OpenID ein und kein Passwort.
Abbildung 116: Ausgefüllte OpenID 101
2. Mit OpenID 2.0 identifiziert der Onlinedienst den OpenID Provider über einen XDRS
Dokument (auch Yadis Dokument genannt), den er über einen Identity Server erhält. Mit
OpenID 1.0 fällt dieser Schritt weg, da der Onlinedienst die URL über den HTML Link Tag
ausliest, den er über die eingegeben URL in Punkt 1 erhält.
3. Der Onlinedienst kann dann mit dem OpenID Provider einen gemeinsamen geheimen
Schlüssel vereinbaren. Dies ist aber optional.
4. Hat der Benutzer seine OpenID eingegeben und abgeschickt, wird er vom Onlinedienst, der
nun die URL des OpenID Providers kennt, zu seinem OpenID Provider umgeleitet und der
99
http://leancode.com/category/openid/
http://openid.net/get-an-openid/start-using-your-openid/
101
100
125
Benutzer muss sich dort authentisieren. Ist er schon beim OpenID Provider eingeloggt, dann
überspringt er den nächsten Punkt.
5. Ist der Benutzer nicht schon beim OpenID Provider angemeldet, muss er sich jetzt mit
seinem Benutzernamen und Passwort einloggen.
6. Hat der Benutzer sich beim OpenID Provider authentisiert, dann wird das OK vom OpenID
Provider über den Benutzer an den Onlinedienst geschickt und er kann auf die Webseite des
Onlinedienstes zugreifen. Hat er sich dort zum ersten Mal eingeloggt, kann es sein, dass der
Benutzer zusätzlich noch bestätigen muss, dass er sich dort einloggt und eventuell der
Onlinedienst Daten (z.B. Name und E-Mail Adresse) verlangt, die der Benutzer erlauben muss.
Falls der Onlinedienst und der OpenID Provider vorher einen geheimen Schlüssel vereinbart
haben, kann man dadurch feststellen, ob die Daten tatsächlich vom OpenID Provider
stammen.
Abbildung 117: Beispiel einer Datenfreigabe bei OpenID 102








102
Auch hier wird mit einem Passwort die Authentifizierung vorgenommen und daher gelten
auch hier die Sicherheitsrisikofaktoren R1 und R5 wie beim Passwortverfahren für den
Benutzer und das Passwort.
Durch Fehlerhafte Implementierungen wie z.B. der OpenID-Erweiterung Attribute Exchange
[Datenschutzbeauftragter, 2011] können Angreifer Informationen verändern und
manipulieren (sozusagen ein Man-in-the-Middle Angriff bzw. XSS starten).
Sollte ein Benutzer sich nicht ausloggen, könnte der nächste Benutzer darauf zugreifen, da
die Daten gespeichert bleiben.
Die Spezifikation empfiehlt SSL, aber Verschlüsslungen sind nicht erforderlich und können
daher zum Risikofaktor werden: Abhören, Phishing, Man-in-the-Middle Angriff
Replay Angriffe soll durch gewürfelte Einmaltransaktionsnummern verhindert werden:
Angreifer gewinnt, wenn er schneller als der Benutzer ist.
Nur eine ID und somit leicht korrelierbar.
Pro Benutzer auch nur eine zentrale IdP und somit geeignet zum Profilen.
Identität eines Benutzers wird bestätigt von einer dritten Instanz:
o Sie muss nicht vorher bekannt sein.
126

9.4.2
o Deren Policy und Sicherheitsstandards können unklar sein.
o Problem könnte umgehen werden, wenn man einen eigenen IdP erstellt.
Onlinedienst muss beliebige URL runterladen, die der Benutzer als ID eingibt:
o DoS103 möglich durch große Dateien.
o Angriffsmöglichkeit auf interne Netze möglich.
o Portscans vom Onlinedienst auf andere Rechner aus möglich.
Shibboleth104
Shibboleth ist eine standardisierte Open Source Software Packet für Single Sign On
Webanwendungen und Webservices. Es basiert auf SAML und wurde von Internet2/MACE
(Middleware Architecture Committee for Education) entwickelt und wird zurzeit hauptsächlich in
wissenschaftlichen Bereichen und Lehre angewendet. Damit können verschiedene Universitäten auf
geschützte Ressourcen zugreifen und brauchen sich dabei nur einmal Authentisieren.
Ablauf105 :
Abbildung 118: Demonstrationsablauf für Shibboleth 106
1. Der Benutzer von Universität B möchte sich auf www.resource.ex einloggen um Zugriff auf
Medical Training 1 zu erhalten. Der Onlinedienst überprüft, ob eine Shibboleth Session schon
existiert (über Cookies). Falls eine Session für den Benutzer existiert, überprüft der
Onlinedienst:
a. ob sie noch gültig ist (wie lange der Benutzer inaktiv war, session timeout nach
normal einer Stunde)
b. ob die Session nicht abgelaufen ist (session lifetime hält normal acht Stunden)
c. die Maximumzeit nach der letzten Authentifizierung nicht überschritten wurde.
103
Deniel of Service: Überlastung von Diensten
http://shibboleth.internet2.edu /
105
http://www.switch.ch/aai/demo/
106
http://www.switch.ch/aai/demo/2/simple.html
104
127
Der Onlinedienst findet in der Session die Daten, die der Identitätsprovider (in unserem
Beispiel Heimanbieter des Benutzers) in einer Assertion bereitgestellt hat. Hatte sich der
Benutzer schon mit Shibboleth auf ein anderes Projekt eingeloggt und der Onlinedienst
findet eine Session, wobei eine der Bedingungen gültig ist, dann hat er gleich Zugriff darauf.
Ansonsten wird er zum Discovery Service (bzw. WAYF - Where are you from ) umgeleitet, da
der Onlinedienst den Heimanbieter des Benutzers nicht kennt. In unserem Beispiel zu
www.wayf.ex.
Abbildung 119: Benutzer möchte sich auf eine Webseite einloggen.
2. Der Discovery Service bietet eine Liste von Heimanbietern an, von denen sich der Benutzer
eine aussuchen muss. Wählt der Benutzer einen Anbieter aus, dann wird er zurück an den
Onlinedienst umgeleitet der die Authentisierungsanfrage dann über den Browser des
Benutzers an den Heimanbieter sendet. Falls der Discovery Service einen Cookie abgelegt hat,
das den Identitätsprovider des Benutzers enthält, dann wird der Webbrowser des Benutzers
direkt darauf umgeleitet.
Abbildung 120: Auswahl des Heimanbieters
3. Der Heimanbieter (als Identitätsprovider) überprüft, ob der Benutzer sich bereits eingeloggt
hat und schaut nach, ob eine Session des Benutzers bereits exi stiert und überprüft in der
Session ob:
a. die Session noch gültig ist (session timeout nicht abgelaufen ist, normalerweise nach
30 Minuten)
b. die die Authentifizierungsmethode107 noch gültig ist (Inaktivität, d.h. authentication
method timeout ist normalerweise bei 30 Minuten für Benutzername/Passwort)
c. ob das Attribute forceAuthn nicht gesetzt ist (zwingt eine Authentifizierung)
Falls eine der Punkte nicht gültig ist, dann erscheint auf dem Browser des Benutzers nun die
Loginseite seines Heimanbieters und er kann sich mit einem Benutzernamen und Passwort
107
z.B. PKI, Benutzername/Passwort
128
einloggen. Der Sessionablauf basiert auf die Inaktivität des Benutzers, nach jeder
Authentifizierungsanfrage wird die Session aktualisiert. Falls die Session abgelaufen ist, dann
werden die authentication method timeouts gelöscht.
Abbildung 121: Authentisierung des Benutzers
4. War die Authentisierung erfolgreich, dann wird der Benutzer zurück auf die Webseite
umgeleitet, auf die er ursprünglich zugreifen wollte. Der Onlinedienst entscheidet dann, ob
die Daten, die der Heimanbieter übermittelt hat genügen, um den Benutzer Zugang zu
erlauben. Die Session wird entsprechend in einem Cookie gespeichert und bleibt solange
aufrecht, bis die Session abgelaufen ist.
Abbildung 122: Benutzer hat den Zugang erhalten


Der Benutzer authentisiert sich mit einem Passwort und daher gelten auch die möglichen
Sicherheitsrisiken R1-R5 für Passwortverfahren, z.B. unsichere Passwörter und Benutze r.
Um möglichst alle Risiken zu vermeiden, sollte man immer aktuell und die neueste Version
benutzen. Das gilt für Shibboleth als auch auf die darauf basierende XML- Framework SAML
(zurzeit Version 2.0). Man sollte daher auch die empfohlenen Sicherheitssysteme benutzen
wie SSL, TLS usw.
129
9.4.3
Liberty Alliance Project
Das Liberty Alliance Project, basierend auf das SAML Protokoll, wurde 2001 von Sun
Microsoftsystems vorgestellt und die zentrale Idee dahinter ist die sogenannte Föderierte Identität
(Federated Identity). Dabei bildet die Liberty Alliance die Brücke zwischen verschiedenen
Organisationen mit jeweils eigenem Identitätsmanagement innerhalb ihrer eigenen Umgebung. Dies
wird mit dem Circle of Trust verwirklicht. Dabei ist ein Circle of Trust zwischen dem Benutzer und
dem Identitätsprovider (IdP), der die Identitäten verwaltet und der andere Circle of Trust ist zwischen
dem Identitätsprovider und Onlinedienst. Es sollte dabei eine dezentralisierte SSO Authentifizierung
verwirklicht werden. Bei zentralisierten SSO Verfahren, wie Microsoft Windows Live ID oder
Facebook, muss man die Identitiy Provider vertrauen können und ist von deren Verfügbarkeit
abhängig.
Abbildung 123: Circle of Trust
Ablauf [Dwiputera, 2005]:
Abbildung 124: SSO Authentisierung mit Liberty Alliance
1. Der Benutzer möchte einen Dienst beim Onlinedienst benutzen.
2. Der Onlinedienst fragt den Benutzer nach dem Identitätsprovider der seine Identität in einer
Föderation verwaltet.
130
3. Der Onlinedienst leitet die Authentisierungsanfrage über den Benutzer an den IdP weiter.
Durch die Umleitung werden auch Informationen des Onlinedienstes gesendet.
4. Der IdP authentisiert den Benutzer und generiert einen SAML Token, abhängig vom Benutzer
Profil und dem Onlinedienst.
5. Der IdP sendet die Antwort an den Benutzer mit dem Token.
6. Der Benutzer übergibt den Token an den Onlinedienst.
7. Der Onlinedienst überprüft den Token indem er sich mit dem IdP in Verbindung setzt. Hat
der IdP den Token anerkannt, dann hat sich der Benutzer gegenüber dem Dienst
authentifiziert.
8. Der IdP überprüft den Token und beantwortet die Anfrage vom Onlinedienst indem er ihm
die Assertion übermittelt.
9. Der Benutzer erlaubt dem Benutzer Zugang zu seinem Dienst gemäß dem Assertion welches
vom IdP erhalten worden ist.




9.4.4
Da auch hier die Methode der Authentisierung nicht festgeschrieben ist und man meistens
Passwörter benutzt, sind auch hier die Risiken R1-R5 wie beim Passwortverfahren (Brute
Force, Replay, Phishing. XSS, usw.) vorhanden.
Übertragungen sollten abgesichert sein und Liberty Alliance empfiehlt SSL.
Gefahren von Absprachen und Missbrauch zwischen den Onlinedienstes innerhalb des Circle
of Trust, die nicht im Sinne des Benutzers sind. Liberty Alliance Spezifikation sollte
sicherstellen, dass jeder Onlinedienst ein einzigartiges Pseudonym des Benutzers erhält.
Sicherheitslücken in SAML könnten auch Liberty Alliance treffen und sollten immer auf den
neuesten Stand sein.
Facebook Connect (FB Connect)
FB Connect wurde 2009 veröffentlicht und anders wie z.B. OpenID nicht nur als SSO Verfahren
konzipiert. Facebook nutzt die Vorteile als Soziales Netzwerk aus und verbindet SSO mit drei
Grundelementen des Social-Webs [Pfefferle, 2010]:



Identity (Zugriff auf Facebook-Profil-Daten möglich, Änderungen werden automatisch an den
angeschlossenen Plattformen verteilt)
Social Graph (Abgleich des Facebook-Adressbuchs mit angeschlossenen Plattformen)
Activities (mit FB Connects Activity-Stream API kann man verteilte Inhalte (z.B. Bilder aus
Flickr, Video aus Youtube, Blogs aus WordPress) in Facebook zusammenführen)
Neben Facebook versuchen auch andere Soziale Netzerke, wie Twitter Auth (Sign in with Twitter),
MySpaceID, Google ID und Yahho!ID, durch eine Verschmelzung zwischen Social Connector und
Soziales Netzwerk, ein schnelles und einfaches Registrieren und Anmelden (SSO), einfaches
Verwalten von Social Graph und das Zusammenführen von Online-Aktivitäten zu verwirklichen. Was
Facebook betrifft, so ist es mit zur Zeit mehr als 800 Millionen Nutzer [Facebook, 2011] ein Anreiz für
Onlineanbieter FB Connect zu unterstützen. Dabei gibt es zwischen den Leistungen und
Funktionalitäten der verschiedenen Connect-Produkte keinen wesentlichen Unterschied. Der
wesentliche Unterschied besteht dabei nur in der Umsetzung, die sich fast beliebig ändern lässt,
ohne den Benutzer in seinem Nutzungsverhalten zu verändern. Um möglichst eine große Reichweite
zu erzielen werden offene Standards wie OpenID, SAML und OAuth unterstützt. So verwendet
131
beispielsweise Facebook OAuth 2.0. Da Standards die von MySpaceID, Google, Yahoo!ID, Sign in with
Twitter unterstützt werden bereits besprochen wurden und die Funktionalität und Leistungen sich
nicht mit FB Connect wesentlich unterscheiden, werde ich auf nicht viel näher auf sie eingehen und
nachfolgend die Funktionalität von FB Connect und deren Sicherheitsrisikofaktoren beschreiben.
Diese können auch für die anderen Connect-Produkte gelten.
Connect-Produkt
FB Connect
Twitter Auth
Google OpenID
Yahoo!ID
MySpaceID
Google Friend Connect
Zugriff auf:
Identity, Social Graph, Stream
Identity, Social Graph, Stream (+alle anderen Twitter APIs)
Identity, Social Graph (+alle anderen mit OAuth geschützten APIs)
Identity, Social Graph, Stream (+alle anderen mit OAuth geschützten APIs)
Identity, Social Graph, Stream (+ alle anderen mit OAuth geschützten APIs)
Social Graph +diverse Widgets
Tabelle 5: Leistungen von Connect-Produkten [Pfefferle, 2010]
Die Facebook Plattform unterstützt dabei zwei verschiedene OAuth 2.0 Abläufe: Server- Side Flow
(Authentication Code in OAuth Spezifikation) und Client-Side Flow (Implict Flow in OAuth
Spezifikation). Server-Side Flow wird dabei benutzt, wenn der Webserver die Graph API108 aufruft
(mit PHP SDK) und die Client-Side Flow wird benutzt wenn von einem Client (z.B. mit JavaScript SDK
vom Webbrowser, Smartphone App oder Desktop Programm) aus die Graph API aufgerufen wird.
Unabhängig vom Ablauf werden drei Schritte überprüft: Benutzer Authentifizierung (user
authentication), App Autorisierung (app authorization) und App Authentifizierung (app
authentication). Die App Autorisierung sichert dabei ab, dass der Benutze r weiß, welche Daten und
Einsatzmöglichkeiten zur Verfügung gestellt werden. Die App Authentifizierung dient dazu, dass der
Benutzer sichergehen kann, dass die Informationen an die korrekte App oder Webseite gehen. Sind
die drei Schritte erfolgreich durchlaufen, dann erhält man einen User Access Token mit der man
Zutritt zu den Informationen des Benutzers hat und auch als Benutzer handeln kann.
In unserem Ablaufbeispiel (Abbildung 127) benutzt der Onlinedienst OAuth 2.0 und JavaScript SDK.
Als Voraussetzung muss der Onlinedienst einen Facebook Account besitzen und hat seine Webseite
bei Facebook als Entwickler registriert um eine App ID und ein App Secret zu erhalten. Auf der Seite
hat er auch seine URL eingetragen, wo seine Homepage ist (Abbildung 125).
108
Kernstück von Facebook: Ermöglicht das Lesen und Schreiben von Daten auf Facebook. Es stellt eine
einfache und konsistente Darstellung des Social Graph bereit.
132
Abbildung 125 109: Basisinformationseite eines Entwicklers auf Facebook
Auf Abbildung 126 ist ein Beispiel angegeben, wie man JavaScript SDK auf der eingetragenen
Homepage laden und initialisieren kann.
Abbildung 126 110: Beispiel einer Initialisierung
109
110
http://developers.facebook.com/docs/authentication/
http://developers.facebook.com/docs/reference/javascript/
133
Ablauf [facebook Developers, 2011]:
Abbildung 127: FB Connect Funktionalität
1. Der Benutzer möchte sich auf die Webseite vom Onlinedienst anmelden. Dabei wird FB
Connect benutzt und die Authentifizierung läuft in einem iFrame komplett über Facebook ab,
um eine Cross-Domain Kommunikation zu verwirklichen. Dabei muss der Browser so
eingestellt sein, dass er Third Party Cookies akzeptiert. Der Onlinedienst leitet also die
Facebook Loginseite bzw. Button auf Facebooks OAuth Dialog um. Mit der Umleitung werden
die URI vom Onlinedienst und deren App ID mit gesendet. Facebook überprüft die Identität
und Echtheit der Anfrage der Webseite über die App ID des Onlinedienstes. Die zusätzliche
Überprüfung über die URI wird von Facebook nicht zusätzlich verlangt.
2. Facebook überprüft, ob der Benutzer sich schon eingeloggt hat, indem er nach einem
gültigen Cookie auf dem Webbrowser sucht. Er schaut also, ob ein Login Cookie existiert,
dann überprüft er den Cookie und ob die Facebook Connect Session nicht schon abgelaufen
ist. Ist der Benutzer schon eingeloggt, dann wird er direkt auf die Webseite eingeloggt bzw.
es wird nach der Erlaubnis der Datenübertragung gefragt.
134
Abbildung 128 111: Beispiel für Login mit Facbook Button
3. Ist der Benutzer noch nicht auf Facebook eingeloggt, dann wird die Authentisierungsanfrage
über den Browser an Facebook weitergeleitet. Sollte der Benutzer noch kein Konto bei
Facebook haben, dann wird er gefragt, ob er ein Konto erstellen möchte und darf sich dann
auf Facebook registrieren.
4. Beim Benutzer öffnet sich z.B. ein Popup Fenster von der Facebookseite in der er seinen
Benutzernamen und Passwort eingeben kann. Der Benutzer authentisiert sich beim
Facebookserver mit seiner E-Mail Adresse und seinem Passwort für sein Facebook Account.
Abbildung 129 112: Anmeldung auf Facebook
5. Hat sich der Benutzer erfolgreich authentifiziert, wird er dann aufgefordert die Anfrage zu
autorisieren. D.h. er muss erlauben, dass Facebook bestimmte Daten übermittelt. Neben
Basisinformationen (Namen, Profilbild, Geschlecht usw.) können auch Erlaubnisse zur
Versendung von E-Mails an den Benutzer oder Ortung von wo sich der Benutzer eingeloggt
111
112
http://developers.facebook.com/docs/guides/web/#login
135
hat erteilt werden, falls diese vom Onlinedienst angefragt wurden (Abbildung 130).
Abbildung 130 113: Erlaubnisabfrage zur Übermittlung von Basisinformationen
Abbildung 131 114: Beispiel einer Übermittlung zusätzlicher Parameter mit OAuth Dialog
Abbildung 132 115: Beispiel einer Übermittlung zusätzlicher Attributen beim Erstellen des Login Buttons
6. Hat er die Erlaubnis erteilt wird er wieder zum Onlinedienst zurückgeleitet und die Daten
werden übermittelt. Die Session wird dabei in einem Cookie gespeichert. Der Onlinedienst
erteilt dem Benutzer dann den Zugang zum Account. Mit Hilfe der App ID und dem App
Secret kann der Onlinedienst auf Daten über den gespeicherten Cookie zugreifen (Abbildung
133).
113
http://developers.facebook.com/docs/guides/web/#personalization
115
114
136
Abbildung 133 116: Beispiel eines Cookie (in fbs_YOUR_APP_ID gespeichert) Zugriffs in PHP
Mögliche Risikofaktoren [Pfefferle, 2010]:


Die Methode der Authentisierung basiert auf Passwörter und darum gelten die
entsprechende Sicherheitsrisiken R1-R5 (XSS, Phishing, schwache Passwörter, usw.) wie beim
Passwortverfahren. So könnte man die Benutzerdaten stehlen mit einer Man-in-the-Middle
Methode, die den Benutzer einloggt und nebenbei die Logindaten erfasst. Der Benutzer
würde es nicht merken, da er sich normal auf ein Account eingeloggt hat.
Um CSRF-Angriffe117 vorzubeugen empfiehlt Facebook sollte der Onlinedienst einen identifier
weitergeben und den bei einer Antwort überprüfen (im state Parameter, Abbildung 134).
116
Cross Site Request Forgery: Unautorisierte Anwendung wird auf einer vertrauenswürdigen Webseite (bereits
authentifiziert und autorisiert) ohne Wissen des Benutzers gestartet.
117
137
Abbildung 134 118: Beispiel für CSFR Schutz mit PHP nach Facebook



118
Sichere Aufbewahrung der OAuth Access Token: Der Access Token kann unendlich gültig sein,
darum muss sie sicher und verschlüsselt in einer Datenbank gespeichert sein, damit Angreifer
keinen Zugriff darauf haben können und somit Zugang zum Account haben. Darum sollten
die Access Token nur begrenzte Zeit gültig sein und eine unbegrenzte Gültigkeitsdauer nicht
erlauben. Das wird leider nicht von Facebook direkt unterstützt und ist vom Onlinedienst
abhängig.
Ein Hacker-Angriff auf den Social-Connect-Provider bedeutet auch den Zugriff auf alle
angeschlossenen Onlinediensten.
Allgemein können SSO Verfahren Phishing über Honey Pot Webseiten erleichtern: Ein
Betrüger könnte eine falsche Webseite einrichten und einen falschen FB Connect Button
einbauen, der dann die Nutzerdaten stiehlt. So sieht es für einen Benutzer aus, als würde er
sich auf Facebook über FB Connect einloggen, aber in Wahrheit werden die eingegeben
Daten an den Betrüger gesendet. Da im Fall von Facebook jede Webseite ein Facebook
138





Account haben muss, wenn er FB Connect und die Apps benutzt, kann man auf Facebook
nachschauen, ob die Webseite dort eingetragen ist.
Ein Social-Connect-Provider kann von einer unseriösen Firma übernommen werden oder das
Vertrauen Missbrauchen.
Eine Regierung kann sich einfacher Zugriff zu Netzwerkübergreifenden Profil-Informationen
erzwingen.
Der Social-Connect-Provider kann seinen Dienst einstellen.
Interesse von Benutzer kann sich mit dem Alter oder veränderten sozialen Umfeld ändern
(wie z.B. MySpace, wo die Community nicht ewig existiert und die Nutzer zum nächsten
Dienst abwandert). Der Benutzer ist daher entweder ewig an ein bestimmtes Soziales
Netzwerk gebunden, wenn er deren Anmeldedienst benutzt oder er muss alle daran
angeschlossenen Plattformen mit dem neuen Identity-Provider verbinden.
Datenschutzsicherheit ist auch ein Problem, dass man erwähnen muss. So werden eine
Vielzahl von Cookies verwendet um das Surfverhalten des Benutzers zu protokollieren
[Schmidt, 2011]. Laut Facebook [Lischka, 2011] wird ein datr Cookie angelegt, um damit die
Sicherheit zu erhöhen. So werden bei verdächtigen Benutzern (z.B. plötzliche eine IP aus
Saudi Arabien, anstatt sonst immer aus Deutschland) dann Sicherheitsmechanismen aktiviert,
wie z.B. das Social Captcha: Dem Benutzer werden drei Fotos gezeigt, mit denen er
befreundet ist. Er muss dann aus neun verschiedenen Namen seine drei Freunde auf den
Fotos wiedererkennen.
Auch wenn dies laut Facebook der Sicherheit dienen sollte, so sind solche gesammelte Daten,
die Interessen usw. von Benutzer beinhalten auch vom großen Interesse Dritter, wie
Werbung oder staatliche Kontrollen. Man kann nicht ausschließen, dass solche Daten in die
Hände von Dritten gelangen, wie durch Verkauf, Diebstahl oder richterliche Anordnungen.
Dies gilt auch für alle anderen sozialen Netzwerke, wie Google+ usw. Darum sollte man seine
Daten dezentral verwalten, d.h. ein Dienst für Bilder, eines für Chats, eines für E-Mails usw.
Damit man nicht das komplette Profil auf ein Anbieter konzentriert.
139
9.4.5
Microsoft Windows Live ID (ehemals .NET Passport)
Microsoft Windows Live ID ist der Nachfolger von .NET Passport. Das .NET Passport wurde 1999
eingeführt und wegen gravierenden Sicherheitslücken und Kritik an der zentralen Datenspeicherung
2006 mit Windows Live ID ersetzt [Schönberg, 2007]. Windows Live ID ist immer noch
abwärtskompatibel zu .NET Passport und unterstützt auch CardSpace. Es ist geplant, dass Windowns
Live ID vom SSO mit einem zentralisierten Identity Provider wegkommt und ein OpenID Framework
als OpenID Server [Windows Live ID, 2011] sowie einer Föderation [Microsoft Corporation, 2007]
ähnlich dem Liberty Alliance Project ist in Planung.
Ablauf:
Vom Protokollfluss hat sich gegenüber .NET Passport nichts geändert und es basiert auf das Kerberos
Protokoll mit seinem Ticketsystem. Das Problem dabei ist, dass der Browser in der Adaption für das
WWW anonym bleibt. Im Gegensatz von Kerberos, bei der die Authentifizierung zwischen Client und
Server durch einen gemeinsamen symmetrischen Schlüssel sichergestellt wurde [Borges, Schwenk,
Stuckenberg, & Wegener, 2011].
Abbildung 135: Protokollfluss einer Loginsession
1. Der Benutzer möchte sich über einen Webbrowser auf einem Onlinedienst einloggen.
2. Der Onlinedienst überprüft anhand eines Cookie ob er schon eingeloggt ist. Wenn nicht,
dann leitet er automatisch die Authentisierungsanfrage an den Windows Live ID Server
weiter oder es erscheint die Anmeldeseite des Windows Live ID Servers.
3. Der Windows Live ID Server überprüft, ob ein Cookie bereits vorhanden ist und der Benutzer
sich schon eingeloggt hat. Wenn nicht, dann fordert der Windows Live ID Server den
Benutzer auf, auf der Anmeldeseite sein Benutzernamen und Passwort einzugeben. Hat der
Benutzer seine Zugangsdaten eingegeben, dann werden sie vom Windows Live ID Server
überprüft und erstellt ein Ticket.
4. Der Windows Live ID Server sendet nun das Ticket an den Benutzer und speichert die
Information des Tickets im Browser in zwei Cookies (ein TGT und ein Ticket mit Zeitstempel
der letzten Anmeldung und Refresh) beim Browser ab. Der Windows Live ID Server speichert
bei sich noch alle besuchten Webseiten ab, damit sie beim Ausloggen des Benutzers
benachrichtigt werden. Der Browser leitet außerdem ein zweites Ticket, den der Windows
140
Live ID mit dem öffentlichen Schlüssel des Onlinedienstes verschlüsselt hat, direkt an den
Onlinedienst weiter, der die Authentisierungsanfrage geschickt hat.
5. Durch die Entschlüsselung des Tickets kann der Onlinedienst den Benutzer authentifizieren
und erlaubt dem Benutzer Zugang auf seine Dienste. Er speichert das erhaltene Ticket wieder
verschlüsselt auf den Browser ab um ihn später schneller erkennen zu können.
Mögliche Risikofaktoren:


9.4.6
Es gelten allgemein die gleichen Risikofaktoren wie beim FB Connect: So gelten auch die
Schwächen des Passwortverfahren und man muss Microsoft als zentralisierter
Identitätsprovider vertrauen können und darauf hoffen, dass er immer erreichbar ist und mit
den Daten sorgsam umgeht.
Große Sicherheitsprobleme mit .NET Passport führten zum Vertrauensverlust und
Unternehmen wie eBay unterstützen das System deshalb nicht. Es ist daher auch möglich,
dass durch Programmierfehler noch unbekannte Schwächen in Windows Live ID stecken, da
sie auch auf das alte System basiert.
Windows CardSpace (ehemals InfoCard)
Windows CardSpace (ehemals InfoCard) ist eine Technologie zur Identitätsverwaltung und kann als
Authentifzierung gegenüber Webseiten genutzt werden [Microsoft CardSpace, 2011]. Es ist
Bestandteil des .NET Frameworks verfolgt aber einen anderen Ansatz als das ehemalige .NET
Passport. Die Entwicklungsarbeiten von Windows CardSpace 2.0 im Februar 2011 wurden eingestellt
und Microsofts Produkte unterstützen SAML 2.0, OpenID 2.0, OAuth WRAP and OAuth 2.0 [Microsoft
Corporation, 2011]. Das System funktioniert ohne Benutzernamen und Passwort und verfolgt eine
dezentrale Strategie mit einem Client (z.B. der Benutzer), Identity Provider (IdP) und Relying Party
(RP, z.B. der Onlinedienst). Die Grundidee dabei ist, dass man sich wie im echten Leben mit
verschiedenen Dokumenten ausweisen kann, die man je nach Situation vorlegt. So legt man z.B. in
einer Videothek als Altersnachweis einen Führerschein vor und keine Kreditkarte, da die
Kreditkartennummer in dem Fall nicht angebracht ist und die Kreditkarte keinen Geburtsdatum hat.
Auch sollte man dem Fahrkartenkontrolleur die entsprechende Fahrkarte für das öffentliche
Verkehrsmittel vorlegen. Der Benutzer besitzt auf seinem PC zwei Arten von InfoCards, die
persönliche Karte und die ausgestellte Karte. Sie werden von der Software CardSpace verwaltet und
die persönliche Karte kann der Benutzer selber (durch einen eigenen Identitätsprovider von
CardSpace) erstellen (und damit Pseudonyme benutzen) und individuell dem Onlinedienst anpassen.
Verwaltete Karten werden als Datei dem Benutzer von einem Identitätsprovider zugeschickt werden
und muss dann von dem Kartenverwaltungsprogramm importiert werden. Die Authentifizierung
basiert daher nicht auf Benutzernamen und Passwort, sondern auf signierte Sicherheitstoken (z.B.
vom Identitätsprovider).
141
Ablauf [Chappel, 2006]:
Abbildung 136: Interaktion zwischen Benutzer, Identitätsprovider und Onlinedienst
1. Der Benutzer möchte sich auf eine Webseite vom Onlinedienst einloggen und wählt dabei
Windows CardSpace als Login aus. Damit fragt er nach den Voraussetzungen für den
Sicherheitstoken.
2. Der Onlinedienst schickt dem Browser die Richtlinien zu, die besagen, welches Format das
Sicherheitstoken (z.B. SAML Tokens, Kerberos Tickets, X.509 Zertifikate usw.) de s
Onlinedienstes akzeptiert und was das Token beinhalten muss. Diese Information wird vom
Browser an CardSpace weitergeleitet.
Abbildung 137 119: CardSpace Kartenauswahlschirm
3. Der Benutzer kann jetzt die InfoCard auswählen, die den Richtlinien des Onlinedienstes
entsprechen (Abbildung 137). Wählt der Benutzer die entsprechende InfoCard aus, dann
119
http://msdn.microsoft.com/en -us/library/Aa480189
142
verlangt CardSpace bei dem entsprechenden Identitätsprovider der InfoCard das
Sicherheitstoken.
4. Der Identitätsprovider schickt das angeforderte Sicherheitstoken an CardSpace.
Abbildung 138 120: Anzeige der übermittelnden Daten, die der Benutzer bestätigen muss.
5. Loggt sich der Benutzer das erste Mal auf die Webseite ein, dann muss er bestätigen, welche
Daten er versendet und kann nochmals überprüfen, ob er mit tatsächlich mit dem
Onlinedienst in Verbindung steht (Abbildung 138). Bestätigt der Benutzer es, dann wird der
Sicherheitstoken von CardSpace über den Browser an den Onlinedienst gesendet und der
Browser kann den Sicherheitstoken überprüfen und danach den Benutzer auf seine Webseite
den Zutritt erlauben.
Mögliche Sicherheitsrisiken:



9.4.7
Die Authentifizierung ist von der Software abhängig, die auf dem PC des Benutzers installiert
ist. Viren könnten da die Software manipulieren.
Die InfoCards können unterschiedliche Sicherheitsstufen voraussetzen und sind
dementsprechend je nach Sicherheitstoken anfällig auf Man-in-the-Middle oder Replay
Angriffe.
Windows CardSpace wird nicht mehr weiterentwickelt. Dadurch könnten eventuelle
Sicherheitslücken nicht geschlossen werden, falls man dafür neuere Versionen voraussetzt.
Mozilla BrowserID
BrowserID von Mozilla wurde am 14. Juli 2011 eingeführt und befindet sich noch in der
experimentellen Phase [Mills, 2011]. Es basiert auf den Verified Email Protokoll [Mozilla Wiki, 2011]
und soll die Sicherheit erhöhen und den Loginprozess für den Benutzer sowie für den Anbieter
vereinfachen. Für die Authentisierung wird nur eine verifizierte E-Mail Adresse benutzt und kein
Passwort. Eine Passworteingabe ist nur einmalig bei der Erstellung einer BrowserID bei einem
Identitätsprovider nötig. Zurzeit wird nur HTML und Javascript benötigt und es soll auch auf alten
Browsern, IE und Mobilgeräten funktionieren.
Die Hauptmerkmale sind [Hilaiel, 2011]:
120
http://msdn.microsoft.com/en -us/library/Aa480189
143




E-Mail als Identität: In BrowserID gibt es keine Benutzernamen, sondern E-Mail Adressen
werden stattdessen verwendet. Menschen können sich normalerweise über eine E-Mail
identifizieren und man braucht keine neue Infrastruktur um zuverlässig die Echtheit zu
überprüfen.
Dezentralisierung: Bei einer Benutzerauthentifizierung mit einer Webseite braucht man
keinen dritten Benutzer. Dies kann effizient sein und dem Schutz der Privatsphäre dienen.
Auch kann man jede beliebige E-Mail Adresse benutzen und jeder E-Mail Provider könnte
BrowserID unterstützen, indem es als primärer Identitätsprovider dient, d.h. für die Identität
des Benutzers garantieren kann.
Auf Besitz-basierte Authentifizierung: Der Browser verwaltet die Authentifizierungsdaten
welches ohne ein Passwort benutzt werden kann. Darum ist es mehr auf Besitz abhängig als
auf dem Faktor Wissen.
Schon heute nutzbar und für die Zukunft gewappnet: Durch HTML 5 Implementation oder
JavaScript kann es jetzt schon benutzt werden. Zusätzlich wird BrowserID entwickelt um für
den Einsatz verschiedener Browsertypen. Direkte Unterstützung von Browsern könnte die
Sicherheit und Benutzererfahrung erhöhen.
BrowserID benutzt asymmetrische Kryptographie121 und digitale Signaturen mit der man signierte
Assertions122 über die Identität des Benutzers erstellen kann und einen Identitätsprovider der für
einen Benutzer bürgt indem er das E-Mail Schlüsselpaar signiert. Außerdem benutzt BrowserID Cross
Document Messaging [Cross-document messaging, 2011] um zwischen Dokumenten
unterschiedlicher Domains zu kommunizieren. Damit ist eine Implementation von BrowserID sofort
möglich ohne bereits existierende Browser anzupassen.
Ablauf:
BrowserID ist dezentralisiert und es existiert ein gesundes Misstrauen während der Interaktion
zwischen den Parteien.
Folgende Parteien sind dabei involviert [Hilaiel, 2011]:



Primärer Identitätsprovider (Primary Identity Authorities): Ein Dienst, der eine
Benutzeridentität in Form einer E-Mail Adresse zur Verfügung stellt (z.B. Yahoo! mail oder
gmail). Es kann "BrowserID support" erstellen und direkt für die Benutzeridentität bürgen.
Falls ein E-Mailprovider BrowserID nicht unterstützt, kann man browserid.org benutzen123.
Relying Parties (RPs): Webseiten, die BrowserID für Authentifizierung benutzen.
Implementation Provider (IP): Webbrowser, der BrowserID unterstützt oder browserid.org
füllt diese Rolle aus indem es Webressourcen (Schlüsselverwaltung und Implementation der
benötigten Algorithmen) zur Verfügung stellt.
Bei der Interaktion zwischen den Parteien gibt es drei wichtige Abläufe, die ich nun näher vorstellen
möchte [Hilaiel, 2011]:


Erstellung einer Browser ID
Erstellung einer Identität Assertion
121
Kompatibel zu JSON Web Key (JWK)
Kompatibel zu JSON Web Token (JWT)
123
Als sogenannter sekundärer Identitätsprovider (Secondary Identity Authorities).
122
144

Verifikation der Assertion.
Erstellung eines BrowserID Accounts:
Abbildung 139: BrowserID Erstellung
1.
Der Benutzer möchte eine BrowserID über eine verifizierte E-Mail Adresse erstellen. Dafür
gibt er beim Identitätsprovider seine E-Mail Adresse und ein Passwort an. Dies kann bei
manchen primären Identitätsprovidern schon genügen.
Abbildung 140: Erstellung eines BrowserID Kontos
2. In unserem Beispiel genügt nicht nur die Eingabe von E-Mail Adresse und Passwort. Über
Webfinger lookup sollte der Identitätsprovider auch überprüfen, dass die Domain der E-Mail
Adresse gültig ist. Auch sendet der Identitätsprovider eine E-Mail an den Benutzer mit einem
Link, die durch das Anklicken den Prozess bestätigen und abschließen kann. Damit möchte
man sicher gehen, dass der Benutzer die E-Mail Adresse eingegeben hat. Dieser Prozess ist
für sekundäre Identitätsprovider empfehlenswert, wenn primäre Identitätsprovider
145
(normalerweise die E-Mail Provider) BrowserID nicht unterstützen. Dann wird die
Generierung der Schlüssel usw. über einen sekundären Identitätsprovider weitergeleitet.
Abbildung 141 124: Bestätigungsnachricht
3. Bestätigt der Benutzer die E-Mail Adresse, dann wird vom Identitätsprovider der
Befehl gestartet, damit die im Browser implementierte Funktion einen privaten und
öffentlichen Schlüssel generiert. Der private Schlüssel wird im Cache für die Session
gespeichert.
4. Über eine gesicherte SSL Verbindung schickt der Browser den öffentlichen Schlüssel an den
Identitätsprovider.
5. Der Identitätsprovider speichert nun den öffentlichen Schlüssel in seine Datenbank und kann
sie auf einen öffentlichen Server hochladen, damit Onlinedienste diesen runterladen können.
Eine bessere Methode wäre es, wenn der Identitätsprovider ein signiertes Objekt125 den
Onlinediensten zur Verfügung zu stellen. Dabei signiert der Identitätsprovider mit seinem
privaten Schlüssel ein Objekt, die die E-Mail Adresse des Benutzers, den öffentlichen
Schlüssel vom Benutzer, die Gültigkeitsdauer und sonstige optionale Daten enthält.
6. Hat der Identitätsprovider ein signiertes Objekt erstellt, dann schickt er das zurück an den
Benutzer.
7. Der Benutzer speichert das Zertifikat und den privaten Schlüssel im Cache in seinem lokalen
Speicher vom Browser sicher ab. Der Browser könnte das signierte Objekt dem Onlinedienst
zuschicken, der dann den öffentlichen Schlüssel nicht mehr runterladen muss. Der
Onlinedienst könnte das Zertifikat stattdessen akzeptieren und benutzen.
124
http://www.ex tremetech.com/internet/90070-browserid-for-firefox-ie-and-chrome-does-away-withusernames-and-passwords
125
JSON Web Token: Ein JSON Objekt, dass signiert wurde mit JSON W eb Signature
146
Erstellung einer Assertion:
Abbildung 142: Erstellung einer Identität Assertion
1. Möchte sich der Benutzer nun mit der BrowserID anmelden, dann klickt er auf dem
Webbrowser auf das Sign in Symbol. Das Symbol könnte im Browser eingebaut sein oder
auch als normaler Link auf der Webseite auftauchen.
Abbildung 143: Sign in Symbol bei eingebauter BrowserID Funktion 126
2. Danach kann der Benutzer zwischen verschiedenen E-Mail Adressen wählen. Der Browser
holt dann von der ausgewählten E-Mail Adresse den geheimen Schlüssel und erstellt dann
eine Identität Assertion. Die Identität Assertion besteht aus zwei Teilen: Der erste Teil wird
mit dem geheimen Schlüssel der E-Mail Adresse signiert und der zweite Teil besteht aus dem
Zertifikat vom Identitätsprovider. Der erste Teil beinhaltet dabei die E-Mail Adresse vom
Benutzer, die Audience (die Adresse vom Onlinedienst und gegebenenfalls Port), eine
Gültigkeitsdauer (als Nonce) und den sekundären Identitätsprovider, falls der E-Mailprovider
BrowserID nicht unterstützen sollte.
126
http://www.ghacks.net/2011/08/13/browser-sign-in-firefox-add-on/
147
Abbildung 144 127: Auswahl der E-Mail Adresse bei der Anmeldung
Abbildung 145 128: Beispiel einer Identität Assertion in JSON Struktur
Assertion Verifizierung:
Abbildung 146: Benutzer wird authentifiziert über Assertion
127
http://www.eggheadcafe.com/tutorials/aspnet/7784b8c5-51ed-4aa9-b837-ed4084924ee8/implementingbrowserid-signin-with-aspnet.aspx
128
https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol#Certification
148
1. Der Onlinedienst erhält die Assertion vom Browser. In unserem Beispiel enthält sie die
Identität und das Zertifikat.
2. Der Onlinedienst überprüft die Assertion und das Zertifikat, ob sie noch gültig ist (z.B. ob eine
Nonce schon verwendet wurde bzw. die Gültigkeitsdauer nicht abgelaufen ist). Dann
entnimmt er von der E-Mail Adresse den Identitätsprovider. Falls es keinen primären
Identitätsprovider gibt, dann entnimmt er den vom angegebenen sekundären
Identitätsprovider.
3. Der Onlinedienst lädt sich dann den öffentlichen Schlüssel vom Identitätsprovider herunter.
Falls kein Zertifikat mitgeschickt wurde, dann lädt er den öffentlichen Schlüssel vom Benutzer
herunter.
4. Hat der Onlinedienst den öffentlichen Schlüssel vom Identitätsprovider runtergeladen, dann
entschlüsselt er das Zertifikat und entnimmt den darin enthaltenen öffentlichen Schlüssel,
um die Identität Assertion dann damit zu überprüfen. Ansonsten überprüft er die Identität
Assertion mit dem öffentlichen Schlüssel des Benutzers. Ist die Verifikation der signierten
Assertion gültig, dann weiß der Onlinedienst, dass der Benutzer diese spezifische E-Mail
Adresse gehört.
Da das Verfahren noch in einer experimentellen Phase ist, kann man Schwachstellen noch finden und
könnten in der endgültigen Version geschlossen werden129 . Allgemein sollte das Verfahren sicher
gegen R1-R5 sein, da der Schlüssel nach Public Key verschlüsselt ist und nicht so einfach
weitergegeben werden kann. Phishing und Keylogger sind wirkungslos. Aber man sollte trotzdem
einige Dinge beachten:









129
Es sollte sichergestellt sein, dass der private Schlüssel sicher gespeichert ist und eventuelle
Risiken von Sicherheitslücken im Browser könnten dem Hacker Zugang zum privaten
Schlüssel ermöglichen.
Es sollte sichergestellt sein, dass Man-in-the Middle Angriffe erschwert werden. Es wäre
möglich, dass ein Hacker eine falsche Loginseite dem Benutzer unterjubelt.
Anmeldung ist nur von einem PC aus möglich. Er kann nur von dem Browser aus sich
anmelden, wo die privaten Schlüssel gespeichert sind. Dritte, die Zugang zum PC erlangen
könnten, hätten die Möglichkeit sich anstatt den Benutzer auf Dienste einzuloggen. Möchte
man von verschiedenen Geräten BrowserID benutzen, dann müsste er auf jedem Gerät sich
neu registrieren oder man müsste dann den privaten Schlüssel sicher miteinander
synchronisieren können.
Identitätsprovider sollten Vertrauenswürdig sein, sowie primäre Identitätsprovider (z.B. EMail Anbieter) oder sekundäre Identitätsprovider wie Anbietern von Zertifikaten.
Datenübermittlung sollte verschlüsselt sein um Manipulationen usw. vorzubeugen.
UAs könnten den Schlüssel erneut benutzen um ein neues Zertifikat zu erhalten.
Timing Attacks
JavaScript Implementierung: Angriffsziel der Hacker für zufällige Angriffe um schwache
Implementierungen auszunutzen.
Zwischen Onlinedienst und Identitätsprovider muss ein gegenseitiges Vertrauen bestehen.
Problem könnte dabei sein, wenn jede Domain es möglich ist eine Adresse zu ve rifizieren.
Bisheriger Stand August/September 2011
149

Noch offene Implementationen:
o Wenige primäre Identitätsprovider vorhanden. Auch nur ein sekundärer
Identitätsprovider: browserid.org
o Noch keine Zertifikate vorhanden, alle Public Keys müssen offen bereitgestellt sein.
o Die Gültigkeitsdauer der Zertifikate und Schlüssel und Erneuerung ist noch nicht
richtig implementiert und offen.
o Anstatt alle öffentlichen Schlüssel des Benutzers runterzuladen, könnte man
sogenannte Key Identifier benutzen mit denen man nur den bestimmten öffentlichen
Schlüssel herausfinden kann. Der Key Identifier müsste dann in der Public Key
Registration, Identität Assertion und Zertifikat enthalten sein, damit der Onlinedienst
(Relying Party) dann nur den öffentlichen Schlüssel anfragt, die er möchte.
9.5 Unterschiede und Gemeinsamkeiten von SSO Verfahren
SSO Verfahren waren für Firmen sehr nützlich und konnten im geschlossenen Netzwerk umgesetzt
werden. Es waren meist individuelle Insellösungen und nicht kompatibel mit anderen Systemen
außerhalb des Netzwerks. Für das Internet werden SSO Verfahren interessanter, da es immer mehr
Online Accounts gibt und man sich so viele Accountnamen und Passwörter merken muss. Was alle
SSO Verfahren für Online Accounts gemeinsam haben: Es sind immer drei Parteien bei der
Authentisierung beteiligt. So muss unter den Parteien auch immer ein Vertrauensverhältnis
herrschen. Der Unterschied zwischen den Verfahren sind die unterschiedlichen Ideen wie ein
Identitätsprovider aufgebaut ist, zentral (z.B. Facebook) oder dezentral (z.B. Liberty Aliance) bzw.
über Zertifikate und daraus entstehende PKI (nPA). Was die verschiedenen verwendeten Protokolle
angeht, so versuchen alle eine standardisierte Schnittstelle bereitzustellen, über die sich die drei
unterschiedlichen Parteien (Benutzer, Onlinedienst und Identitätsprovider) kommunizieren können.
Dabei soll idealerweise das Passwort vom Benutzer nicht vom Identitätsprovider an den Onlinedienst
übermittelt werden. Der Unterschied zwischen den Protokollen ist, dass manche noch mehr können,
um weitere Ansprüche zu genügen, wie z.B. Rechte130 entsprechend zu verteilen.
9.6 Fazit SSO
SSO Verfahren bringen Unternehmen einen Zeitvorteil, da man viel Zeit verbraucht, um sich auf alle
Systeme einzuloggen. Aber bisher scheint sich noch kein SSO Verfahren für das Internet durchgesetzt
zu haben. Ein Grund könnte sein, dass sich noch kein technischer Standard durchgesetzt hat. Wie wir
gesehen haben, braucht man auch einen Identitätsserver für SSO Verfahren. So kann ein anderer
Grund sein, dass der Benutzer Zweifel gegenüber dem Datenschutz und Sicherheit hat. Das Vertrauen
scheint noch nicht groß genug zu sein, worauf die Verfahren im Prinzip aufbauen. Der nPA kann eine
sichere SSO anbieten, da sie als einzige bisher die Zwei-Faktor-Authentifizierung unterstützt. Sie wird
von der Industrie jedoch noch nicht groß unterstützt und ist in Deutschland auch nicht weit
verbreitet. Facebook hat dagegen mit 800 Mio. Nutzer [Facebook, 2011] zurzeit einen interessanten
Ausgangspunkt geschaffen und es bleibt abzuwarten, ob sich mit seinem FB Connect damit SSO
Verfahren durchsetzen können. In Abbildung 147 benutzen alle SSO Verfahren, außer dem nPA,
Mozilla BrowserID und Windows Cardspace, Passwörter zur Authentisierung. nPA benutzt PIN und
den Personalausweis und Mozilla BrowserID und Windows CardSpace entsprechend eine im Browser
bzw. im PC gespeicherte Private Key bzw. InfoCard, die ich hier als Besitz kategorisiere, da man sich
nur auf dem PC einloggen kann, der die entsprechenden Daten gespeichert hat.
130
Z.B. Zugriffsrechte auf Informationen oder Bilder.
150
Abbildung 147: Beziehungen zwischen SSO Verfahren.
Eine zusätzliche Gefahr kann von der Verkettung der Identitäten ausgehen, die man auch bei SSO
Verfahren einsetzt. So versucht man im Zuge der Kompatibilität möglichst viele Protokolle und
Verfahren zu unterstützen. Jedoch beruht dann jede zusätzliche Einbindung auch auf Vertrauen und
in der Identitätskette könnten Sicherheitslücken entstehen.
Ein Onlinedienst würde sich z.B. für ein SSO Verfahren mit einem Identitätsprovider entscheiden, der
möglichst viele Benutzer einbinden kann. Damit er noch eine größere Zielgruppe erreicht, akzeptiert
der Identitätsprovider andere Identitätsprovider. Aber am Ende könnte der Onlinedienst die
Verkettung von den Identitäten vielleicht gar nicht mehr lückenlos zurückverfolgen und zusätzlich die
Grundidee einer einfachen Authentifizierung mit nur einer Identität nichtig machen, wenn man am
Ende wieder verschiedene Identitäten besitzt.
10 Authentisierungsverfahren im Vergleich
In diesem Kapitel möchte ich die vorgestellten Authentisierungsverfahren nach deren Sicherheit und
Benutzerfreundlichkeit in einem Diagramm und einer Tabelle vergleichen. Damit kann man sich einen
Überblick auf bisher verfügbare Verfahren schaffen. Einige theoretische Verfahren, die nicht
umgesetzt sind, werde ich erwähnen aber nicht auflisten, da es dafür keine ausreichend praktische
Vergleichsmöglichkeit gibt. Durch die Analyse der einzelnen Verfahren konnte ich sie auch in Klassen
einteilen, die bei der Übersicht der Verfahren helfen. So kann ich Verfahren in Klassen
zusammenfassen und sie entsprechend vergleichen.
10.1 Sicherheit und Benutzerfreundlichkeit
Hier möchte ich die Authentisierungsverfahren anhand der Benutzerfreundlichkeit und Sicherheit
überprüfen. Dabei möchte ich der Behauptung nachgehen, dass hohe Sicherheit nicht mit hoher
Benutzerfreundlichkeit zusammenpasst. Vergleichen werde ich die Verfahren am Passwortverfahren,
151
da es das Standardverfahren für Accountsicherung ist. Dabei fasse ich die Authentisierungsverfahren
anhand der Klassen zusammen und ordne sie entsprechend ein. Die Sicherheit gegenüber Trojaner
(R2) und Phishing (R3) wird hier verglichen. Die Sicherheit des Schlüssels (R1), gegen Man-in-theMiddle Angriffen (R4) und der Speicherorte (R5) werde ich vernachlässigen, da im Prinzip kein
Verfahren dagegen hundertprozentig sicher ist. Sie unterscheiden sich nur nach dem
Schwierigkeitsgrad diese Angriffe durchzuführen und werden meisten von Angreifern nur benutzt,
wenn es keine Alternativen gibt. Populärer sind die "einfachen" Angriffe über Trojaner oder Phishing.
Was die Benutzerfreundlichkeit angeht, so werden die Verfahren danach bewertet, wie einfach die
Authentisierung abläuft und ob sie leicht erhältlich ist. Auch die Mobilität sollte für die
Benutzerfreundlichkeit eine Rolle spielen. Sollten also Benutzer das Verfahren nicht benutzen
können, da sie eine Anforderung nicht besteht, dann können Verfahren schlechter in der
Benutzerfreundlichkeit gesetzt sein, obwohl der Authentisierungsablauf an sich recht simpel wäre.
Zuerst vergleiche ich die Authentisierungsverfahren nach den einzelnen Klassen. Dabei werde ich die
Klassifizierung von Kapitel 8 benutzen:



Die Oberklassen: No-Tech, Low-Tech und High-Tech.
Die Hauptklassen: Wissen und Besitz.
Die Unterklassen: Zwei-Wege-Kommunikation und Zwei-Faktor-Authentifizierung.
Zu den No-Tech Verfahren gehören alle Ein-Faktor Authentisierungsverfahren, die auf Wissen
basieren.
Die Tabellen 6-8 geben einen Überblick auf die Qualität der Angriffe, die auf die
Authentisierungsverfahren nach den Oberklassen getrennt möglich sind. Wir setzen aber voraus,
dass die Onlinedienste so gut abgesichert sind, sodass eine globale Deduktion nicht möglich ist.
Angriffsarten
Phishing
Trojaner
Man-in-the-Middle
Brute-Force
X
X
X
X
Lokale Deduktion
Tabelle 6: Angriffsqualität für No-Tech Verfahren
Phishing und Brute-Force wäre zwar für High-Tech Verfahren möglich, aber sie sollten nutzlos sein,
da der Schlüssel nicht mehr gültig ist.
Angriffsarten
Phishing
Trojaner
Man-in-the-Middle
Brute-Force
X
Lokale Deduktion
X
X
X
Tabelle 7: Angriffsqualität für Low-Tech Verfahren
Angriffsarten
Phishing
Trojaner
Man-in-the-Middle
Brute-Force
Lokale Deduktion
X
X
X
X
Tabelle 8: Angriffsqualität für High-Tech Verfahren
152
Abbildung 148: No-Tech Verfahren
In den Abbildungen 148 - 151 ist ein Verfahren benutzerfreundlicher, je weiter oben es steht. Und je
weiter rechts ein Verfahren steht, desto sicherer ist es. So ist in Abbildung 148 die Sicherheitsfrage
höher in der Benutzerfreundlichkeit als ein Passwort/PIN und die Zwei -Schritte Abfrage, da man sich
eine Antwort auf die Sicherheitsfrage besser merken kann und sie nur einmal eingeben muss. Die
Sicherheitsfrage ist aber gleichzeitig niedriger in der Sicherheit im Vergleich zum Passwort und Zwei Schritte-Abfrage, da man die Antwort leichter herausfinden kann. Persönliche Antworten zu
Sicherheitsfragen könnten z.B. leicht in Soziale Netzwerke gefunden werden. Passwörter, PIN und
iPIN können in einer Gruppe zusammengefasst werden, da zwischen ihnen die Sicherheit und
Benutzerfreundlichkeit nicht groß unterscheiden. Einige SSO-Verfahren gehören auch dazu, da sie
Passwortverfahren einsetzen. Die nächst höherer Sicherheit im Vergleich zum Passwortverfahren
bieten die Low-Tech Verfahren auf Abbildung 149. Dabei werden nur einfache Hilfsmittel wie
Papierlisten benutzt. Einen großen Unterschied zwischen Benutzerfreundlichkeit und Sicherheit
besteht zwischen den Verfahren, die direkte oder indirekte Eingabe benutzen.
Abbildung 149: Low-Tech Verfahren
Das TAN-Verfahren steht dabei stellvertretend für die Einmal-PIN Liste und indizierte Einmal-PIN Liste
Verfahren. Sie haben alle eine ähnliche Benutzerfreundlichkeit und Sicherheit. Eine viel höhere
Sicherheit bieten dagegen die Verfahren an, in der man das Passwort indirekt eingibt. In Vertretung
zu den verschiedenen Möglichkeiten einer indirekten Eingabe steht das iiPIN-Verfahren (indirekte
indizierte Einmal-PIN Liste). Dafür leidet aber die Benutzerfreundlichkeit, da die Eingabe
komplizierter und länger dauern kann. In unserem Beispiel in Abbildung 149 schaue ich nur die EinFaktor Versionen an. Sollte man symbiotische Zwei-Faktor Authentisierungen anwenden, dann
erhöht sich die Sicherheit, die zwischen Google Sesame und RSA SecurID Token herankommen kann
(Abbildung 152). Die Benutzerfreundlichkeit ist bei Low-Tech Verfahren niedriger als No-Tech
153
Verfahren, da man eine Liste benötigt und sie bei sich tragen muss, wenn man sich damit überall
einloggen möchte. Auch ist die Anzahl der Logins von der Liste abhängig, je nachdem wie lang sie ist.
Abbildung 150: High-Tech Verfahren
High-Tech Verfahren (Abbildung 150 und 151) sind von der Sicherheit generell höher als Low-Tech
Verfahren und können auch benutzerfreundlicher sein. Die Benutzerfreundlichkeit ist nicht so hoch
wie bei No-Tech Verfahren, da man etwas besitzen muss und nicht jeder den Besitz (bzw. den
Schlüssel) sofort erhalten, sich leisten (Schlüsselgenerator/Zubehör muss man normalerweise selber
bezahlen) oder damit mobil sein kann. Dabei ist aber die Benutzerfreundlichkeit höher als bei den
Low-Tech Verfahren, da man unendlich viele Schlüssel generieren kann. Unter den High-Tech
Verfahren sind Authenticactor Apps für Smartphones benutzerfreundlicher als die klassischen
Authenticator Tokens, da man kein zusätzliches Gerät benötigt und somit keine zusätzlichen Kosten
anfallen. Auch wenn nur Benutzer von den unterstützenden Handys davon profitieren, wiegt das
doch hier etwas höher. Von der Sicherheit her dürfte sich da nichts groß ändern. Wenn man
zwischen Low-Tech und High-Tech die Benutzerfreundlichkeit vergleicht, dann liegt die Einfachheit
der Benutzung, unendliche Schlüsselgenerierung und eventuell leichterer Zugang (z.B. von einem App
Market kostenlos runterladen) höher als die hohe Verbreitungsmöglichkeit (Papierlisten kann über
Postweg jeder besitzen) und Kosten. Noch sicherer als High-Tech Ein-Faktor Verfahren sind die ZweiFaktor Verfahren (Abbildung 151). Sie sind aber generell auch etwas benutzerunfreundlicher, das
man länger braucht um sich zu authentisieren. Auch benötigen manche Verfahren wie etwa der nPA
neben dem Ausweis noch Lesegeräte usw. Das macht sie unflexibel und teuerer. Das theoretische
Sichere Fenster Verfahren habe ich hier als sicherstes Verfahren eingeordnet, auch wenn es als EinFaktor Verfahren verwendbar ist, aber es ist auch am benutzerunfreundlichsten, da eine
Authentisiserung nur von einem PC aus möglich ist und man spezielle Lesegeräte und Anschlüsse
braucht. Im Gegensatz zum nPA, bei der man ein beliebiges NFC-fähiges Lesegerät benutzen könnte.
Abbildung 151: Zwei-Faktor Verfahren
154
In Abbildung 152 sind alle Authentisierungsverfahren zusammengefasst und man kann erkennen,
dass No-Tech Verfahren am unsichersten sind, gefolgt von Low-Tech Verfahren. Wobei die
Benutzerfreundlichkeit zwischen No-Tech und Low-Tech Verfahren abnimmt.
Abbildung 152: Vergleich nach Sicherheit und Benutzerfreundlichkeit
In Abbildung 153 habe ich die Verfahren als ein Diagramm angeordnet, die die Argumente von
Abbildung 148-151 verfeinert wiederspiegeln. Das Referenzmodell, mit der die Verfahren verglichen
werden, ist das Passwortverfahren, da es das am meisten benutzte Verfahren für Online Account ist.
Die Benutzerfreundlichkeit vom Passwortverfahren wird hier mit 10 (hohe Benutzerfreundlichkeit)
und die Sicherheit mit 1 (hält die Mindestsicherheitsanforderung einer Authentisierung einer
Identität) bewertet. Die Sicherheit und Benutzerfreundlichkeit einzelner Verfahren können sich
überschneiden und innerhalb der eingeteilten Gruppen in einer Toleranzgrenze mehr oder weniger
abweichen. Darum sind einige Punkte kleiner dargestellt als andere (kleine Punkte: weniger Toleranz
in einer Gruppe). An sich sind die Verfahren aber ähnlich sicher und hängen hauptsächlich davon ab,
in welcher Klasse sie sich befinden, wie die schwarz eingekreisten Verfahren andeuten (No-Tech,
Low-Tech, High-Tech und Zwei-Faktor).
155
Abbildung 153: Verfahren in Abhängigkeit von Sicherheit und Benutzerfreundlichkeit.
Allgemein kann man sehen, dass die Benutzerfreundlichkeit abnimmt, je sicherer ein Verfahren wird.
Eine stetige Verminderung der Benutzerfreundlichkeit mit höherer Sicherheit lässt sich hier aber
nicht ausmachen. Kompensieren kann man dies nämlich durch verbesserte Technik, doch nimmt die
Benutzerfreundlichkeit trotzdem leicht ab, da Techniken für sichere Authentisierungen nicht für
jeden verfügbar ist. Das Passwortverfahren ist nach wie vor am unsichersten, aber auch um
benutzerfreundlichsten. Dies kann sich aber in der Zukunft ändern, da es die Möglichkeit gibt, dass
bestimmte technische Voraussetzungen sich weit verbreiten und somit die
Verbreitungsmöglichkeiten sicherer High-Tech Verfahren einfacher und größer werden, wie z.B.
durch große Verbreitung von Smartphones und Handykameras. Bisher ist aber leider noch der Fall,
dass es kein Verfahren gibt, dass eine hohe Benutzerfreundlichkeit wie ein No-Tech Verfahren
anbietet und eine hohe Sicherheit hat wie ein High-Tech Verfahren.
156
10.2 Authentisierungsverfahren auf einem Blick
In Tabelle 9 gebe ich einen Überblick von verschiedenen Authentisierungsverfahren. Dabei vergleiche
ich die verschiedenen Authentisierungsverfahren nach Methode, Anzahl der Beteiligten, Angriffe und
Sonstiges. Die Methode wird nach Besitz und Wissen unterschieden. Bei der Anzahl der Beteiligten
unterscheide ich, wer alles bei einer Authentifizierung involviert ist. Bei zwei Parteien sind nur der
Benutzer und der Onlinedienst und bei drei Parteien zusätzlich noch der Identitätsprovider beteiligt.
Im Hinblick auf die Sicherheit vergleiche ich sie, wie sicher sie gegen Trojaner, Phishing und Man-inthe-Middle Angriffe sind. Die ersten beiden Angriffe, da sie am häufigsten in Erscheinung treten und
die letzte, da diese am schwersten zu verhindern ist. Unter Sonstiges vergleiche ich die Verfahren
noch nach Benutzerfreundlichkeit und der einfachen Möglichkeit einer Accountwiederherstellung
falls der Schlüssel verloren gehen sollte.
Sehr gut geschützte Accounts sind solche Verfahren, bei denen es entweder nicht möglich ist mit
einem der Angriffsmethoden den Schlüssel herauszufinden. Auch fallen solche Verfahren darunter,
bei denen man zwar den Schlüssel herausbekommen kann, sie aber nicht nützt, da noch was anderes
für eine Authentisierung fehlt. Ausreichend gut geschützte Accounts sind solche Verfahren, bei
denen der Angreifer einen sehr großen Aufwand benötigen würde und es sich für ihn daher kaum
lohnt einen solchen Angriff zu starten bzw. der Schlüssel nur einmal gültig wäre oder bereits ungültig
ist. Schlecht geschützte Accounts sind die Verfahren, bei denen der Angreifer keine Mühe hat sich
Zugang zum Schlüssel zu verschaffen und sie benutzen kann. Bei der Account Recovery kommt es
darauf an, wie schnell man einen Ersatzschlüssel erhält, falls der Benutzer seinen
Authentisierungsschlüssel verlieren sollte. Kann er sich sofort wieder einloggen, muss er länger
darauf warten bzw. den Schloss komplett auswechseln. D.h. er kann sich trotz neuem Schlüssel nicht
auf sein Account einloggen, sondern der Account muss erst von einem Administrator neu angepasst
werden. Wie in Tabelle 9 zu erkennen ist, unterscheiden sich die Verfahren bei der Authentisierung
hauptsächlich zwischen Wissen und Besitz. Die Unterschiede innerhalb der einzelnen Methoden
dienen meistens, um stärker bestimmte Angriffsarten wie Trojaner, Man-in-the-Middle oder Phishing
zu verhindern. Dabei werden nur gezielt einzelne Angriffe bekämpft und bieten keinen sehr guten
Schutz gegen alle Angriffsarten.
Für einen bestimmten Angriff gibt es zurzeit leider keine Abwehr: Wenn ein Live Angriffe auf die
Session des Benutzers gelingen sollte. Hat der Angreifer erfolgreich die aktuelle Session stehlen
können, dann kann er ohne Probleme sich im Account umschauen solange die Session aktiv ist und
der Benutzer sich nicht ausloggt. Tabelle 9 zeigt auch, dass es noch kein Verfahren gibt, die gegen alle
Angriffsarten gleichzeitig sicher und zusätzlich auch Benutzerfreundlich sind. Doch es gibt Verfahren,
die so schwer zu knacken sind, dass sie für Hacker zu aufwändig und zu teuer sind und somit für sie
nicht lohnen würde einen Angriff zu starten. Damit wäre ein Account ausreichend gut geschützt.
157
Beteiligten
Anzahl
Methode
Authentisierungsverfahren
für Online Accounts
2-step verification (a)
Bildpasswort-PIN
Cardano-PIN
Cronto (a)
Einmal-PIN Liste
eKaay (a)
eKaay PIN (a)
eTAN-Plus
Facebook Connect
Google Sesame (a)
HBCI-1
HBCI-2
HBCI-3
indirekt indiziertes BildEinmal-PIN Liste
indirekte indizierte EinmalPIN Liste
indizierte Einmal-PIN Liste
indizierte Einmal-PIN Liste
mit CAPTCHA
Internetpassport
iPIN
Liberty Alliance Project
Linien-PIN
Microsoft Windows Live ID
Mozilla BrowserID
mTAN/smsTAN (a)
NFC-Foto-TAN (a)
nPA (Lesegerät Klasse 1)
Passwort
Permutations-PIN
PIN
RSA SecurID Token
Schlüsselkarte
Shibboleth
SMS PASSCODE (a)
Sichere Fenster
Sicherheitsfrage
sm@rt optic /chipTAN
comfort
sm@rt-TAN
sm@rtTAN-Plus/chip TAN
manuell
USB-Stick mit Browser
USB-Token
Visuelle-PIN
Windows CardSpace
ZTIC
Zwei-Schritte Abfrage
Phishing
Man-intheMiddle
Benutzerfreundlich
Account
Recovery
x
x
x
x
⊕
⊕⊕
⊕⊕
⊕
⊕
⊕
⊕
⊕⊕
⊝
⊕
⊕
⊕
⊕
⊕
⊕
⊕
⊕⊕
⊕
⊕⊕
⊕
⊕⊕
⊝
⊝
⊕
⊕
⊕
⊕
⊝
⊝
⊕
⊝
⊕
⊕
⊕
⊝
⊕
⊕
⊕
⊕⊕
⊕
⊝
⊝
⊕
⊕
⊕
⊕
⊝
⊕⊕
⊕
⊕
⊕
⊕
⊕
⊕
⊕
⊕
⊕
⊝
⊝
⊕
⊕⊕
⊕⊕
⊕
⊕
⊕
x
x
⊕⊕
⊕
⊝
⊝
⊕
x
x
⊕⊕
⊕
⊝
⊝
⊕
x
x
⊕⊕
⊕
⊝
⊝
⊕
x
⊕⊕
⊕
⊕
⊝
⊕
x
x
⊕⊕
⊝
⊝
⊕
⊝
⊕⊕
⊕⊕
⊕⊕
⊕
⊕
⊕
⊝
⊕
⊝
⊕⊕
⊕⊕
⊝
⊕⊕
⊕⊕
⊝
⊕
⊝
⊝
⊝
⊝
⊕
⊕
⊕
⊕
⊕
⊕⊕
⊝
⊝
⊝
⊕
⊕
⊝
⊕
⊕
⊝
⊝
⊕⊕
⊕⊕
⊝
⊕⊕
⊕⊕
⊕
⊝
⊕
⊕
⊕
⊕⊕
⊝
⊕⊕
⊕
⊕
⊕⊕
⊕
⊕
⊕⊕
⊝
⊕⊕
⊕⊕
⊕
⊕⊕
⊝
⊕
⊕
⊕
⊕
⊕
⊕⊕
⊕
⊕⊕
⊝
⊝
⊝
⊕
⊕
⊕⊕
Besitz
Sein
2
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
3
x
x
x
x
x
x
x
x
x
⊕⊕
⊕
⊝
⊕⊕
⊝
⊕
⊕
⊕
⊕
⊕
⊕
⊝
⊕⊕
⊝
⊕
⊕⊕
⊝
⊕
⊕⊕
⊝
x
x
⊕⊕
⊕⊕
⊕
⊕
⊕
x
x
⊕
⊕
⊕
⊕
⊕
(x)
x
x
⊕
⊕⊕
⊕⊕
⊕
⊕
(x)
x
x
x
x
x
x
x
x
⊕
⊕
⊕⊕
⊕
⊕
⊝
⊕⊕
⊕⊕
⊕
⊕⊕
⊕⊕
⊝
⊕
⊕
⊕
⊕
⊕⊕
⊝
⊕
⊕
⊕
⊕
⊕
⊕⊕
⊕
⊕
⊕
⊕
⊕
⊕⊕
⊕
Schlecht, da ein
Angriff einfach ist
Mit Aufwand zu
bedienen
Muss komplett
neu ersetzt
werden
⊝
(x)
x
x
x
x
(x)
x
x
x
x
x
x
x
x
(x)
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
(x)
x
x
x
x
Erklärung
Ausreichend geschützt, da Angriff
möglich, aber aufwändig
Einfach zu bedienen, aber nicht für
jeden verfügbar
Sehr gut
geschützt
Einfach und für
jeden verfügbar
⊕⊕
Account Recovery
Einfach ohne
lange Wartezeit
⊕⊕
(x)
Beteiligten Anzahl
(a)
Optional
2
Benutzer, Onlinedienst
Viren auf Smartphones, Handys möglich.
Sicherheit
Benutzerfreundlichkeit
Sonstiges
Trojan er
Wissen
(x)
X
(x)
x
x
x
x
x
Sicherheit
⊕⊕
⊕
Ersatz möglich mit Wartezeit
3
⊕
⊝
⊝
Benutzer, Onlinedienst, Identitätsdienst
Tabelle 9: Vergleich von Authentisierungsverfahren
158
11 Schlusswort
Weltweit wird das Passwortverfahren immer noch überwiegend für Authentifizierungen von der
Bevölkerung akzeptiert. Es ist nach wie vor die einfachste und augenscheinlich günstigste Lösung.
Damit eine Authentisierung mit Passwörter sicher ist, muss man aber einiges im Kauf nehmen:
Passwörter müssen mindestens 12 Stellen und eine Mischung aus Alphanumerischen Zeichen
besitzen. Auch muss man sie regelmäßig ändern, täglich seinen Computer vor Malware mit einer
Firewall und Antivirenprogrammen überprüfen und schützen und vor Phishingversuche in Acht
nehmen. Es kann daher recht schwer sein, sich für alle Online Accounts Passwörter wie
Wekl2tM0!z@q zu merken oder täglich lange und komplizierte Passwörter einzugeben. Wie in der
Arbeit aufgezeigt wurde, gibt es bereits einige Alternativen. Einmalpasswortgeneratoren wie RSA
SecurID Tokens und SMS Benachrichtigungen werden eingesetzt, sind aber meistens nur neben dem
Passwort eine Option und nicht verpflichtend. Die Alternativen zum Passwort haben sich aber
weltweit nicht durchgesetzt. Dies könnte u.a. auch damit zu tun haben, dass auch jedes Land andere
Voraussetzungen, wie Technik oder Kultur, mit sich bringt. So scheinen nur Passwörter überall
akzeptiert zu sein. So werden z.B. TAN Listen, wie sie beim Onlinebanking in Deutschland Standard
sind, in anderen Ländern nicht angewandt und Überweisungen werden über wiederverwendbare
PINs abgesichert. Sichere Verfahren, wie die mTAN ersetzen in Deutschland langsam die TAN Listen,
doch in weniger technisch zuverlässigen Ländern wäre es zurzeit nicht möglich, da SMS täglich
verloren gehen. Das würde das mTAN-Verfahren unzuverlässig machen. Sollte sich der nPA in
Deutschland durchsetzen, dann wäre es nur für deutsche Onlinedienste interessant, da Benutzer aus
anderen Ländern sich nicht einloggen könnten. Durch fortschreitende Technik können neue
Möglichkeiten für Authentisierungen hinzukommen, wie z.B. mit der weiten Verbreitung und
Weiterentwicklung von Handys bzw. Smartphones. Damit könnten sichere und einfache
Authentisierungen ermöglicht werden, wie z.B. über Apps. Sie wären kostengünstig und einfach zu
besorgen, wie es z.B. mit dem Google Authenticator der Fall ist.
Ich habe in der Arbeit verschiedene Authentisierungsverfahren für Online Accounts vorgestellt
(Tabelle 9). So gibt es einige Authentisierungsverfahren, die sich prinzipiell ähnel n und sich nur
dadurch unterscheiden, dass einige gegen bestimmte Angriffsmethoden besser geschützt sind. Diese
scheinen aber bei den Benutzern und Anbietern nicht auf breite Akzeptanz zu stoßen und sind immer
noch nicht verbreitet oder selbstverständlich wie die Authentisierung mit einem Passwort. Solange
die Benutzer weltweit nicht auf die Gefahr von gehackten Accounts sensibilisiert werden, wird es
wohl weiterhin schwer sein, Passwörter als Authentisierungen mit anderen Verfahren zu ersetzen
bzw. Einmalpasswörter verpflichtend einzuführen. Zumal sich kein Standard durchgesetzt hat und
jedes Unternehmen eine eigene Lösung anbietet. Man sollte die Entwicklung aber weiter beobachten,
da sich vielleicht Onlinedienste wie Facebook weltweit durchsetzen könnten und durch Medien die
Aufklärungen über die Gefahren von gehackten Accounts auch den Benutzern vielleicht bewusster
wird. Sollte die Nachfrage daher weltweit nach sicheren Authentisierungen steigen, könnten sich
dann vielleicht einer der Alternativen dann als einzige Authentisierung durchsetzen und nicht nur als
eine optionale zusätzliche Methode. Denn die Gefahren sind groß, sollten E-Mail Accounts oder
Handys gehackt werden, was bisher leider nur in den Medien berichtet wird, wenn Prominente Opfer
von solchen Angriffen wurden. Die Tatsache, dass es Millionen Menschen passiert, scheint leider
noch nicht in den Köpfen der Benutzer angekommen. So werden täglich 600.000 missbräuchliche
Loginversuche auf Facebook registriert. Laut Facebook wären täglich nur 0,06 Prozent der Logins
kompromittiert [Brodkin, 2011]. Vielleicht ist es im Vergleich zu der großen Anzahl von Logins gering,
aber sieben kompromittierte Accounts pro Sekunde sind andererseits eine ziemlich große Zahl. Und
159
wie auf Abbildung 154 zu sehen ist, unternimmt Facebook große Anstrengungen um Accounts zu
schützen. Dabei ist die Hälfte davon optional, wobei diese Verfahren die Accountsicherheit sehr
erhöhen würden. So wird es schon fast vorausgesetzt, dass der eingeloggte Benutzer ein Angreifer
und nicht der tatsächliche Benutzer ist und man versucht über verschiedene Beobachtungen
festzustellen131 , ob es sich tatsächlich um den Benutzer handelt. Würde man tatsächlich ein sicheres
Authentisierungsverfahren einsetzen, dann könnte man viel Geld und Zeit sparen, die man zurzeit
aufwendet um herauszufinden, ob ein Account beim Einloggen kompromittiert ist oder nicht.
Dabei müssten Authentisierungsverfahren sogar nicht zu 100% vor Angreifern schützen können, aber
sie sollten Angriffe so erschweren, dass sie zu teuer werden. Dann würden viele Hacker nicht mehr
versuchen Accounts über den Benutzer anzugreifen, da sich der Aufwand nicht lohnt. Sollten
Authentisierungsverfahren so schwer zu knacken sein, dass sie zu teuer und aufwändig sind, dann
sollte man dann nicht die Serversicherheit vernachlässigen, auf denen die Schlüssel wie z.B.
Zertifikate, Seeds usw. gespeichert sind. Es wäre dann lohnender und günstiger die
"Originalschlüssel" zu klauen, als sie bei den Benutzern zu suchen. Eine kurzfristige Lösung um Online
Accounts sicherer zu machen wäre vielleicht, dass man die Benutzer gegenüber Accountsicherheit
sensibilisiert ,d.h. die Aufklärung gegenüber Accountsicherheit erhöht und sie dazu bringt sichere
Passwörter zu verwenden und regelmäßig zu wechseln. So könnte dann auch die Nachfrage nach
sicheren Authentisierungsverfahren erhöht werden, da die Benutzer über die Gefahren informiert
werden. Eine mittelfristige Lösung wäre dann, weiterhin auf sogenannte Insellösungen zu setzen und
jeder Onlinedienst bietet verpflichtend ein sicheres Verfahren als Option an, sei es ein Authenticator
Token oder ein Authenticator App für IPhones oder Android Smartphones. Eine langfristige Lösung
wäre, wenn man auf einen sicheren Mindeststandard einigen könnte, dass für alle Online Accounts
verpflichtend gilt. Wie z.B. bei DMARC132 (Domain-based Message Authentication, Reporting and
Conformance133) , könnte man eine Allianz gründen, um einen sicheren Standard zu entwickeln und
einzuführen. Dabei sollte man beachten, dass jedes Land das Verfahren einsetzen kann, unabhängig
wie weit das Land technische entwickelt ist. Man kann dies am Beispiel von den sinkenden
Skimmingfälle bei Bankautomaten erkennen. So sanken die Skimmingfälle um 45% im Jahre2011 zum
Vorjahr, da rigoros die EC-Karten und Automaten umgerüstet wurden, so dass die einfache
Skimmingmethode mit den Magnetstreifenkarten nicht mehr funktionierten. Die Skimmingbetrüger
sind daher auf andere Länder wie Russland oder den USA ausgewichen, wo sich Chipkarten noch
nicht durchgesetzt haben bzw. auf Tankautomaten, die immer noch mit Magnetstreifen arbeiten
[Eikenberg, heise Security, 2011].
131
Dabei werden Login, Onlineverhalten und sogar Logout bebobachtet.
Eine Allianz aus konkurrierenden Unternehmen wie Facebook, Google, PayPal und Yahoo, die eine Technik
vorgestellt haben, um gegen Phishingmails vorzugehen.
133
http://www.dmarc.org/
132
160
Abbildung 154 134: Facebook Security Infographic
134
http://www.scribd.com/doc/70451272/Facebook-Security-Infographic
161
12 Literaturverzeichnis
amz/dapd/AP/Reuters/dpa/AFP. (03. Mai 2011). Millionen Bankdaten gestohlen: Sony meldet
Hackerangriff auf weiteres Netzwerk. Abgerufen am 06. Oktober 2011 von SPIEGEL ONLINE:
http://www.spiegel.de/netzwelt/gadgets/0,1518,760256,00.html
Authentifizierung, W. (03. Oktober 2011). Authentifizierung. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Authentifizierung
Bachfeld, D. (03. Juni 2011). Cracker Bremse. Abgerufen am 2011. Oktober 2011 von heise online:
http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html
Beiersmann, S., & Poessneck, L. (14. November 2011). silicon.de. Abgerufen am 21. Dezember 2011
von Android-Geischtserkennung ausgetrickst:
http://www.silicon.de/technologie/mobile/0,39044013,41557128,00/android_gesichtserkennung_a
usgetrickst.htm
Beschke, S. (2009). Demonstration des Cardano TAN-Verfahrens. Abgerufen am 07. November 2011
von Arbeitsbereich für Theoretische Informatik/Formale Sprachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/studdiplbeschke/
Borchert, B. (April 2009). Bildpasswort-TAN Verfahren. Abgerufen am 07. November 2011 von
Arbeitsbereich für Theoretische Informatik/Formale Sprachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/BildpasswortTAN/index.php
Borchert, B. (kein Datum). Bild-TAN Verfahren. Abgerufen am 07. November 2011 von Arbeitsbereich
für Theoretische Informatik/Formale Sprachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/BildTAN/
Borchert, B. (2009). Patentnr. DE-10-2009-007277.2. Deutschland.
Borchert, B. (kein Datum). eKaay - Mit dem Handy einloggen, statt mit Passwort. Abgerufen am 07.
November 2011 von eKaay - Mobile Authentication: http://www.ekaay.com/demo/
Borchert, B. (kein Datum). eKaay PIN. Abgerufen am 07. November 2011 von eKaay - Mobile
Authentiation: http://www.ekaay.com/PIN/
Borchert, B. (2009). Fotohandy-TAN mit NFC. Abgerufen am 07. November 2011 von Arbeitsbereich
für Theoretische Informatik/Formale Sprachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/NFC-Fotohandy-TAN/
Borchert, B. (kein Datum). Knick- und-Klick PIN. Abgerufen am 07. November 2011 von
Arbeitsbereich für Theoretische Informatik/Formale Srachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/pPIN/
Borchert, B., & Reinhardt, K. (2008). Patentnr. WO/2008/128528. Deutschland.
Borchert, B., & Reinhardt, K. (2009). Patentnr. WO/2009/000223. Deutschland.
Borchert, B., Fouquet, M., Niedermayer, H., & Reinhardt, K. (2008). Patentnr. DE-10-2008-062872.7.
Deutschland.
162
Borges, G., Schwenk, J., Stuckenberg, C.-F., & Wegener, C. (2011). Identitätsdiebstahl und
Identitätsmissbrauch im Internet. Berlin Heidelberg: Springer.
Brainard, J., Juels, A., Rivest, R. L., Szydlo, M., & Yung, M. (2006). Fourth Factor Authentication:
Somebody You Know. ACM CCS, (S. 168-178). http://www.rsa.com/rsalabs/node.asp?id=3156.
Brodkin, J. (28. Oktober 2011). Facebook sees 600,000 comrpomised logins per day - 0.06% of all
logins. Abgerufen am 01. November 2011 von ars technica:
http://arstechnica.com/gadgets/news/2011/10/facebook-sees-600000-compromised-logins-perday006-of-all-logins.ars
BSI. (2011). BSI: Der neue Personalausweis - Geeignete Kartenleser. Abgerufen am 19. Oktober 2011
von BSI: Der neue Personalausweis: https://www.ausweisapp.bund.de/pweb/cms/kartenleser.jsp
BSI. (September 2010). Innovationen für eine eID-Achitektur in Deutschland. Abgerufen am 19.
Oktober 2011 von Bundesamt für Sicherheit in der Informationstechnik:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekAusweise/Pressemappe_nPA/Innovati
onen_eID-Architektur_Deutschland.pdf?__blob=publicationFile
BSI. (2008). M 2.11 Regelung des Passwortgebrauchs. Abgerufen am 06. Oktober 2011 von
Bundesamt für Sicherheit in der Informationstechnik:
https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m02/m02011.html
BSI TR-03110. (14. Oktober 2010). BSI TR-03110 Advanced Security Mechanism for Readable Travel
Documents. Abgerufen am 19. Oktober 2011 von Bundesamt für Sicherheit in der
Informationstechnik:
https://www.bsi.bund.de/cln_0/ContentBSI/Publikationen/TechnischeRichtlinien/tr03110/index_ht
m.html
BSI TR-03112-7. (23. Mai 2011). eCard-API-Framework Teil 7. Abgerufen am 19. Oktober 2011 von
Bundesamt für Sicherheit in der Informationstechnik:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03
112/API/api1_teil7_pdf.pdf?__blob=publicationFile
Chappel, D. (April 2006). Introducing Windows CardSpace. Abgerufen am 19. Oktober 2011 von
MSDN Microsoft: http://msdn.microsoft.com/en-us/library/Aa480189
Cross-document messaging. (04. Oktober 2011). Cross-document messaging. Abgerufen am 19.
Oktober 2011 von WIKIPEDIA: http://en.wikipedia.org/wiki/Cross-document_messaging
Cross-Site-Scripting, W. (13. September 2011). Cross-Site-Scripting. Abgerufen am 06. Oktober 2011
von WIKIPEDIA: http://de.wikipedia.org/wiki/Cross-Site_Scripting
Cryptas. (2011). Kosten eines Passwortsystems. Abgerufen am 06. Oktober 2011 von cryptoshop:
http://www.cryptoshop.com/de/knowledgebase/governance/economics/passwordroi.php
Datenschutzbeauftragter. (10. Mai 2011). Identitätsklau bei OpenID. Abgerufen am 19. Oktober 2011
von Datenschutzbeauftragter: Information zum Datenschutz: http://www.datenschutzbeauftragterinfo.de/identitaetsklau-bei-openid/
163
Deep Crack, W. (25. September 2011). EFF DES cracker. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://en.wikipedia.org/wiki/EFF_DES_cracker
Drive-by-Download, W. (12. Juni 2011). Drive-by-Download. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Drive-by-Download
Dwiputera, A. F. (2005). Single-Sign-On architectures in public networks (Liberty Alliance). Abgerufen
am 19. Oktober 2011 von INFOTECH Seminar Advanced Communitaction Services:
http://www.linecity.de/INFOTECH_ACS_SS05/acs5_top7_paper.pdf
Eichholz, J., Hühnlein, D., & Schwenk, J. (2009). SAMLizing the European Citizen Card. Abgerufen am
19. Oktober 2011 von esec: http://www.ecsec.de/pub/SAMLizing-ECC.pdf
Eikenberg, R. (16. Januar 2012). "Sesam öffne dich" statt Passwort. Abgerufen am 26. Januar 2012
von heise Security: http://heise.de/-1414050
Eikenberg, R. (23. Dezember 2011). heise Security. Abgerufen am 02. Februar 2012 von 45 Prozent
weniger Opfer durch manipulierte Geldautomaten: http://heise.de/-1401043
facebook Developers. (September 2011). Facebook für Websites - Facebook-Entwickler. Abgerufen
am 19. Oktober 2011 von Facebook: http://developers.facebook.com/docs/guides/web/#login
Facebook. (2011). Statistik. Abgerufen am 19. Oktober 2011 von Facebook:
http://www.facebook.com/press/info.php?statistics
Facebook. (2011). Statistik. Abgerufen am 10. Dezember 2011 von Facebook:
http://www.facebook.com/press/info.php?statistics
Fiat, A., & Shamir, A. (19. September 2011). Fiat-Shamir-Protokoll. Abgerufen am 06. Oktober 2011
von WIKIPEDIA: http://de.wikipedia.org/wiki/Fiat-Shamir-Protokoll
Google. (2011). Bestätigung in zwei Schritten. Abgerufen am 07. Oktober 2011 von Google:
http://www.google.com/support/accounts/bin/topic.py?hl=de&topic=28786
Google. (2011). google-authenticator - Two-step verification. Abgerufen am 07. Oktober 2011 von
Google: http://code.google.com/p/google-authenticator/
Haber, J. (17. Mai 2011). SmartScreen® Application Reputation in IE9. Abgerufen am 06. Oktober
2011 von MSDN Blogs: http://blogs.msdn.com/b/ie/archive/2011/05/17/smartscreen-174application-reputation-in-ie9.aspx
Hammer-Lahav, E. (23. April 2009). Explaining the OAuth Session Fixation Attack. Abgerufen am 19.
Oktober 2011 von hueniverse: http://hueniverse.com/2009/04/explaining-the-oauth-sessionfixation-attack/
Hammer-Lahav, E. (April 2010). RFC 5849. Abgerufen am 19. Oktober 2011 von Internet Engineering
Task Force: http://tools.ietf.org/html/rfc5849#section-3.4.1
Hammer-Lahav, E., Recordon, D., & Hardt, D. (05. September 2011). The OAuth 2.0 Authorization
Protocol: draft-ietf-oauth-v2-21. Abgerufen am 07. Oktober 2011 von The Internet Engineering Task
Force : http://tools.ietf.org/html/draft-ietf-oauth-v2-21
164
Hauck, P. (2003). Kryptologie und Datensicherheit. Vorlesung WS 2002/2003 (S. 8-13). Tübingen:
Vorlesungsskript von Jürgen Sommer.
Hilaiel, L. (2011). How BrowserID Works. Abgerufen am 19. Oktober 2011 von lloyd.io:
http://lloyd.io/how-browserid-works
Hoeveler, C. (04. Juli 2010). Authentifizierung oder Authentisierung? Abgerufen am 06. Oktober 2011
von wörter blog: http://woerter.germanblogs.de/archive/2010/07/04/authentifizierung-oderauthentisierung.htm
Hueniverse. (15. Juli 2011). OAuth. Abgerufen am 06. Oktober 2011 von hueniverse:
http://hueniverse.com/oauth/
IdM, W. (29. September 2011). Identitätsmanagement. Abgerufen am 07. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Identit%C3%A4tsmanagement
Information zum Datenschutz. (21. Juni 2011). Passwort-Sicherheit: Size does matter. Abgerufen am
06. Oktober 2011 von Datenschutzbeauftragter Info: Information zum Datenschutz:
http://www.datenschutzbeauftragter-info.de/passwort-sicherheit-size-does-matter/
Kerberos, W. (13. September 2011). Kerberos (protocol). Abgerufen am 07. Oktober 2011 von
WIKIPEDIA: http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
Kerckhoffs, A. (02. Oktober 2011). Kerckhoffs' Prinzip. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip
Key size, W. (06. Oktober 2011). Key size. Abgerufen am 06. Oktober 2011 von WIKIPEDIA:
http://en.wikipedia.org/wiki/Key_size
Knoke, F. (19. Mai 2011). Netzwelt-Ticker. Abgerufen am 06. Oktober 2011 von SPIEGEL ONLINE:
http://www.spiegel.de/netzwelt/web/0,1518,763586,00.html
Kremp, M. (06. September 2011). Diginotar-Hack: Attacke auf das Sicherheitssystem des Web.
Abgerufen am 07. 10 2011 von SPIEGEL ONLINE:
Kryptoanalyse, W. (07. Juli 2011). Kryptoanalyse. Abgerufen am 06. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/Kryptoanalyse
lis/AFP/dpa. (20. 05 2011). Polizeistatistik: Netz-Kriminalität steigt auf Rekordwert. Abgerufen am 05.
10 2011 von SPIEGEL ONLINE: http://www.spiegel.de/netzwelt/netzpolitik/0,1518,763806,00.html
Lischka, K. (29. November 2011). Umstrittener Identitäts-Cookie. Abgerufen am 26. Januar 2012 von
SPIGEL ONLINE: http://www.spiegel.de/netzwelt/netzpolitik/0,1518,799909,00.html
Malware, W. (06. Oktober 2011). Schadprogramm. Abgerufen am 06. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/Malware
Manhart, D. K. (26. Juni 2007). Sicherheit bei Web Services: SAML. Abgerufen am 19. Oktober 2011
von TecChannel:
http://www.tecchannel.de/webtechnik/soa/479383/sicherheit_bei_web_services/index8.html
165
Microsoft CardSpace. (23. August 2011). Microsoft CardSpace. Abgerufen am 19. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Microsoft_CardSpace
Microsoft Corporation. (15. Februar 2011). Beyond Windows CardSpace. Abgerufen am 19. Oktober
2011 von Claims-Based Identity Blog - MSDN Blogs:
http://blogs.msdn.com/b/card/archive/2011/02/15/beyond-windows-cardspace.aspx
Microsoft Corporation. (Juli 2007). Windows Live ID Federation. Abgerufen am 19. Oktober 2011 von
MSDN White Paper: http://www.avrashow.com/docs/WLID-Federation-whitepaper.doc
Mills, D. (14. Juli 2011). Identity at Mozilla. Abgerufen am 19. Oktober 2011 von Home of the Mozilla
Identity team: http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-tosign-in
MITM, W. (08. September 2011). Man-in-the-middle-Angriff. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/Man-in-the-middle-Angriff
Mozilla Wiki. (17. Juli 2011). Verfified Email Protocol. Abgerufen am 19. Oktober 2011 von
MozillaWiki: https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol
Naor, M., & Shamir, A. (1994). Visual Cryptography. EUROCRYPT, (S. 1-12).
Narang, R. (21. Mai 2011). LidedIN SSL Cookie Vulnerability. Abgerufen am 06. Oktober 2011 von
WTF.uzz: http://www.wtfuzz.com/blogs/linkedin-ssl-cookie-vulnerability/
OASIS. (25. März 2008). SAML V.20 Technical Overview. Abgerufen am 19. Oktober 2011 von OASIS:
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.pdf
OAuth Security Adivsory. (23. April 2009). Oauth Security Advisory: 2009.1. Abgerufen am 19.
Oktober 2011 von OAuth: http://oauth.net/advisories/2009-1/
Ohlhorst, F. J. (09. April 2004). VARs Can Help Solve The Identity Crisis. Abgerufen am 06. Oktober
2011 von CRN: http://www.crn.com/news/security/18841586/vars-can-help-solve-the-identitycrisis.htm?itc=refresh
OpenID Foundation. (2006-2011). What is OpenID? Abgerufen am 19. Oktober 2011 von OpenID:
http://openid.net/get-an-openid/what-is-openid/
OpenID, W. (25. September 2011). OpenID. Abgerufen am 19. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/OpenID
OTP, W. (06. Oktober 2011). One-Time-Pad. Abgerufen am 06. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/One-Time-Pad
Pfefferle, M. (26. Juni 2010). Login leicht gemacht: Single-Sing-ON mit Facebook, Twitter und dem
Open Stack. Abgerufen am 19. Oktober 2011 von t3n Magazin: http://t3n.de/magazin/single -sign-onfacebook-twitter-open-stack-login-leicht-224747/
Phishing, W. (28. September 2011). Phishing. Abgerufen am 06. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/Phishing
166
Robertson, J. (17. August 2011). Viren und Trojaner: Angriffe auf Smartphones nehmen zu. Abgerufen
am 01. November 2011 von SPIEGEL ONLINE:
Rohrer, E. (November 2009). Linien-TAN Verfahren. Abgerufen am 07. November 2011 von
Arbeitsbereich für Theoretische Informatik/Formale Sprachen: http://www-ti.informatik.unituebingen.de/~borchert/Troja/studdiplLinienTAN/
SAML, W. (07. Oktober 2011). Security Assertion Markup Language. Abgerufen am 19. Oktober 2011
von WIKIPEDIA: http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
Sawall, A. (01. November 2011). E-Personalausweis: Praktisch keine Nutzer für Onlinefunktionen.
Abgerufen am 03. November 2011 von Golem.de: http://www.golem.de/1111/87444.html
Schmidt, J. (20. April 2011). Das Like-Problem. Abgerufen am 26. Januar 2012 von heise Security:
http://www.heise.de/security/artikel/Das-verraet-Facebooks-Like-Button-1230906.html
Schneider, M. (22. August 2011). gamescom 2011: Kaspersky Vortrag über Gaming Security.
Abgerufen am 20. Oktober 2011 von NEGATIV - Magazin für Film und Medienkultur:
http://www.negativ-film.de/2011/08/gamescom-2011-kaspersky-vortrag-uber.html
Schönberg, M. (28. September 2007). Single Sign-On-Technologien für das World Wide Web.
Abgerufen am 19. Oktober 2011 von Universität Hamburg: Fakutlät für Mathematik, Informatik und
Naturwissenschaften: http://vsis-www.informatik.unihamburg.de/getDoc.php/thesis/179/Single_Sign-OnTechnologien_f%FCr_das_World_Wide_Web.pdf
SecurID, W. (03. Oktober 2011). SecurID. Abgerufen am 18. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/SecurID
Social Engineering, W. (11. September 2011). Sociial Engineering (Sicherheit). Abgerufen am 06.
Oktober 2011 von WIKIPEDIA: http://de.wikipedia.org/wiki/Social_Engineering_%28Sicherheit%29
Stöcker, C. (24. März 2011). Cyberangriff aus Iran: Hacker attackieren Fundamente des Internets.
Abgerufen am 07. 10 2011 von SPIEGEL ONLINE:
http://www.spiegel.de/netzwelt/netzpolitik/0,1518,752934,00.html
The OAuth 1.0 Guide. (30. September 2011). Security Framework. Abgerufen am 19. Oktober 2011
von hueniverse: http://hueniverse.com/oauth/guide/security/
Trojanisches Pferd, W. (23. September 2011). Trojaneisches Pferd (Computerprogramm). Abgerufen
am 06. Oktober 2011 von WIKIPEDIA:
http://de.wikipedia.org/wiki/Trojanisches_Pferd_%28Computerprogramm%29
twitters developer. (12. Juli 2011). Using OAuth 1.0a. Abgerufen am 06. Oktober 2011 von Twitters
Developers: https://dev.twitter.com/docs/auth/oauth
ULD. (2008). Was ist Identitätsmanagement? Abgerufen am 07. Oktober 2011 von Unabhängiges
Landeszentrum für Datenschutz Schleswig-Holstein:
https://www.datenschutzzentrum.de/projekte/idmanage/was.htm
167
Weigold, T., Kramp, T., Hermann, R., Höring, F., Buhler, P., & Baentsch, M. (2008). The Zurich Trusted
Information Channel - An Efficient Defence against Man-in-the-Middle and Malicious Software
Attacks. In A.-R. S.-M. P. Lipp (Hrsg.). (S. 75-91). Berlin Heidelberg: Springer-Verlag.
Welchering, P. (15. Oktober 2011). Kriminelle automatisieren den Datenklau. Abgerufen am 20.
Oktober 2011 von Digital: http://www.digital-zeitschrift.de/stories.php?id=51
Wilkens, A. (13. August 2010). Studie: Fast 50 Millionen Internetnutzer in Deutschland. Abgerufen am
06. Oktober 2011 von heise online: http://www.heise.de/newsticker/meldung/Studie-Fast-50Millionen-Internetnutzer-in-Deutschland-1058419.html
Windows Live ID. (03. Oktober 2011). Windows Live ID. Abgerufen am 19. Oktober 2011 von
WIKIPEDIA: http://en.wikipedia.org/wiki/Windows_Live_ID
Wörterbuchangriff, W. (06. August 2011). Wörterbuchangriff. Abgerufen am 06. Oktober 2011 von
WIKIPEDIA: http://de.wikipedia.org/wiki/W%C3%B6rterbuchangriff
13 Tabellenverzeichnis
Tabelle 1: Übersicht von Authentisierungsverfahren ....................................................................... 7
Tabelle 2: Verschlüsselungsverfahren .......................................................................................... 10
Tabelle 3: Qualität eines Angriffs.................................................................................................. 17
Tabelle 4: Gespeicherte eID-Datengruppen für eID-Funktionen...................................................... 95
Tabelle 5: Leistungen von Connect-Produkten [Pfefferle, 2010] ....................................................132
Tabelle 6: Angriffsqualität für No-Tech Verfahren ........................................................................152
Tabelle 7: Angriffsqualität für Low-Tech Verfahren.......................................................................152
Tabelle 8: Angriffsqualität für High-Tech Verfahren......................................................................152
Tabelle 9: Vergleich von Authentisierungsverfahren.....................................................................158
14 Abbildungsverzeichnis
Abbildung 1: Benutzer - Server Beziehung ...................................................................................... 8
Abbildung 2: Darstellung von Sender, Hacker und Empfänger........................................................ 10
Abbildung 3: Hacker Mallory probiert alle Kombinationen für ein Passwort aus. ............................. 12
Abbildung 4: Mallory schickt eine Phishingmail an den Alice. ......................................................... 12
Abbildung 5: Alice besucht eine gefälschte Seite und gibt seine Daten ein, die an den Mallory
weitergeleitet werden................................................................................................................. 13
Abbildung 6: Mallory gibt sich gegenüber Bob als Alice aus............................................................ 13
Abbildung 7: Mallory manipuliert eine Webseite mit einem Trojaner. ............................................ 14
Abbildung 8: Alice installiert den Trojaner unwissentlich über einen Drive -by-Download auf seinen
Rechner...................................................................................................................................... 14
Abbildung 9: Mallory schickt eine E-Mail mit einem angehängten Trojaner an Alice. ....................... 14
Abbildung 10: Alice verbindet sich mit Bob und die Zugangsdaten werden auch an Mallory gesendet.
.................................................................................................................................................. 15
168
Abbildung 11: Mallory loggt sich bei Bob ein. ................................................................................ 15
Abbildung 12: Mallory fängt die Kommunikation zwischen Alice und Bob ab und kann sie verändert
an ihnen weitergeben.................................................................................................................. 15
Abbildung 13: Eve hört die gesendeten Daten zwischen Alice und Bob ab...................................... 16
Abbildung 14: Eve gibt sich Bob gegenüber als Alice aus und sendet die abgehörten Daten an Bob.. 16
Abbildung 15: Benutzer kennt ein Geheimnis, dass nur er wissen kann, z.B. ein Passwort und
authentisiert sich damit beim Onlinedienst............................................................... ........................ 18
Abbildung 16: Benutzer besitzt einen schwer zu fälschenden Gegenstand, z.B. ein Ausweis und
authentisiert sich damit beim Onlinedienst.......................................................................................... 19
Abbildung 17: Benutzer besitzt biometrische Daten wie Fingerabdruck, Iris, DNA und authentisiert
sich damit beim Onlinedienst................................................................................................. ...............20
Abbildung 18: Authentisierung über das soziale Netzwerk: Jemand bestätigt die Identität vom
Besitzer beim Onlinedienst................................................................................................................ .. 21
Abbildung 19: Methoden der Authentisierung .............................................................................. 22
Abbildung 20: Klartextpasswortübertragung ................................................................................. 23
Abbildung 21: Sicherheitsrisikofaktoren: Passwort, Benutzer, Übertragung, Speicherung................ 23
Abbildung 22: Challenge-Response Verfahren mit symmetrischer Verschlüsselung ......................... 26
Abbildung 23: Beispiel eines iPIN-Verfahrens bei der Bank of Ireland ............................................. 31
Abbildung 24: Beispiel eines Logins über eine Geheimfrage bei der Bank of Ireland ........................ 32
Abbildung 25: Beispiel einer Zwei-Schritte Authentisierung bei der Bank of Ireland......................... 33
Abbildung 26: Beziehungen zwischen Authentisierungsverfahren basierend auf Wissen ................. 35
Abbildung 27: RSA SecurID 700 Token und Battle.Net Authenticator von Blizzard ........................... 36
Abbildung 28: Möglicher Authentisierungsablauf mit RSA Token.................................................... 37
Abbildung 29: Mögliche Angriffsziele während einer Anmeldung mit einem RSA Token .................. 37
Abbildung 30: ZTIC USB Device..................................................................................................... 40
Abbildung 31: ZTIC Benutzer Ablauf ............................................................................................. 40
Abbildung 32: Technischer Ablauf mit ZTIC Device ........................................................................ 40
Abbildung 33: Beispiel einer Einmal-PIN-Liste ............................................................................... 43
Abbildung 34: Möglicher Ablauf eines Einmal-PIN Liste Verfahrens ................................................ 43
Abbildung 35: Mögliche Sicherheitsrisikofaktoren ......................................................................... 44
Abbildung 36: Beispiel eines Phishingversuchs für Onlinebanking über eine gefälschte Webseite .... 45
Abbildung 37: indizierte Einmal-PIN-Liste ..................................................................................... 46
Abbildung 38: iTAN mit CAPTCHA Beispiel .................................................................................... 47
Abbildung 39: CAPTCHA Beispiele ................................................................................................ 47
Abbildung 40: Yahoo! sign-in-seal ................................................................................................ 47
Abbildung 41: iiTAN Liste ............................................................................................................. 49
Abbildung 42: Beispiel einer Anmeldeseite ................................................................................... 49
Abbildung 43: Eingabe-Beispiel einer indirekten indizierten Einmalpasswortliste ............................ 50
Abbildung 44: BildTAN Karte ........................................................................................................ 51
Abbildung 45: Beispiel eines Loginbildschirms............................................................................... 51
Abbildung 46: Beispiel eines Loginbildschirms für Bestätigungsschritt ............................................ 52
Abbildung 47: Anmeldebildschirm mit angelegter Bild-PIN Liste..................................................... 52
Abbildung 48: Linien-PIN Liste...................................................................................................... 54
Abbildung 49: Eingabemaske für Linien-PIN Verfahren .................................................................. 54
Abbildung 50: Beispiel von Linien-PIN mit angelegter Liste ............................................................ 55
Abbildung 51: Beispiel einer Cardano Lochkarte............................................................................ 55
169
Abbildung 52: Beispiel einer Anmeldeseite mit Cardano PIN.......................................................... 56
Abbildung 53: Lochkarte wurde über das Ziffernfeld gelegt und man sieht nun die Felder für die PIN
.................................................................................................................................................. 56
Abbildung 54: Die Ziffern und die PIN die hinter dem Eingabefeld stehen, wie es die Cardano
Lochkarte anzeigt........................................................................................................................ 57
Abbildung 55: A zeigt das Bildschirm ohne die drübergelegte Folie und B zeigt das Geheimnis, indem
man die Folie über das Bildschirm legt.......................................................................................... 58
Abbildung 56: Mögliche Angriffsziele............................................................................................ 58
Abbildung 57: Beispiel einer indizierten Permutationsliste............................................................. 60
Abbildung 58: Loginbeispiel für pPIN ............................................................................................ 60
Abbildung 59: Anwendungsbeispiel mit pPIN ................................................................................ 60
Abbildung 60: Angriffsmöglichkeiten ............................................................................................ 61
Abbildung 61: Bildpasswort-PIN-Liste ........................................................................................... 62
Abbildung 62: Bildpasswort ......................................................................................................... 62
Abbildung 63: Beispiel eines Überweisungsformulars .................................................................... 63
Abbildung 64: Eingabebeispiel ..................................................................................................... 63
Abbildung 65: Bankey: Token von der Volkswagenbank................................................................. 64
Abbildung 67: Beispiel von Bankey ............................................................................................... 65
Abbildung 68: sm@rt-TAN Generator in der die Karte oben eingefügt wird. ................................... 67
Abbildung 69: ChipTAN Generator genannt tanJack® optic SR von der Kreissparkasse Freudenstadt 69
Abbildung 70: Sm@rt-TAN plus Gerät der Volksbank..................................................................... 70
Abbildung 71: Erzeugung eines TANs einer Sparkasse mittels chipTAN comfort .............................. 70
Abbildung 72: Hardwarevoraussetzungen von Authentisierungsverfahren ..................................... 74
Abbildung 73: Möglicher Kommunikationsablauf mit mTAN .......................................................... 76
Abbildung 74: Risiken beim mTAN................................................................................................ 76
Abbildung 75: Funktionsablaufbeispiel mit eKaay.......................................................................... 79
Abbildung 76: eKaay Funktionsablaufbeispiel mit SSO ................................................................... 80
Abbildung 77: Kommunikationsablauf mit Google Sesame............................................................. 82
Abbildung 78: Datenfluss von eKaayPIN als Zwei-Wege-Kommunikation ........................................ 84
Abbildung 79: Authentisierung wird über einen Browser und ein Handy auf zwei unterschiedliche
Wege vorgenommen. .................................................................................................................. 85
Abbildung 80: Mehr-Faktor-Authentifizierung durch Kombinationen ............................................. 86
Abbildung 81: HBCI-1 Kartenlesegerät.......................................................................................... 87
Abbildung 84: Benutzer aktiviert die EC-Karte über ein Lesegerät mit einer PIN. Die Software erstellt
mit der EC-Karte und Lesegerät eine TAN, die man dann dem Onlinedienst zuschickt...................... 88
Abbildung 85: Mögliche Sicherheitsrisiken wie PIN, Lesegerät, Software und die Verbindung zum
Onlinedienst ............................................................................................................................... 89
Abbildung 86: Anmeldung an ein Google-Konto ............................................................................ 91
Abbildung 87:Zweiter Bestätigungsschritt..................................................................................... 91
Abbildung 88: Das Internetpassport ............................................................................................. 92
Abbildung 89: Anmeldebeispiel mit dem nPA................................................................................ 96
Abbildung 90: Kommunikationsablauf zwischen Benutzer, Onlinedienst, Lesegerät, nPA und CA
(Certification Authority), PKD (Public Key Directory)............................................................................ 97
Abbildung 91: Sicherheitsrisiken beim nPA ................................................................................... 98
170
Abbildung 92: Eingabemaske für die PIN......................................................................................100
Abbildung 93: Darstellung des Nummernfeldes auf dem Smartphone ...........................................101
Abbildung 94: NFC-Foto-TAN Verfahren ......................................................................................102
Abbildung 95: NFC-Foto-TAN Informationsfluss ...........................................................................103
Abbildung 96: Sicheres Fenster Verfahren ...................................................................................104
Abbildung 97: Beispiel einer Darstellung der Schlüsselkarte und des Monitors bei ei ner Überweisung
.................................................................................................................................................106
Abbildung 98: Dekodierte Darstellung des Monitors mit einer drüber liegenden Schlüsselkarte......106
Abbildung 99: 2-Schritte-Authentisierung innerhalb eines Faktors ................................................107
Abbildung 100: 2-Faktor-Authentisierung in 2 Schritten ...............................................................108
Abbildung 101: Klassische 2-Faktor-Authentisierung ....................................................................108
Abbildung 102: Symbiotische Zwei-Faktor Authentisierung in einem Schritt ..................................109
Abbildung 103: Anwendungsbeispiel einer permutierten Eingabeliste und Anmeldebildschirm ......111
Abbildung 104: Anwendungsbeispiel einer App für indirekte Eingabe des Passworts und
Anmeldeseite.............................................................................................................................111
Abbildung 105: Anmeldung mit PIN und PIN-Liste ........................................................................112
Abbildung 106: Indirekte Anzeige der PIN Nr. ..............................................................................113
Abbildung 107: Indirekte Anzeige der PIN Nr. mit Liste .................................................................113
Abbildung 108: Abhörsichere PIN Eingabe ...................................................................................114
Abbildung 109: Linien-PIN als Zwei-Faktor Authentifizierung ........................................................115
Abbildung 110: Mögliche Anzeige der PIN Eingabe .......................................................................115
Abbildung 111: Token zeigt die Zifferdarstellung an, die man bei der Anmeldeseite für die PIN
anklicken muss...........................................................................................................................116
Abbildung 112: Klassifizierung von Authentisierungsverfahren .....................................................118
Abbildung 113: Ticket Granting Ticket .........................................................................................122
Abbildung 114: Anmeldung auf einem Onlinedienst .....................................................................123
Abbildung 115: OpenID Datenfluss ..............................................................................................125
Abbildung 116: Anmeldeform mit OpenID ...................................................................................125
Abbildung 117: Ausgefüllte OpenID.............................................................................................125
Abbildung 118: Beispiel einer Datenfreigabe bei OpenID ..............................................................126
Abbildung 119: Demonstrationsablauf für Shibboleth ..................................................................127
Abbildung 120: Benutzer möchte sich auf eine Webseite einloggen. .............................................128
Abbildung 121: Auswahl des Heimanbieters ................................................................................128
Abbildung 122: Authentisierung des Benutzers ............................................................................129
Abbildung 123: Benutzer hat den Zugang erhalten .......................................................................129
Abbildung 124: Circle of Trust .....................................................................................................130
Abbildung 125: SSO Authentisierung mit Liberty Alliance..............................................................130
Abbildung 126: Basisinformationseite eines Entwicklers auf Facebook ..........................................133
Abbildung 127: Beispiel einer Initialisierung.................................................................................133
Abbildung 128: FB Connect Funktionalität ...................................................................................134
Abbildung 129: Beispiel für Login mit Facbook Button ..................................................................135
Abbildung 130: Anmeldung auf Facebook ....................................................................................135
Abbildung 131: Erlaubnisabfrage zur Übermittlung von Basisinformationen ..................................136
Abbildung 132: Beispiel einer Übermittlung zusätzlicher Parameter mit OAuth Dialog ...................136
Abbildung 133: Beispiel einer Übermittlung zusätzlicher Attributen beim Erstellen des Login Buttons
.................................................................................................................................................136
171
Abbildung 134: Beispiel eines Cookie (in fbs_YOUR_APP_ID gespeichert) Zugriffs in PHP................137
Abbildung 135: Beispiel für CSFR Schutz mit PHP nach Facebook ..................................................138
Abbildung 136: Protokollfluss einer Loginsession .........................................................................140
Abbildung 137: Interaktion zwischen Benutzer, Identitätsprovider und Onlinedienst .....................142
Abbildung 138: CardSpace Kartenauswahlschirm .........................................................................142
Abbildung 139: Anzeige der übermittelnden Daten, die der Benutzer bestätigen muss...................143
Abbildung 140: BrowserID Erstellung...........................................................................................145
Abbildung 141: Erstellung eines BrowserID Kontos.......................................................................145
Abbildung 142: Bestätigungsnachricht.........................................................................................146
Abbildung 143: Erstellung einer Identität Assertion ......................................................................147
Abbildung 144: Sign in Symbol bei eingebauter BrowserID Funktion .............................................147
Abbildung 145: Auswahl der E-Mail Adresse bei der Anmeldung ...................................................148
Abbildung 146: Beispiel einer Identität Assertion in JSON Struktur ................................................148
Abbildung 147: Benutzer wird authentifiziert über Assertion ........................................................148
Abbildung 148: Beziehungen zwischen SSO Verfahren..................................................................151
Abbildung 149: No-Tech Verfahren .............................................................................................153
Abbildung 150: Low-Tech Verfahren............................................................................................153
Abbildung 151: High-Tech Verfahren...........................................................................................154
Abbildung 152: Zwei-Faktor Verfahren ........................................................................................154
Abbildung 153: Vergleich nach Sicherheit und Benutzerfreundlichkeit ..........................................155
Abbildung 154: Verfahren in Abhängigkeit von Sicherheit und Benutzerfreundlichkeit. ..................156
Abbildung 155: Facebook Security Infographic.............................................................................161
Erklärung
Ich versichere, dass ich die vorstehende Arbeit selbständig und ohne fremde Hilfe angefertigt und
mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedient habe. Alle
Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden, sind solche als
kenntlich gemacht.
Außerdem erkläre ich, dass ich mit der Einstellung dieser Diplomarbeit in den Bestand der
Bibliotheken der Universität einverstanden bin.
Tübingen, den 15.02.2012
Il-Hyun Kim
172

Dipl. - Universität Tübingen

Transcrição

Documentos relacionados

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

Original Empfänger Mazda 626 GF Auf Zu 1k 1k +

Benutzerordnung iServ der Realschule Meinersen

Phishing und Pharming: Diebstahl im Netz

Martin-Luther-Universität Halle-Wittenberg Naturwissenschaftliche

Office 365 Admin Center – First Steps - RZ

ALLGEMEINE GESCHÄFTSBEDINGUNGEN

Finanzamt Treptow-Köpenick