Authentifizierung

KAPITEL 07 · IT-SICHERHEIT

Authentifizierung & Identitätsmanagement

Sichere Überprüfung von Identitäten im Enterprise-Umfeld. Lernen Sie MFA, SSO, OAuth 2.0, Kerberos, FIDO2/WebAuthn und Zero-Trust-Architekturen kennen – die Grundlage moderner IT-Sicherheit.

MFA & 2FA SSO & Federation OAuth 2.0 / OIDC FIDO2 / WebAuthn

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Authentifizierung im Enterprise-Umfeld:

  • Grundlagen: Authentifizierung vs. Autorisierung, AAA-Modell
  • Authentifizierungsfaktoren: Wissen, Besitz, Sein, Ort, Verhalten
  • MFA/2FA: Multi-Faktor-Authentifizierung im Detail
  • Protokolle: Kerberos, OAuth 2.0, SAML, OpenID Connect, FIDO2
  • SSO: Single Sign-On und Identity Federation
  • Best Practices: Passwortrichtlinien, Zero Trust, Monitoring
  • FAQ: Häufige Fragen und Troubleshooting

1. Was ist Authentifizierung?

Definition

Authentifizierung ist der Prozess der Überprüfung der Identität eines Benutzers, Systems oder Dienstes. Sie beantwortet die Frage: "Bist du wirklich, wer du behauptest zu sein?"

Im Gegensatz zur Autorisierung (die fragt: "Was darfst du tun?") geht es bei der Authentifizierung ausschließlich um die Identitätsfeststellung. Beide Prozesse sind Teil des AAA-Modells:

  • Authentication: Wer bist du? (Identitätsprüfung)
  • Authorization: Was darfst du? (Berechtigungsprüfung)
  • Accounting: Was hast du getan? (Protokollierung/Audit)

Beispiel: Sie loggen sich mit Benutzername und Passwort ein (Authentifizierung). Das System prüft dann, ob Sie auf bestimmte Dateien zugreifen dürfen (Autorisierung). Alle Zugriffe werden protokolliert (Accounting).

Warum ist starke Authentifizierung wichtig?

  • Schutz vor Identitätsdiebstahl: Gestohlene Passwörter reichen nicht aus
  • Compliance: DSGVO, ISO 27001, BSI IT-Grundschutz verlangen starke Authentifizierung
  • Zero Trust: "Never trust, always verify" – jede Anfrage muss authentifiziert werden
  • Remote Work: Sichere Anmeldung von überall
  • Cloud-Sicherheit: Schutz von Cloud-Ressourcen und SaaS-Anwendungen

2. Die 5 Authentifizierungsfaktoren

Authentifizierung basiert auf fünf Kategorien von Faktoren. Je mehr Faktoren kombiniert werden, desto sicherer ist die Authentifizierung.

Wissen

Something you know

Informationen, die nur der berechtigte Benutzer kennt. Der klassische Faktor, aber allein nicht ausreichend.

  • Passwort / PIN
  • Sicherheitsfragen
  • Muster / Gesten
  • Passphrase
Sicherheitsniveau: Niedrig bis Mittel – kann vergessen, erraten oder gestohlen werden

Besitz

Something you have

Physische Objekte oder Geräte, die der Benutzer besitzt. Schwerer zu stehlen als Wissen.

  • Smartphone (TOTP-App)
  • Hardware-Token (YubiKey)
  • Smartcard / Chipkarte
  • Sicherheitsschlüssel (FIDO2)
Sicherheitsniveau: Hoch – physischer Zugriff erforderlich

Sein

Something you are

Biometrische Merkmale, die eindeutig zum Benutzer gehören. Sehr sicher, aber datenschutzrelevant.

  • Fingerabdruck
  • Gesichtserkennung (Face ID)
  • Iris-Scan
  • Stimmerkennung
Sicherheitsniveau: Sehr hoch – einzigartig, aber nicht änderbar bei Kompromittierung

Ort

Somewhere you are

Standortbasierte Authentifizierung. Wird oft als zusätzlicher Kontextfaktor verwendet.

  • GPS-Standort
  • IP-Adresse / Geolocation
  • WLAN-Netzwerk
  • VPN-Verbindung
