Auf einen Blick
- Authentisierung = "Wer bist du?" (Identität behaupten). Authentifizierung = "Du bist es." (Prüfung durch die Gegenseite).
- Drei Faktoren: Wissen (Passwort) – Besitz (Token, Karte) – Sein (Biometrie). Mehrere zusammen ergeben MFA/2FA.
- Challenge-Response: Server sendet Zufall $c$, Client antwortet mit $r = f(c, k)$. Schützt vor Replay, weil $c$ jedes Mal neu ist.
- Moderne Standards: Kerberos (Tickets, KDC), PAKE/SRP (PW nie im Klartext), FIDO2/WebAuthn (passwortlos), OAuth 2.0 / OIDC (Third-Party-Delegation).
- Klausur-Kern: Zusammenhang zwischen Nonce, Freshness und Replay-Schutz; Passwort-Entropie berechnen; sichere Speicherung mit Salt + KDF (bcrypt, Argon2).
Kernkonzepte
1. Authentisierung vs. Authentifizierung vs. Autorisierung
| Begriff | Wer tut es? | Frage |
|---|---|---|
| Authentisierung | Nutzer | "Ich bin XY." – Identitätsbehauptung + Nachweis |
| Authentifizierung | System | "Stimmt das?" – Prüfung des Nachweises |
| Autorisierung | System | "Was darfst du?" – Rechtevergabe nach erfolgreicher Auth. |
Die drei Begriffe werden in der Praxis oft gemischt. Klausur: klar trennen.
2. Die drei Authentisierungsfaktoren
- Wissen – etwas, das nur der Nutzer weiß: Passwort, PIN, Antwort auf Sicherheitsfrage.
- Besitz – etwas, das nur der Nutzer hat: Smartcard, YubiKey, TOTP-App auf dem Handy, SMS-Code.
- Sein / Inhärenz – etwas, das der Nutzer ist: Fingerabdruck, Iris, Gesicht, Stimme.
Ein weiterer, oft genannter Faktor: Ort (Standort, IP-Range) und Verhalten (Tipprhythmus).
2FA / MFA: mindestens zwei unabhängige Faktoren – ein Passwort und eine zweite Passphrase reicht nicht, weil beides Wissen ist.
3. Challenge-Response-Verfahren
Grundidee: Der Client soll beweisen, dass er ein Geheimnis $k$ kennt, ohne $k$ selbst zu übertragen.
Server Client |------- c (random) ----------->| | r = f(c, k) |<------ r ---------------------| prüft: f(c, k) == r ?
$f$ muss eine Einwegfunktion mit Schlüsselabhängigkeit sein. Klassisch: HMAC-SHA256, früher HMAC-MD5.
Warum kein Replay? Weil $c$ bei jeder Sitzung neu und zufällig ist, ist auch $r$ jedes Mal anders. Ein Angreifer, der ein altes $(c, r)$ mitgeschnitten hat, kann damit nichts anfangen, weil der Server ein neues $c'$ sendet.
4. Kerberos (grob)
Ticket-basiertes Authentisierungssystem für verteilte Netzwerke (MIT, in Windows-AD verbreitet). Kern: das KDC (Key Distribution Center) mit zwei Rollen:
- AS – Authentication Server: prüft initiales Login, gibt TGT (Ticket-Granting Ticket) aus.
- TGS – Ticket-Granting Server: gibt Service-Tickets für konkrete Dienste aus.
Ablauf sehr vereinfacht:
1. Client → AS: "Ich bin Alice" 2. AS → Client: TGT (verschl. mit KDC-Key) + Session-Key (verschl. mit Alice' PW-Hash) 3. Client → TGS: TGT + Wunsch "will an Dienst XY" 4. TGS → Client: Service-Ticket + neuer Session-Key für Dienst XY 5. Client → Dienst: Service-Ticket + Authenticator
Vorteil: Passwort geht nie über die Leitung, Session-Keys sind kurzlebig, jeder Dienst hat einen eigenen Schlüssel. Nachteil: KDC ist Single Point of Trust und Failure; Uhren müssen synchron sein (Timestamps gegen Replay).
5. PAKE / SRP – Password-Authenticated Key Exchange
Bei einfachem Login sendet der Client das Passwort (oder einen Hash) an den Server – der sieht es potenziell im Klartext. PAKE löst das:
- Server speichert nur einen Verifier $v = g^{H(salt \| pw)} \bmod N$.
- Client und Server tauschen zufällige Werte $A$ und $B$ aus, jeder berechnet lokal den gleichen Sitzungsschlüssel $K$.
- Der Server erfährt das Passwort nie, auch nicht kurzzeitig.
Beispiel: SRP-6a. Auch OPAQUE, SPAKE2.
6. FIDO2 / WebAuthn
Passwortlose Authentisierung mit einem Hardware-Authenticator (YubiKey, TPM, Face ID/Touch ID + Secure Enclave).
- Bei der Registrierung erzeugt der Authenticator ein Schlüsselpaar $(sk, pk)$. $pk$ geht an den Server, $sk$ verlässt das Gerät nie.
- Login = Challenge-Response mit Signatur: Server sendet Zufall $c$, Authenticator signiert $c$ mit $sk$, Server verifiziert mit $pk$.
- Origin-Binding: Der Browser bindet die Signatur an die Domain – schützt gegen Phishing.
7. OAuth 2.0 und OpenID Connect
- OAuth 2.0 – Autorisierungs-Framework: Nutzer erlaubt einer App den Zugriff auf Ressourcen bei einem Provider, ohne sein Passwort an die App zu geben. Ergebnis: ein Access Token.
- OpenID Connect (OIDC) – Erweiterung von OAuth 2.0 um Authentisierung. Zusätzlich zum Access Token gibt es ein ID Token (JWT), das die Identität des Nutzers bezeugt.
Typischer Flow (Authorization Code Flow mit PKCE):
App → IdP: Redirect zum Login, mit code_challenge Nutzer: loggt sich beim IdP ein IdP → App: Auth-Code (per Redirect) App → IdP: Code + code_verifier → Access Token + ID Token
8. Replay-Angriffe und ihre Abwehr
Ein Replay-Angriff zeichnet eine gültige Nachricht auf (z. B. "überweise 100 €" oder das Ergebnis $r$ einer Challenge-Response) und spielt sie später erneut ein, um die gleiche Aktion nochmal auszulösen.
Gegenmaßnahmen:
- Nonce – frischer Zufallswert pro Sitzung/Nachricht.
- Timestamp – Zeitstempel plus Toleranzfenster (z. B. ±5 min). Erfordert synchrone Uhren.
- Session-ID / Sequenznummer – laufende Nummer, jede darf nur einmal vorkommen.
- Kombination: Kerberos etwa nutzt Timestamp + Nonce + Session-Key.
Merksätze
🧮 Rechenaufgaben mit Lösung
Klick auf eine Aufgabe, um den vollständigen Lösungsweg zu sehen.
Aufgabe 1 – Challenge-Response mit MD5
Analyse Schritt für Schritt
Schritt 1 – Grundstruktur: Server $\to c$, Client antwortet mit $r = f(c, k)$. Das ist das klassische Challenge-Response-Schema. Solange $c$ pro Anfrage frisch (Nonce) ist, ist das Grundprinzip korrekt.
Schritt 2 – Konkatenation prüfen: $c \,\|\, k$ hängt Bytes einfach hintereinander. Bei variabler Länge entsteht das Problem, dass "42" $\|$ "17" nicht eindeutig von "4" $\|$ "217" unterscheidbar ist. Bei fester Byte-Länge ist das ok, bei String-Konkat ohne Trennzeichen aber gefährlich.
Schritt 3 – MD5 bewerten: MD5 ist seit 2004 kollisionsanfällig (Wang et al.), seit 2008 sind auch Chosen-Prefix-Kollisionen praktisch. Für Authentisierung ist MD5 gebrochen.
Schritt 4 – Length-Extension: MD5, SHA-1 und SHA-2 sind Merkle-Damgård-Konstruktionen und anfällig für Length-Extension-Angriffe: aus $\mathrm{MD5}(k \,\|\, m)$ kann ein Angreifer $\mathrm{MD5}(k \,\|\, m \,\|\, m')$ berechnen, ohne $k$ zu kennen. Deshalb ist "Hash über konkateniertes Geheimnis" grundsätzlich falsch.
Empfehlung
| Problem | Fix |
|---|---|
| MD5 gebrochen | SHA-256 oder besser SHA-3 verwenden |
| Length-Extension | Statt Hash($k \| c$) besser HMAC-Konstruktion |
| Kein Nonce garantiert | $c$ muss echt zufällig und mind. 128 Bit sein |
Konkret: $r = \mathrm{HMAC\text{-}SHA256}(k, c)$.
Grundidee ok, konkrete Umsetzung mit MD5 unsicher. Ersetzen durch HMAC-SHA256.Aufgabe 2 – Wie viele Bit für eine sichere Nonce?
Geburtstagsproblem
Schritt 1: Bei einem Zufallsraum der Größe $N = 2^n$ tritt eine Kollision (zwei gleiche Nonces) mit hoher Wahrscheinlichkeit nach etwa $\sqrt{N} = 2^{n/2}$ Ziehungen auf (Birthday Bound).
Schritt 2 – für $n = 64$ Bit: $\sqrt{2^{64}} = 2^{32} \approx 4{,}29 \cdot 10^{9}$. Nach ca. 4 Milliarden Sitzungen droht Kollision. Zu wenig für große Systeme.
Schritt 3 – für $n = 128$ Bit: $\sqrt{2^{128}} = 2^{64} \approx 1{,}84 \cdot 10^{19}$. Erst nach $\approx 1{,}8 \cdot 10^{19}$ Nonces wird Kollision wahrscheinlich. Bei $10^{12}$ Anfragen ist $\Pr[\text{Kollision}] \approx \frac{(10^{12})^2}{2 \cdot 2^{128}} \approx 1{,}5 \cdot 10^{-15}$ – vernachlässigbar.
Schritt 4 – für $n = 96$ Bit (z. B. GCM-IV): $\sqrt{2^{96}} = 2^{48} \approx 2{,}8 \cdot 10^{14}$. Für die meisten Anwendungen genug, aber für Massen-Server-Verkehr grenzwertig.
Empfehlung: mindestens 128 Bit Nonce → Kollision erst bei ca. $2^{64}$ Anfragen kritisch.Aufgabe 3 – Passwort-Entropie
Rechenschritte
Schritt 1 – Alphabetgröße: $|\Sigma| = 26 + 10 = 36$.
Schritt 2 – Anzahl Kombinationen: $$36^8 = ?$$
| Rechenschritt | Wert |
|---|---|
| $36^2$ | $1\,296$ |
| $36^4 = 1296^2$ | $1\,679\,616$ |
| $36^8 = (36^4)^2$ | $2\,821\,109\,907\,456 \approx 2{,}82 \cdot 10^{12}$ |
Schritt 3 – Entropie in Bit: $$H = \log_2(36^8) = 8 \cdot \log_2(36).$$ Mit $\log_2(36) = \log_2(4 \cdot 9) = 2 + 2\log_2 3 \approx 2 + 2 \cdot 1{,}585 = 5{,}170.$ Also $H \approx 8 \cdot 5{,}170 \approx 41{,}4$ Bit.
Schritt 4 – Bewertung: 41 Bit sind für Offline-Angriffe zu wenig. Eine moderne GPU-Farm probiert $\sim 10^{10}$ SHA-256/s. $2{,}82 \cdot 10^{12} / 10^{10} = 282$ Sekunden – unter 5 Minuten Brute-Force. Mit bcrypt (Cost 12) sind es aber ca. $10^{4}$ Hashes/s → $2{,}82 \cdot 10^{8}$ s $\approx$ 9 Jahre; deshalb: langsame KDF.
$36^8 \approx 2{,}82 \cdot 10^{12}$ Kombinationen, ≈ 41 Bit Entropie. Zu wenig ohne langsame KDF.Aufgabe 4 – bcrypt-Speicherformat
bcrypt-Format
Schritt 1 – Aufbau: bcrypt liefert einen 60-Zeichen-String im Modular-Crypt-Format:
$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW | | | |________________________|________________________| | | | Salt (22 Zeichen) Hash (31 Zeichen) | | Cost-Faktor (hier 12) | Version (2b = aktuelle bcrypt-Version) Prefix
Schritt 2 – Komponenten:
| Feld | Länge | Bedeutung |
|---|---|---|
| Version | 2 Zeichen | $2b$ = korrigierte bcrypt-Version |
| Cost | 2 Zeichen | Zahl 4..31, Anzahl Runden = $2^{\text{cost}}$ |
| Salt | 22 Zeichen | 128 Bit Zufallssalz, base64-kodiert |
| Hash | 31 Zeichen | 184 Bit Hash-Output, base64-kodiert |
Schritt 3 – Cost-Faktor: Cost 12 heißt $2^{12} = 4\,096$ Runden Blowfish-basierter Key-Schedule. Die Rechenzeit verdoppelt sich mit jedem Cost-Schritt. Empfehlung 2026: Cost $\geq 12$, besser 13-14.
Schritt 4 – Warum reicht "nur Hash" nicht? Salt verhindert Rainbow Tables (jedes PW hat einen eigenen Salt, präkomputierte Tables funktionieren nicht). Der hohe Cost-Faktor verlangsamt Brute-Force massiv.
60-Zeichen-String: $2b$Cost$Salt(22) + Hash(31). Cost bestimmt Runden = $2^{\text{cost}}$.Aufgabe 5 – Bruteforce eines 4-stelligen PIN
Rechenschritte
Schritt 1 – Kombinationen: $10^4 = 10\,000$ mögliche PINs (0000 bis 9999).
Schritt 2 – Erwartungswert: Im Mittel wird der PIN nach $\frac{10\,000}{2} = 5\,000$ Versuchen gefunden, im Worst-Case nach 10 000.
Schritt 3 – Fall (a), ohne Limit: 1 ms pro Versuch.
| Fall | Versuche | Zeit |
|---|---|---|
| Mittel | 5 000 | 5 000 ms = 5 s |
| Worst-Case | 10 000 | 10 s |
Schritt 4 – Fall (b), 3 Versuche/Minute: Rate $= 3/60 = 0{,}05$ Versuche pro Sekunde $= 4\,320$ Versuche pro Tag.
| Fall | Versuche | Zeit |
|---|---|---|
| Mittel | 5 000 | $5000/4320 \approx 1{,}16$ Tage |
| Worst-Case | 10 000 | $10000/4320 \approx 2{,}31$ Tage |
Schritt 5 – Praxis: iOS und Android koppeln Rate-Limit mit exponentiell steigenden Sperrzeiten und einer harten Grenze (z. B. 10 Fehlversuche → Wipe). Damit wird selbst ein 4-stelliger PIN unpraktikabel für Angreifer.
Ohne Limit: ~5 s im Mittel. Mit 3/min: ~1-2 Tage. Rate-Limiting macht den Unterschied, nicht die PIN-Länge allein.Aufgabe 6 – HMAC vs. Hash-Konkatenation
Length-Extension-Angriff
Schritt 1 – Setting: Angreifer kennt $H(k \| c)$ (weil er es abhört), aber nicht $k$. Ziel: einen gültigen Response $H(k \| c \| c')$ für eine neue Challenge $c'$ berechnen.
Schritt 2 – Merkle-Damgård-Konstruktion: Hashes wie MD5, SHA-1, SHA-256 verarbeiten Nachrichten in festen Blöcken und geben nach jedem Block einen Zwischenzustand aus. Der finale Output = letzter Zwischenzustand.
Schritt 3 – Angriff: Der Angreifer nimmt $H(k \| c)$ als neuen Startzustand, hängt Padding + $c'$ an und berechnet $H(k \| c \| \text{pad} \| c')$. Das Ergebnis ist ein gültiger Hash über eine erweiterte Nachricht – ohne $k$ zu kennen.
Schritt 4 – HMAC schützt: HMAC ist definiert als $$\mathrm{HMAC}_k(m) = H\big((k \oplus \text{opad}) \,\|\, H((k \oplus \text{ipad}) \,\|\, m)\big).$$ Der zweite Hash-Aufruf "kapselt" den ersten – Length-Extension ist wirkungslos, weil der Angreifer den äußeren Hash nicht weiterführen kann, ohne $k$ zu kennen.
Naive Konkatenation ist anfällig für Length-Extension; HMAC durch doppeltes Hashing sicher.Übungsfragen
F1Was ist der Unterschied zwischen Authentisierung und Autorisierung?
Authentisierung beantwortet "Wer bist du?" und wird durch eine Authentifizierung vom System geprüft (Passwort korrekt? Token gültig?).
Autorisierung beantwortet danach "Was darfst du?" – also welche Ressourcen und Aktionen der jetzt identifizierte Nutzer verwenden darf. Autorisierung setzt eine erfolgreiche Authentifizierung voraus, aber nicht umgekehrt.
Beispiel: Login am Server = Authentisierung + Authentifizierung. "Alice darf /admin sehen, Bob nicht" = Autorisierung.
F2Was sind die drei Authentisierungsfaktoren?
- Wissen: Passwort, PIN, Passphrase, Antwort auf Sicherheitsfrage.
- Besitz: Smartphone mit TOTP-App, YubiKey, Smartcard, Bankkarte.
- Sein / Inhärenz: biometrische Merkmale wie Fingerabdruck, Gesichts- oder Iriserkennung, Stimme.
Weitere, seltener genannte Faktoren: Ort (Geolokation, Netzwerk) und Verhalten (Tipprhythmus, Mausbewegung).
Multi-Faktor-Authentisierung (MFA) verlangt Nachweise aus unterschiedlichen Kategorien.
F3Wie funktioniert Challenge-Response und wovor schützt es?
Der Server sendet dem Client einen frischen Zufallswert $c$ (Challenge/Nonce). Der Client berechnet $r = f(c, k)$ mit einer schlüsselabhängigen Einwegfunktion (typisch HMAC-SHA256) und einem gemeinsamen Geheimnis $k$. Der Server prüft, ob $f(c, k)$ mit dem empfangenen $r$ übereinstimmt.
Vorteile:
- Das Geheimnis $k$ verlässt nie die beiden Endpunkte.
- Weil $c$ jedes Mal neu ist, ist auch $r$ jedes Mal anders → Schutz vor Replay-Angriffen.
Voraussetzung: $c$ muss unvorhersehbar und ausreichend groß sein (mind. 128 Bit).
F4Was ist ein Replay-Angriff?
Ein Angreifer zeichnet eine gültige, authentifizierte Nachricht ab (z. B. "Login-Token", "überweise 100 €") und spielt sie später erneut ein, um die Aktion nochmal auszulösen. Er muss dabei den Inhalt nicht verstehen oder entschlüsseln.
Gegenmaßnahmen:
- Nonce pro Sitzung – Server merkt sich, welche schon verwendet wurden.
- Timestamp mit Toleranzfenster – nur aktuelle Nachrichten akzeptieren.
- Sequenznummer in einer Session.
- TLS bietet all das automatisch auf Transportebene.
F5Was ist der Vorteil von FIDO2 gegenüber Passwörtern?
- Kein gemeinsames Geheimnis auf dem Server: der Server hat nur den öffentlichen Schlüssel. Ein DB-Leak nützt dem Angreifer nichts.
- Phishing-resistent: der Authenticator bindet die Signatur an die Origin (Domain). Eine Phishing-Seite mit anderer Domain bekommt keine gültige Signatur.
- Kein Merken, kein Tippen, keine Wiederverwendung – jedes Konto hat ein eigenes Schlüsselpaar.
- Zweiter Faktor "eingebaut": der User-Presence-/User-Verification-Check (Touch, PIN, Biometrie) am Authenticator ist bereits ein zweiter Faktor.
- Kein Passwort im Klartext, kein Brute-Force gegen Server möglich.
F6Warum ist reines Passwort-Hashen ohne Salt unsicher gegen Rainbow Tables?
Eine Rainbow Table ist eine vorberechnete Tabelle von (Passwort, Hash)-Paaren für eine gewählte Hashfunktion. Ist ein reiner Hash gespeichert (z. B. $\mathrm{SHA256}(\text{"Passwort123"})$), kann der Angreifer die Tabelle direkt konsultieren und das Klartext-Passwort ablesen.
Mit einem pro-Nutzer zufälligen Salt hashen wir $\mathrm{SHA256}(\text{salt} \| \text{Passwort})$. Damit müsste der Angreifer für jeden Salt eine eigene Rainbow Table bauen – unpraktikabel.
Zusätzlich sollte man eine langsame KDF (bcrypt, scrypt, Argon2) verwenden, damit jeder einzelne Versuch teuer ist – Salt allein reicht bei billigen Hashes nicht, weil dann Brute-Force pro Nutzer möglich wird.
F7Was ist ein Session-Cookie und was ist eine sichere Cookie-Konfiguration?
Ein Session-Cookie ist ein vom Server gesetzter Cookie, der eine zufällige Session-ID enthält. Der Server speichert im Backend die zugehörige Sitzung (User, Rechte, Ablauf) und identifiziert den Nutzer bei jedem Request per Cookie.
Sichere Konfiguration:
Secure– nur über HTTPS.HttpOnly– für JavaScript unlesbar (Schutz vor XSS-Diebstahl).SameSite=StrictoderLax– Schutz gegen CSRF.__Host--Prefix – zwingt Path=/, Secure, kein Domain-Attribut.- Kurze Lebensdauer, Rotation bei Login/Rechtewechsel.
- Session-ID mind. 128 Bit Entropie, kryptographisch zufällig.
F8Wie funktioniert Kerberos (grob)?
Kerberos ist ein Ticket-basiertes Authentisierungssystem. Zentrale Komponente ist das KDC (Key Distribution Center) mit zwei Diensten: AS (Authentication Server) und TGS (Ticket-Granting Server).
- Client sendet Login-Anfrage an AS.
- AS antwortet mit einem TGT (Ticket-Granting Ticket, verschlüsselt mit KDC-Schlüssel) und einem Session-Key (verschlüsselt mit Passwort-abgeleitetem Client-Key).
- Client will Dienst XY nutzen → sendet TGT an TGS und fragt nach Service-Ticket.
- TGS gibt ein Service-Ticket + neuen Session-Key aus, verschlüsselt mit dem Schlüssel des Zieldiensts.
- Client präsentiert das Service-Ticket dem Dienst; der Dienst entschlüsselt es, kennt die Identität und den Session-Key und antwortet.
Vorteile: Single Sign-On, Passwort geht nie über die Leitung, Session-Keys sind kurzlebig. Nachteile: KDC = Single Point of Failure, Zeitsynchronisation notwendig (Timestamps gegen Replay).
F9Warum ist SMS-2FA schwächer als App-basierte oder Hardware-2FA?
- SIM-Swapping: Angreifer überzeugt Mobilfunkanbieter, die Nummer auf eine neue SIM zu portieren.
- SS7-Angriffe: Schwachstellen im Mobilfunk-Signalisierungsprotokoll erlauben SMS-Umleitung.
- Kein Origin-Binding: Der Nutzer tippt den Code auch auf einer Phishing-Seite ein.
- TOTP-Apps: mind. Origin-freies Shared Secret ohne Netzwerkübertragung. Hardware-Token (FIDO2): Origin-Binding + physisches Gerät.
SMS-2FA ist dennoch besser als gar keine 2FA – aber für hochsensible Konten sollte FIDO2 verwendet werden.
F10Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?
OAuth 2.0 ist ein Framework für Autorisierung: Der Nutzer erlaubt einer Anwendung (Client) Zugriff auf Ressourcen bei einem Provider (Resource Server), ohne sein Passwort herzugeben. Ergebnis: Access Token.
OpenID Connect ist eine Erweiterung von OAuth 2.0, die zusätzlich Authentisierung liefert. Der Identity Provider gibt ein ID Token (JWT) aus, das die Identität des Nutzers signiert bezeugt (sub, iss, aud, exp, nonce, …).
Merksatz: OAuth = "Darf die App etwas tun?" – OIDC = "Wer ist der Nutzer?".
F11Was ist eine Nonce, und warum reicht in Kerberos ein Zeitstempel oft?
Eine Nonce ("number used once") ist ein Wert, der pro Sitzung/Nachricht nur einmal verwendet wird. Zwei Ausprägungen:
- Zufalls-Nonce: kryptographischer Zufall, mind. 128 Bit.
- Counter/Timestamp: monoton wachsender Wert.
In Kerberos arbeitet der Authenticator mit Timestamps: der Client stempelt seine Anfrage mit der aktuellen Uhrzeit, verschlüsselt mit dem Session-Key. Der Server akzeptiert nur Nachrichten innerhalb eines Toleranzfensters (z. B. ±5 Minuten). Nachrichten außerhalb oder Duplikate gelten als Replay. Voraussetzung: alle Uhren sind hinreichend synchron (NTP).
F12Warum ist "Sicherheitsfrage" (z. B. Mädchenname der Mutter) ein schwacher zweiter Faktor?
- Immer noch Faktor Wissen – keine echte 2FA.
- Antworten sind oft öffentlich recherchierbar (Social Media, öffentliche Register).
- Wenige Antwortmöglichkeiten pro Frage – Brute-Force / Guessing einfach.
- Wird bei einem Datenleck praktisch nie rotiert.
Empfehlung: keine Sicherheitsfragen; stattdessen echte 2FA (TOTP-App, FIDO2). Falls unvermeidbar: als Passwort behandeln, mit Zufalls-Antworten füllen und im Passwort-Manager speichern.