Tag 9: Authentifizierung & Zugriffssicherheit

Grundbegriffe · häufige Prüfungsfalle

Authentifizierung vs. Autorisierung vs. Authentisierung

Die drei Begriffe werden in der Prüfung oft verwechselt oder synonym verwendet – das ist falsch. Hier die saubere Abgrenzung:

🪪 Authentisierung

Wer behauptet? Der Nutzer.

Der Vorgang, bei dem ein Nutzer seine Identität behauptet / nachweist – z.B. Benutzernamen + Passwort eingibt.

Beispiel: Nutzer tippt Zugangsdaten ein.

🔑 Authentifizierung

Wer überprüft? Das System.

Der Vorgang, bei dem das System die behauptete Identität verifiziert – also prüft, ob jemand wirklich der ist, der er vorgibt zu sein.

Beispiel: Server prüft Passwort-Hash gegen Datenbank.

✅ Autorisierung

Was darf wer? Rechtevergabe.

Nach erfolgreicher Authentifizierung wird geprüft, welche Ressourcen und Aktionen dem Nutzer erlaubt sind.

Beispiel: User darf Dateien lesen, aber nicht schreiben.

💡 Merkhilfe: Authentisierung = Nutzer stellt sich vor · Authentifizierung = System überprüft die Vorstellung · Autorisierung = System erteilt Rechte

Die drei Faktoren der Authentifizierung

Womit kann man sich ausweisen?

🧠

Wissen (Knowledge)

Etwas, das nur der Nutzer kennt. Einfach zu implementieren, aber verlierbar oder erraten.

Passwort PIN Sicherheitsfrage Muster (Pattern)

📱

Besitz (Possession)

Etwas, das der Nutzer physisch besitzt. Sicherer, aber verlierbar oder gestohlen werden.

Smartphone (TOTP-App) Smartcard / Chipkarte Hardware-Token (YubiKey) TAN-Generator

👁️

Inhärenz / Sein (Inherence)

Etwas, das der Nutzer ist – biometrische Merkmale. Sehr sicher, aber datenschutzrechtlich heikel (DSGVO: besondere Datenkategorie nach Art. 9).

Fingerabdruck Gesichtserkennung Iris-Scan Stimmerkennung

Merkhilfe: AAA-Framework

In der Netzwerkwelt steht AAA für das Gesamtkonzept der Zugangskontrolle:

Authentication – Wer bist du? (Identität prüfen)
Authorization – Was darfst du? (Rechte prüfen)
Accounting / Auditing – Was hast du getan? (Protokollierung für Nachvollziehbarkeit und Forensik)