Sicherheitsniveau: Mittel – kann manipuliert werden (VPN, Proxy), aber guter Kontextfaktor

Verhalten

Something you do

Verhaltensbiometrie analysiert typische Nutzungsmuster. Kontinuierliche Authentifizierung.

  • Tippverhalten (Keystroke Dynamics)
  • Mausbewegungen
  • Nutzungsgewohnheiten
  • Gerät-Nutzungsmuster
Sicherheitsniveau: Hoch – kontinuierlich, schwer zu imitieren, aber komplex in der Implementierung

Multi-Faktor-Authentifizierung (MFA)

MFA kombiniert mindestens zwei verschiedene Faktoren aus unterschiedlichen Kategorien. Beispiel:

  • 2FA (Two-Factor): Passwort (Wissen) + TOTP-App (Besitz)
  • 3FA: Passwort (Wissen) + YubiKey (Besitz) + Fingerabdruck (Sein)
  • Adaptive MFA: Risikobasierte Entscheidung basierend auf Ort, Gerät, Verhalten

Wichtig: Zwei Faktoren aus der gleichen Kategorie (z.B. Passwort + PIN) gelten nicht als echte MFA!

3. MFA-Methoden im Vergleich

Nicht alle MFA-Methoden bieten das gleiche Sicherheitsniveau. Hier ein Vergleich der gängigsten Methoden:

Methode Sicherheit Benutzerfreundlichkeit Phishing-resistent Kosten Einsatzgebiet
SMS-TAN Niedrig Hoch Nein Mittel Consumer, Legacy
E-Mail-Code Niedrig Hoch Nein Gering Consumer, Backup
TOTP-App (Google Auth) Mittel Mittel Nein Gering Enterprise, Consumer
Push-Benachrichtigung Mittel-Hoch Hoch Teilweise Mittel Enterprise
Hardware-Token (YubiKey) Sehr hoch Mittel Ja Hoch High-Security, Admin
FIDO2 / WebAuthn Sehr hoch Hoch Ja Mittel-Hoch Modern Enterprise, Passwordless
Biometrie (Face/Finger) Hoch Sehr hoch Teilweise Gering (Device) Consumer, Mobile

Empfehlung für Enterprise

  • Standard-Benutzer: TOTP-App oder Push-Benachrichtigung
  • Administratoren: FIDO2/WebAuthn oder Hardware-Token (YubiKey)
  • Passwordless: FIDO2 + Biometrie (Windows Hello, Apple Face ID)
  • Vermeiden: SMS-TAN (SIM-Swapping-Risiko) und E-Mail-Codes (Phishing)

4. Authentifizierungsprotokolle

Verschiedene Protokolle regeln, wie Authentifizierung technisch umgesetzt wird. Jedes hat spezifische Stärken und Einsatzgebiete.

Kerberos

Ticket-basiert · Active Directory

Das Standard-Protokoll für Windows-Domains. Verwendet Tickets statt Passwörter im Netzwerk.

  • Ticket-Granting-Ticket (TGT)
  • Service Tickets für Ressourcen
  • Gegenseitige Authentifizierung
  • Keine Passwort-Übertragung
Einsatz: Active Directory, Windows-Domains, Enterprise-Intranets

OAuth 2.0

Autorisierungs-Framework

Framework für delegierte Autorisierung. Ermöglicht Drittanbieter-Zugriff ohne Passwort-Weitergabe.

  • Access Tokens (JWT)
  • Refresh Tokens
  • Scopes (Berechtigungen)
  • Grant Types (Authorization Code, etc.)
Einsatz: API-Zugriff, Social Login, Mobile Apps, Microservices

SAML 2.0

XML-basiert · Enterprise SSO

XML-basierter Standard für Single Sign-On im Enterprise-Umfeld. Weit verbreitet in Legacy-Systemen.

  • SAML Assertions (XML)
  • Identity Provider (IdP)
  • Service Provider (SP)
  • Browser-basierte Redirects
Einsatz: Enterprise SSO, Legacy-Webanwendungen, VPN

OpenID Connect (OIDC)

Identity Layer auf OAuth 2.0

