In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

In den Anfängen des Internets hatte man ein Passwort. Womöglich noch eines für alle Dienste, das war einfach zu merken. Böse Leute, die einem nach den Zugangsdaten trachteten, gab es nicht.

In den letzten Jahren haben sich (zu Recht) zwei Standards nach und nach durchgesetzt: SingleSignOn und 2-Faktor-Authentisierung (bzw. generell Mehr-Faktor-Authentisierung). Der erste macht das Leben komfortabler (aber nicht unbedingt sicherer), der zweite das Leben sicherer (aber nicht unbedingt komfortabler).

Beim SingleSignOn meldet man sich an einem zentralen System an, und wird damit automatisch oder auf Knopfdruck in alle anderen Systeme "durchgeloggt". 

Der Klassiker ist die Windows-Anmeldung in einem ActiveDirectory, ich melde mich am PC an und habe direkt Zugriff auf meine Netzlaufwerke (obwohl die auf anderen Server liegen), bin im Intranet meiner Firma direkt eingeloggt usw. usf.

Zur Abgrenzung, was nicht SSO ist:

• Ich melde mich auf meinem PC an und bin direkt in meinem Softphone, meinem Outlook usw. eingeloggt (weil ich mich da mal irgendwann separat eingeloggt hatte, und Windows einfach diese Anmeldeinformationen gespeichert hat.
• Ich habe (automatisch) das gleiche Passwort für alles, d.h. ich kann mich im Browser im Webmail-Tool mit meinen Windows-Zugangsdaten einloggen.
• Ich melde mich morgens mit einem extrem sicheren Passwort in einer Software wie z.B. 1Password an und den Rest des Tages kennt mein PC all seine (unterschiedlichen) Passwörter automatisch.

Sondern SingleSignOn ist wirklich:

• Ich rufe z.B. die Startseite unseres Intranets auf und logge mich ein
• Ab dann kann ich alle anderen internen Systeme (TroubleTicket-System, Zeiterfassung, CMS, ...) nutzen, auch wenn die auf völlig anderen Servern liegen
• Wenn irgend ein System (z.B. ein CMS) mich nicht erkennt und mich eigentlich nach dem Passwort fragen würde, fragt es statt dessen in einer Dreiecksbeziehung nach, ob ich befugt bin und loggt mich automatisch ohne Passworteingabe ein.
• Automatisch ("Single-Sign-Off") und z.B. nach einer gewissen Zeit verfällt mein Zugangstoken für z.B. die Zeiterfassung. Die würde mich dann wieder an die Intranet-Startseite weiterleiten, und wenn ich mich da schon ausgeloggt hatte, dann bin ich quasi auch (wenn auch evtl. verzögert) in den anderen System ausgeloggt. 

Neben dem unternehmensinternen Einsatz gibt es auch andere Anwendungszwecke, z.B.

• in etwas entfernterem Sinne die Funktion "checkout by PayPal" (ich bestelle etwas in einem Online-Shop und anstatt Rechungs-/Lieferanschrift usw. einzugeben, nutze ich eine Art PayPal-SSO und bin in dem Shop direkt als Kunde "bekannt")
• Webseiten, bei denen man sich mit seinem Google- oder Facebook-Konto einloggen kann.
• Webseiten, bei denen nur bestimmte Zielgruppen Zugriff haben (z.B. nur Mitglieder eines Verbandes, oder nur bestimmte Berufsgruppen) und wo man sich dann mit z.B. seinem DocCheck-Account (Nachweis, dass man Arzt o.ä. ist) einloggen muss.

Technisch ist der Ablauf in der Regel folgender:

• Ich rufe z.B. unser Wiki auf und bin noch nicht eingeloggt.
• Wenn das Wiki verschiedene Login-Möglichkeiten (Username/Passwort zusätzlich zum SSO, oder SSO über verschiedene Systeme) erlaubt, dann muss ich jetzt noch "Login via Intranet" anklicken. Wenn es ohnehin nur diesen einen Login-Provider gibt (also man ohne Intranet-Zugang nicht ins Wiki kommt), geht der Schritt automatisch.
• Das Wiki leitet mich jetzt ans Intranet um mit sozusagen einer Stempelkarte im Anhang
• Bedingung 1 ist jetzt, dass das Intranet mich erkennt, weil ich dort schon eingeloggt bin. Wenn nicht, müsste ich das jetzt nachholen.
• Bedingung 2 ist, dass das Intranet weiß, das "SSO-zum-Wiki-hin" seine Richtigkeit hat. Wenn nicht, müsste ich das bestätigen ("darf die Webseite wiki.vollzeitnerd.de Zugriff auf folgende Infos haben: Name, Mail-Adresse")
• Wenn das ok ist, setzt der Intranet-Server ein Token (=ein Abrufcode) auf meine Stempelkarte, gibt sie mir wieder und schickt mich zurück zum Wiki-Server
• Der Wikiserver nimmt mir die Stempelkarte ab und holt sich direkt (ohne Umweg über mich, denn natürlich darf mein PC hierbei nicht mitreden) beim Intranet Infos ab: Ist das Token gültig? Darf der Typ ins Wiki rein? Wie heißt er?
• Mit diesen Infos werde ich jetzt (falls noch nicht geschehen) im Wiki als User angelegt und danach eingeloggt.

Vorteile dieser Technik sind Komfort einerseits und im Prinzip auch ein Sicherheitsgewinn, weil man an weniger Stellen Passwörter benötigt und eingeben muss. Außerdem können z.B. Berechtigungen zentral verwaltet werden (wenn mein Account wegfällt, ich das Passwort zurücksetzen möchte etc. geht das an einer Stelle zentral und es besteht kein Risiko, dass ich irgendwo noch das alte Passwort gesetzt habe).

Nachteil dieser Technik ist, 

• dass die Verfügbarkeit von zentralen Systemen abhänigt (fällt das Intranet-System aus, komme ich auch nicht mehr in's Wiki rein, um nachzulesen, was man in dem Fall tun muss)
• dass ich dem SSO-Server(provider) vertrauen muss - wird mein Account dort missbraucht oder ist deren System kompromittiert, dann hat derjenige einen Generalschlüssel für zahlreiche andere Systeme (die ohne SSO eigentlich getrennt wären)
• dass ich beiden Parteien auch vertrauen muss hinsichtlich Datenübertragung. Ein "Login mittels Google- oder Facebook-Konto" in z.B. ein Online-Spiel bedeutet automatisch, dass Google oder Facebook wissen, dass und wie oft und von wo ich dieses Online-Spiel nutze. Und umgekehrt, durch den Login mit meinem Google-Account erfährt der Online-Spiele-Anbieter meine öffentlichen Infos, die im Account hinterlegt sind (i.d.R. Name, Profilbild, Mailadresse).

Insbesondere der letzte Punkt ist z.B. der Grund, warum ich persönlich niemals "netID" als angeblich neutralen SSO-Dienst nutzen würde, wenn man sich mal anguckt, wer dahinter steht.

Ein anderes großes Thema der letzten Jahre ist die Mehr-Faktor-Authentisierung: Neben dem Passwort ist bei immer mehr Systemen (im Banken-Umfeld ist das teilweise vorgeschrieben) ein Einmal-Code (SMS, pushTAN-App, ...) nötig. Bevor ich das klären, sollten wir kurz einen Blick auf die Begriffe werfen:

• Im Deutschen gibt es die Authentisierung, die Authentifizierung und die Autorisierung.
• Authentisierung ist der Vorgang aus Anwendersicht: Er legt seine (authentischen) Dokumente/Passwörter/... vor, um Zugang zu bekommen.
• Authentifizierung ist der Vorgang aus der anderen Seite: Er prüft die vorgelegten Dokumente auf Richtigkeit/Echtheit
• Und die Autorisierung kommt danach, das ist die Befugnis, auf irgendwelche Systeme zuzugreifen (weil die vorherige Authentifizierung erfolgreich war).
• Im Englischen gibt es nur die Authentication (bezeichnet sowohl den Vorgang des Ausweisens, als auch den der Prüfung des Ausweisens) und danach der Authorization.

Im Englischen heißt das Ding Two-factor-authentication bzw. Multi-factor-authentication. Die richtige deutsche Übersetzung zwei Zwei-/Multi-Faktor-Authentisierung (weil man ja zwei Sachen vorlegt: Passwort und Code). Aber umgekehrt, der Server prüft ja auch beides, darum ist es m.E. auch völlig in Ordnung, von Zwei-Faktor-Authentifizierung zu reden. Und um es nicht selbst immer versehentlich zu mische, bleiben wir bei der Abkürzung 2FA bzw. MFA.

Zurück zum eigentlichen Thema:

Um Zugang zu irgend einem (z.B. IT-)System zu gelangen, braucht man ein oder mehrere Dinge. Diese unterteilt man in verschiedene Kategorien:

• etwas, was man hat. Klassischerweise z.B. der eigene Hausschlüssel. Aber auch ein Token (Schlüsselanhänger, der irgendwelche Codes errechnet und anzeigt) oder eine Chipkarte oder ein bestimmten Smartphone.
• etwas, was man weiß. Klassischerweise ein Passwort, aber auch Sicherheitsabfragen (Name des ersten Haustieres der ersten Freundin oder so)
• jemand, der man ist. Gerne durch Biometrie (Fingerabdruck) nachgewiesen.

Innerhalb jeder Kategorie kann man unterschiedliche Sicherheit haben, sagen wir mal auf einer Skala von 1 bis 10. Ein zu einfaches Passwort oder der "Mädchenname der Mutter" wäre vielleicht nur eine 1, ebenso wie eine Magnetkarte (lässt sich einfach kopieren) oder z.B. eine FaceID/WindowsHello/...-Prüfung, die sich durch ein 3D-gewölbtes Foto austricken lässt. 

Ein sehr sicheres Passwort oder eine App, die alle 30 Sekunden eine neue kryptografische Zufallszahl errechnet haben vielleicht eine 10 als Sicherheit.

Bei MFA nimmt man jetzt mehrere dieser Kategorien zusammen. Dadurch - vereinfacht gesagt - multipliziert sich die SIcherheit (heißt ja schließlich Faktor). Der Klassiker seit Jahrzehnten ist die ec-Karte ("etwas, was man hat") mit der PIN ("etwas, was man weiß"). Beides sagen wir mal eine 7 (die vierstellige PIN ist zwar nicht super-sicher, aber man hat nur drei Versuche. Und der Magentstreifen hat längst ausgedient, mit Chip sind die Karten ja im Prinzip nicht kopierbar). Damit kommen wir jetzt auf 7*7, also schon ein Sicherheitsniveau von 49. 

Wer sich noch an Eurocheckes erinnern kann: Da hatte man den Scheck (Sicherheitsniveau 2, spätestens seit "Catch me if you can" wissen wir, dass man sich die selbst drucken kann) plus die ec-Karte, die dazu vorgelegt werden musste (Sicherheitsniveau 3, denn die Karte wurde ja nich eingelesen, sondern nur visuell geprüft). Und bei größeren Beträgen hat sich er Händler auch noch den Ausweis zeigen lassen - Sicherheitsniveau sagen wir mal 4, zwar sind Ausweise schwer zu fälschen, aber sie wurden nur stichprobenartig und nur oberflächlich geprüft). Aber: Scheck und Karte sind beides aus der Kategorie "etwas, was man hat", die mulitplizieren sich nicht, die addieren sich nur auf zusammen 5. Der Ausweis hingegen fällt in die Kategorie "jemand, der man ist" (es ging ja nicht darum, einen Ausweis zu haben, sondern es war ja eine Identitätsprüfung), also 5*4, wäre dann Sicherheitsniveau von 20. In dieser (zugegeben stark vereinfachten und nach bauchgefühl bewerteten) Skala ist die Kombination aus heutiger Bankkarte + PIN deutlich sicherer als die frühere Kombi Karte+Scheck+Ausweis. 

Entscheidend ist aber: Die Sicherheit steigt durch die Zunahme eines weiteren Faktors enorm, viel mehr, als man sie innerhalb der gleichen Kategorie absichern könnte. Also ein einfaches Passwort verbunden mit einem Code, der über einen anderen Übertragungsweg (SMS, E-Mail oder Errechnung auf z.B. dem Smartphone) ist erheblich sicherer als ein richtig gut ausgedachtes Passwort (das aber, wenn es jemand in die Hände bekommt, ohne weiteres Zutun funktioniert).

Die bisherigen Beispiele waren dann auch alle 2FA, die beliebteste Form von MFA. Reine Mathematik, bei drei Faktoren (Passwort + Einmal-Code + Biometrie) würde das Sicherheitsniveau sich ja nochmal multiplizieren - für den normalen Hausgebrauch aber völlig unnötig bei zu viel Komfortverlust.

Die Grenzen zwischen den Kategorien sind dabei fließend. Wenn ich auf meinem Smartphone meine Onlinebanking-Zugangsdaten speichere ("etwas, was man weiß") und auf das gleiche Gerät die pushTAN-App installiere ("etwas, was man hat"), dann mache ich mir einen Faktor kaputt (denn dann genügt das Smartphone ja). Andersherum, beide Apps erfordern den Fingerabdruck, damit nehme ich "jemand der ich bin" direkt wieder dazu.

Und auch ein Einmalpasswort, das mir per Mail geschickt wird, kann man je nach Betrachtungsweise als "etwas, was ich habe" (=Zugriff auf mein Mailprogramm) oder "jemand, der ich bin" (=Empfänger meiner personenbezogenen Mail-Adresse) oder auch nur als "etwas, das ich weiß" (Zugangsdaten Mailaccount reichen aus, um an das Einmalpasswort zu kommen) einstufen.

Das ist dann auch eigentlich der einzige Nachteil dieser Technologie: Dass die Grenzen zwischen den Kategorien nicht immer starr sind und ggf. das in der Theorie hohe Sicherheitsniveau in der Praxis geringer ausfällt.