Protokoll, das AAA umsetzt: RADIUS (→ Tab „RADIUS & Zertifikate")

BSI-Empfehlung Mindestlänge

≥ 12 Zeichen

für normale Accounts; kritische Systeme ≥ 20 Zeichen

Passwort-Entropie steigt durch

Länge > Komplexität

Lange Passphrasen sind stärker als kurze Sonderzeichen-Kombinationen

BSI TR-02102 & NIST SP 800-63B (aktuell)

Passwortrichtlinien im Überblick

Pflicht Mindestlänge: ≥ 8 Zeichen (Minimum), BSI empfiehlt ≥ 12, für privilegierte Accounts ≥ 20 Zeichen

Pflicht Zeichenvielfalt: Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen – mindestens 3 von 4 Kategorien

Pflicht Kein Default-Passwort: Initialpasswörter müssen beim ersten Login geändert werden (z.B. Router-Admin)

Pflicht Speicherung als Hash: Passwörter dürfen nie im Klartext gespeichert werden – nur als gesalzener Hash (bcrypt, Argon2, PBKDF2)

Empfohlen Passwort-History: Die letzten 5–10 Passwörter nicht wiederverwenden dürfen (verhindert Cycling)

Empfohlen Wechselintervall: Früher Pflicht alle 90 Tage – aktuell (NIST/BSI) nur noch bei Kompromittierungsverdacht. Zu häufiger Wechsel führt zu schwachen Passwörtern.

Empfohlen Account-Sperrung: Nach 3–10 Fehlversuchen temporäre Sperrung (Brute-Force-Schutz); Lockout-Policy

Verboten Schwache Passwörter: „Password1!", Namen, Geburtsdaten, Wörterbuchwörter – sollten durch Blocklisten ausgeschlossen sein

Passphrase vs. Passwort

Warum Passphrases besser sind

Eine Passphrase besteht aus mehreren zufälligen Wörtern (z.B. Apfel-Traktor-Nebel-42). Sie ist:

Länger → höhere Entropie (Bits of Randomness)
Merkbarer → geringere Notizzettel-Gefahr
Resistent gegen Brute-Force durch schiere Länge

Ein 20-Zeichen-Passphrase aus 4 zufälligen Wörtern ist sicherer als ein 8-Zeichen-Passwort mit erzwungenen Sonderzeichen.

💡 Prüfungs-Tipp: Den Begriff „Entropie" im Kontext Passwörter erklären können: Entropie = Maß für Unvorhersagbarkeit, gemessen in Bit. Mehr Entropie = sicherer.

Technische Maßnahmen

Passwort-Manager & weitere Kontrollen

Passwort-Manager: Erlaubt unique, komplexe Passwörter pro Dienst – empfohlen von BSI. Zentralisiertes Risiko muss durch starkes Master-Passwort + MFA abgesichert werden.
Have I Been Pwned / Credential-Checking: Prüfung neuer Passwörter gegen bekannte Leak-Datenbanken (NIST empfiehlt dies).
CAPTCHA: Verhindert automatisierte Login-Versuche durch Bots.
Rate Limiting: Maximalanzahl Login-Versuche pro Zeitfenster.

Multi-Factor Authentication

Was ist MFA?

MFA (Multi-Faktor-Authentifizierung) erfordert den Nachweis von mindestens zwei verschiedenen Faktoren aus den Kategorien Wissen, Besitz und Inhärenz. Damit wird ein kompromittierter Faktor (z.B. gestohlenes Passwort) allein nicht ausreichend.

2FA (Zwei-Faktor): Häufigste Form – z.B. Passwort + SMS-Code
MFA (Multi-Faktor): Zwei oder mehr Faktoren – z.B. Smartcard + PIN + Fingerabdruck
Wichtig: Zwei Faktoren derselben Kategorie (z.B. zwei Passwörter) zählt nicht als MFA

💡 In der Prüfung oft gefragt: Warum ist SMS als 2FA schwächer als TOTP? → SIM-Swapping, SS7-Angriffe, kein Ende-zu-Ende-Schutz.

One-Time Password

OTP – Einmalpasswort-Verfahren

H

HOTP – HMAC-based OTP (RFC 4226)

Zählerbasiert: Jedes Mal, wenn ein OTP generiert wird, erhöht sich ein Zähler. Server und Client müssen synchron sein. Problem: Bei Desynchronisation können Codes ungültig werden.

Algorithmus: HMAC-SHA1(Secret, Counter) → 6-stelliger Code

T

TOTP – Time-based OTP (RFC 6238)

Zeitbasiert: Code ist nur für ein kurzes Zeitfenster gültig (typisch 30 Sekunden). Kein Zähler-Synchronisations-Problem. Basis für Google Authenticator, Microsoft Authenticator, Aegis, etc.

Algorithmus: HOTP(Secret, ⌊Unixzeit / 30⌋) → 6-stelliger Code

S

SMS-OTP / mTAN

Einmalcode per SMS. Einfach zu nutzen, aber unsicher: Anfällig für SIM-Swapping, SS7-Protokollangriffe, Malware auf dem Gerät. Von BSI und NIST nicht mehr als sicheres MFA eingestuft.

Moderne Verfahren

FIDO2 / WebAuthn & Push-MFA

FIDO2 / WebAuthn: Phishing-resistenter Standard. Nutzer authentifiziert sich per Hardware-Key (YubiKey) oder Gerät-Biometrie (Windows Hello, TouchID). Kein Passwort nötig. Gilt als aktuell sicherste Methode.
Push-Benachrichtigung: App auf Smartphone zeigt Login-Anfrage an – Nutzer bestätigt per Tipp. Beispiele: Microsoft Authenticator, Duo Security. Anfällig für MFA Fatigue (Nutzer bestätigt aus Versehen).
Backup-Codes: Einmalig generierte Codes für den Notfall, wenn der zweite Faktor nicht verfügbar ist. Sicher aufzubewahren.

Network Access Control

RADIUS – Remote Authentication Dial-In User Service

RADIUS ist ein Client-Server-Protokoll für zentralisierte Authentifizierung, Autorisierung und Accounting (AAA) in Netzwerken. Es ist der Standard für Netzwerkzugangskontrolle.

1

Supplicant (Client)

Das Endgerät, das Zugang zum Netzwerk möchte (z.B. Laptop, der sich mit WLAN verbindet).

2

Network Access Server / Authenticator

Der Switch, Access Point oder VPN-Concentrator. Er leitet die Zugangsdaten des Clients an den RADIUS-Server weiter und setzt die Entscheidung um.

3

RADIUS-Server

Prüft Credentials gegen eine Benutzerdatenbank (Active Directory, LDAP). Antwortet mit Access-Accept, Access-Reject oder Access-Challenge.

Port: UDP 1812 (Authentifizierung) · UDP 1813 (Accounting)

💡 Praxisbeispiel: 802.1X – Portbasierte Netzwerkzugangskontrolle. Gerät verbindet sich mit Switch-Port → Switch fragt RADIUS-Server → erst nach OK wird Port freigeschaltet. Standard in Unternehmensnetzen für WLAN und LAN.

Public-Key-Infrastruktur

Digitale Zertifikate & PKI

Ein digitales Zertifikat (X.509) bindet einen öffentlichen Schlüssel an eine Identität (Person, Server, Organisation) und wird von einer vertrauenswürdigen Stelle signiert.

Zertifikatsinhalt: Öffentlicher Schlüssel, Identität des Inhabers, Gültigkeitszeitraum, Aussteller (CA), digitale Signatur
CA (Certificate Authority): Vertrauensanker, der Zertifikate ausstellt und signiert (z.B. DigiCert, Let's Encrypt, unternehmenseigene CA)
Zertifikatskette: Root-CA → Intermediate-CA → End-Entity-Zertifikat. Browser prüft die gesamte Kette.
CRL / OCSP: Sperrliste (Certificate Revocation List) bzw. Online-Protokoll zum Prüfen ob Zertifikat widerrufen wurde

TLS/SSL Transport Layer Security Port 443 (HTTPS)

Nutzt Zertifikate zur Authentifizierung des Servers (und optional des Clients). Schützt Vertraulichkeit und Integrität der Übertragung.

S/MIME Secure E-Mail E-Mail-Verschlüsselung

Zertifikate für E-Mail-Signierung und -Verschlüsselung. Stellt Authentizität des Absenders und Vertraulichkeit sicher.

EAP-TLS Extensible Authentication Protocol 802.1X / RADIUS

Stärkste 802.1X-Methode: Client und Server authentifizieren sich gegenseitig über Zertifikate. Kein Passwort nötig.

Single Sign-On

Was ist SSO?

Single Sign-On ermöglicht es einem Nutzer, sich einmalig zu authentifizieren und danach auf mehrere Anwendungen und Dienste zuzugreifen – ohne sich erneut anmelden zu müssen.

Vorteil Nutzer: Weniger Passwörter, bessere Usability, weniger Passwort-Fatigue
Vorteil IT: Zentralisierte Verwaltung, einheitliche Passwortrichtlinie, schnelle Deaktivierung beim Mitarbeiteraustritt
Risiko: Single Point of Failure – kompromittiertes SSO-Konto gibt Zugang zu allen verbundenen Diensten → MFA zwingend erforderlich

Protokolle & Technologien

Wie wird SSO technisch umgesetzt?

SAML 2.0 Security Assertion Markup Language

XML-basiertes Protokoll für Web-SSO in Unternehmensumgebungen. Drei Rollen: Identity Provider (IdP) (stellt Assertions aus), Service Provider (SP) (vertraut dem IdP), User/Browser. Häufig bei Microsoft AD FS, Shibboleth, ADFS.

OAuth 2.0 Authorization Framework

Kein Authentifizierungsprotokoll, sondern ein Autorisierungsframework – delegiert Zugriffsrechte. „Login mit Google/GitHub" gibt einer App Zugang zu bestimmten Ressourcen, ohne das Passwort zu teilen. Token-basiert (Access Token, Refresh Token).

OpenID Connect OIDC – Authentifizierung über OAuth 2.0

Baut auf OAuth 2.0 auf und ergänzt es um Authentifizierung. Liefert ein ID-Token (JWT) mit Nutzerinformationen. Standard für moderne Web- und Mobile-SSO. Beispiele: „Login mit Google", Azure AD, Keycloak.

Kerberos Netzwerk-Authentifizierungsprotokoll

Ticket-basiertes SSO-Protokoll für interne Netzwerke. Basis von Windows Active Directory. Nutzer erhält nach Login ein Ticket Granting Ticket (TGT) vom Key Distribution Center (KDC), womit er Service Tickets für einzelne Dienste erhält – ohne erneute Passwort-Eingabe.

Port: UDP/TCP 88

💡 Prüfungs-Abgrenzung: OAuth 2.0 = Autorisierung (was darf die App?) · OpenID Connect = Authentifizierung (wer ist der Nutzer?) · SAML = Enterprise-SSO (XML, Browser-Redirect) · Kerberos = On-Premise Windows-Netzwerk

Ablauf SSO mit SAML (vereinfacht)

Schritt-für-Schritt: SAML-SSO

1

Nutzer ruft Service Provider (SP) auf

z.B. Jira, Salesforce, eine interne Web-App

2

SP leitet zum Identity Provider (IdP) weiter

z.B. Microsoft Azure AD, Okta, eigener ADFS-Server

3

Nutzer authentifiziert sich beim IdP

Einmaliges Login mit Passwort + MFA

4

IdP stellt SAML-Assertion aus

Signiertes XML-Dokument mit Benutzerattributen (Name, Rollen, Gültigkeit)

5

SP prüft Assertion & gewährt Zugang

Nutzer ist eingeloggt – ohne eigenes Passwort beim SP

Fortschritt

1. Ein Nutzer gibt seinen Benutzernamen und sein Passwort in ein Login-Formular ein. Welcher Vorgang findet dabei statt?

2. Welche Kombination stellt echte Multi-Faktor-Authentifizierung dar?

3. Was ist der Hauptunterschied zwischen TOTP und HOTP?

4. Welches Protokoll wird in Windows Active Directory für Single Sign-On intern verwendet?

5. Ein Unternehmen setzt 802.1X ein, damit sich Geräte erst nach erfolgreicher Prüfung mit dem Netzwerk verbinden dürfen. Welche Rolle übernimmt der RADIUS-Server dabei?

6. Was ist der wesentliche Unterschied zwischen OAuth 2.0 und OpenID Connect?

7. Welche BSI-Empfehlung zur Passwort-Wechselfrequenz gilt aktuell (Stand BSI-Grundschutz / NIST SP 800-63B)?