Erweiterung von OAuth 2.0 um Authentifizierung. Moderner Standard für Web- und Mobile-Apps.

  • ID Token (JWT, signiert)
  • UserInfo Endpoint
  • Discovery Document
  • Kompatibel mit OAuth 2.0
Einsatz: Moderne Web-Apps, Mobile Apps, Cloud-Dienste, API-Gateways

FIDO2 / WebAuthn

Passwordless · Phishing-resistent

Modernster Standard für passwortlose Authentifizierung. Nutzt Public-Key-Kryptographie und Hardware-Token.

  • Public/Private Key-Paar
  • Platform Authenticator (Biometrie)
  • Roaming Authenticator (YubiKey)
  • Vollständig phishing-resistent
Einsatz: Passwordless Login, High-Security, Admin-Accounts, Zero Trust

NTLM

Legacy · Veraltet

Veraltetes Microsoft-Protokoll. Anfällig für Relay-Angriffe und sollte deaktiviert werden.

  • Challenge-Response
  • Hash-basiert (NT-Hash)
  • Anfällig für Relay-Angriffe
  • Kein gegenseitiges Auth
Status: DEPRECATED – Nur noch für Legacy-Kompatibilität, Migration zu Kerberos empfohlen

5. Single Sign-On (SSO) – Wie funktioniert es?

Single Sign-On ermöglicht es Benutzern, sich einmal anzumelden und dann auf mehrere Anwendungen zuzugreifen, ohne sich erneut authentifizieren zu müssen.

SSO-Ablauf (vereinfacht)

1
Benutzer greift auf App A zu

Benutzer ist nicht angemeldet → App leitet zum Identity Provider (IdP) weiter

2
Authentifizierung am IdP

Benutzer gibt Credentials am IdP ein (z.B. Azure AD, Okta, Keycloak)

3
Token wird ausgestellt

IdP erstellt signiertes Token (SAML Assertion / OIDC ID Token) und sendet es an App A

4
App A validiert Token

App prüft Signatur und gewährt Zugriff. Benutzer ist nun bei App A angemeldet.

5
Benutzer greift auf App B zu

App B leitet zum IdP weiter → IdP erkennt bestehende Session → stellt neues Token aus

6
Automatische Anmeldung bei App B

App B validiert Token → Benutzer ist automatisch angemeldet (keine erneute Eingabe!)

Vorteile von SSO

  • Benutzerkomfort: Nur ein Login für alle Anwendungen
  • Sicherheit: Zentrale Kontrolle, schnelle Sperrung bei Kompromittierung
  • Admin-Effizienz: Zentrale Benutzerverwaltung, weniger Passwort-Resets
  • Compliance: Zentrale Audit-Logs, einheitliche Richtlinien
  • Onboarding/Offboarding: Schnelle Aktivierung/Deaktivierung aller Zugriffe

6. Best Practices für Authentifizierung

MFA erzwingen

  • MFA für alle Benutzer, besonders Admins
  • Phishing-resistente Methoden bevorzugen (FIDO2)
  • SMS-TAN vermeiden (SIM-Swapping-Risiko)
  • Adaptive MFA: Risikobasierte Entscheidungen
  • Backup-Codes für Notfall-Wiederherstellung

Passwortrichtlinien

  • Mindestlänge: 12+ Zeichen (NIST-Empfehlung)
  • Keine komplexen Regeln (führen zu schwachen Passwörtern)
  • Passwort-Manager fördern (Bitwarden, KeePass)
  • Breached-Password-Check (Have I Been Pwned API)
  • Keine regelmäßigen Resets (nur bei Verdacht)

Monitoring & Alerting

  • Alle Auth-Versuche loggen (erfolgreich + fehlgeschlagen)
  • Alerting bei ungewöhnlichen Mustern (Geo, Zeit, Device)
  • Brute-Force-Erkennung und Account-Lockout
  • SIEM-Integration für zentrale Analyse
  • Regelmäßige Review von Auth-Logs

Zero Trust Prinzipien

  • "Never trust, always verify"
  • Jede Anfrage authentifizieren (auch intern)
  • Least Privilege: Minimal notwendige Rechte
  • Kontinuierliche Validierung (nicht nur beim Login)
  • Device Compliance prüfen (Patch-Level, Antivirus)

NIST-Empfehlungen (SP 800-63B)

  • Passwortlänge: Mindestens 8 Zeichen, besser 12+
  • Keine Komplexitätsregeln: Keine Sonderzeichen-Pflicht (führt zu vorhersehbaren Mustern)
  • Keine regelmäßigen Resets: Nur bei Verdacht auf Kompromittierung
  • Breached-Password-Check: Prüfen gegen bekannte Leaks
  • MFA: Immer aktivieren, bevorzugt phishing-resistente Methoden
  • Rate Limiting: Brute-Force-Schutz implementieren

7. FAQ – Häufige Fragen & Antworten

Häufige Fragen zur Authentifizierung

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?

Authentifizierung prüft die Identität: "Wer bist du?" (z.B. Login mit Passwort + MFA).

Autorisierung prüft die Berechtigung: "Was darfst du tun?" (z.B. Zugriff auf bestimmte Dateien oder Funktionen).

Beispiel: Sie authentifizieren sich mit Ihrem Ausweis am Flughafen (Authentifizierung). Dann wird geprüft, ob Sie in die Business Lounge dürfen (Autorisierung).

Warum ist SMS-TAN unsicher?

SMS-TAN ist anfällig für mehrere Angriffsvektoren:

  • SIM-Swapping: Angreifer übernehmen Ihre Telefonnummer durch Social Engineering beim Mobilfunkanbieter
  • SS7-Angriffe: Schwachstellen im Mobilfunkprotokoll ermöglichen Abhören von SMS
  • Malware: Trojaner auf dem Smartphone können SMS abfangen
  • Keine Verschlüsselung: SMS werden unverschlüsselt übertragen

Empfehlung: Nutzen Sie stattdessen TOTP-Apps (Google Authenticator, Microsoft Authenticator) oder besser noch FIDO2/WebAuthn.

Was ist FIDO2/WebAuthn und warum ist es besser als TOTP?

FIDO2/WebAuthn ist ein moderner Standard für passwortlose Authentifizierung, der Public-Key-Kryptographie nutzt:

  • Phishing-resistent: Der Private Key verlässt nie das Gerät (Hardware-Token oder Biometrie)
  • Domain-gebunden: Der Key ist an die spezifische Domain gebunden – funktioniert nicht auf Phishing-Seiten
  • Keine Shared Secrets: Kein gemeinsames Geheimnis zwischen Server und Client (wie bei TOTP)
  • Passwordless: Kann komplett ohne Passwort genutzt werden

Unterschied zu TOTP: TOTP nutzt ein zeitbasiertes Einmalpasswort, das theoretisch abgefangen werden kann. FIDO2 nutzt asymmetrische Kryptographie und ist damit deutlich sicherer.

Wie funktioniert Single Sign-On (SSO)?

SSO ermöglicht es, sich einmal anzumelden und dann auf mehrere Anwendungen zuzugreifen:

  1. Benutzer greift auf App A zu → wird zum Identity Provider (IdP) weitergeleitet
  2. Benutzer authentifiziert sich am IdP (einmalig)
  3. IdP stellt ein signiertes Token aus (SAML/OIDC) und sendet es an App A
  4. App A validiert das Token und gewährt Zugriff
  5. Bei Zugriff auf App B: IdP erkennt bestehende Session → stellt neues Token aus → automatische Anmeldung

Vorteile: Nur ein Login, zentrale Kontrolle, einfachere Administration.

Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?

OAuth 2.0 ist ein Autorisierungs-Framework – es regelt, wie Drittanbieter Zugriff auf Ressourcen erhalten, ohne das Passwort zu kennen. Es sagt nichts über die Identität des Benutzers aus.

OpenID Connect (OIDC) ist eine Erweiterung von OAuth 2.0 um eine Authentifizierungsschicht. Es fügt ein ID Token (JWT) hinzu, das die Identität des Benutzers bestätigt.

Einfach gesagt: OAuth 2.0 = "Darf diese App auf meine Daten zugreifen?" | OIDC = "Wer ist der Benutzer?"

Wie oft sollten Passwörter geändert werden?

Nicht regelmäßig! Die aktuelle NIST-Empfehlung (SP 800-63B) rät von regelmäßigen Passwort-Resets ab, da sie zu schwächeren Passwörtern führen (Benutzer wählen einfache Variationen).

Stattdessen:

  • Passwörter nur bei Verdacht auf Kompromittierung ändern
  • Breached-Password-Check implementieren (gegen bekannte Leaks prüfen)
  • MFA erzwingen (macht Passwort-Änderungen weniger kritisch)
  • Passwort-Manager fördern (ermöglicht starke, einzigartige Passwörter)
Was ist Adaptive MFA / Risk-Based Authentication?

Adaptive MFA passt die Authentifizierungsanforderungen dynamisch an das Risiko an:

  • Niedriges Risiko: Bekannter Ort, bekanntes Gerät, normale Uhrzeit → nur Passwort oder kein MFA
  • Mittleres Risiko: Neues Gerät, anderer Ort → TOTP oder Push-Benachrichtigung
  • Hohes Risiko: Ungewöhnlicher Ort, verdächtige Uhrzeit, Tor-Netzwerk → FIDO2 + zusätzliche Verifikation

Vorteil: Bessere Balance zwischen Sicherheit und Benutzerkomfort. Normale Benutzer werden nicht unnötig belastet, risikoreiche Anmeldungen werden streng geprüft.

Wie schützt man Administrator-Accounts besonders?

Administrator-Accounts benötigen besonderen Schutz:

  • Phishing-resistente MFA: FIDO2/WebAuthn oder Hardware-Token (YubiKey) – keine TOTP/SMS
  • Privileged Access Workstations (PAW): Dedizierte Admin-PCs, kein Internet, kein E-Mail
  • Just-in-Time-Access: Admin-Rechte nur temporär gewähren (z.B. via PAM-Lösungen)
  • Getrennte Accounts: Separater Admin-Account, kein Daily-Use-Account mit Admin-Rechten
  • Monitoring: Alle Admin-Aktivitäten loggen und alerten
  • Regular Reviews: Regelmäßige Überprüfung der Admin-Berechtigungen

Zusammenfassung

Die wichtigsten Punkte

  • Authentifizierung: Überprüfung der Identität ("Wer bist du?") – Teil des AAA-Modells
  • 5 Faktoren: Wissen, Besitz, Sein, Ort, Verhalten – MFA kombiniert mindestens 2 verschiedene
  • MFA-Methoden: FIDO2/WebAuthn > Hardware-Token > Push > TOTP > SMS/E-Mail (vermeiden!)
  • Protokolle: Kerberos (AD), OAuth 2.0 (APIs), SAML (Legacy SSO), OIDC (Modern SSO), FIDO2 (Passwordless)
  • SSO: Einmal anmelden, überall Zugriff – zentrale Kontrolle und Komfort
  • Best Practices: MFA erzwingen, NIST-Richtlinien folgen, Zero Trust, Monitoring
  • Admin-Schutz: Phishing-resistente MFA, PAWs, Just-in-Time-Access

Enterprise-Empfehlungen

  • Standard-Benutzer: OIDC + TOTP/Push-MFA
  • Administratoren: FIDO2/WebAuthn + Hardware-Token + PAW
  • Passwordless: FIDO2 + Biometrie (Windows Hello, Apple Face ID)
  • Legacy-Systeme: SAML für alte Web-Apps, Kerberos für Windows-Domains
  • APIs/Microservices: OAuth 2.0 + JWT
  • Vermeiden: NTLM (deprecated), SMS-TAN, E-Mail-Codes

Weiterführende Themen

Kryptographie

Verschlüsselung, Hashing, digitale Signaturen – die Grundlagen der sicheren Authentifizierung.

Zur Kryptographie
Netzwerksicherheit

Firewalls, VPN, IDS/IPS – wie Authentifizierung im Netzwerk integriert wird.

Zur Netzwerksicherheit
Zero Trust

Zero Trust Architecture – "Never trust, always verify" im modernen Enterprise.

Zu Zero Trust
Identity & Access Management

IAM-Systeme, Active Directory, Azure AD – zentrale Identitätsverwaltung.

Zu IAM