Authentifizierung und Identität
Nachdem wir die Verbindung zwischen Browser und Server abgesichert haben, stellt sich die nächste Frage: Wer darf überhaupt auf die Webanwendung zugreifen?
Authentifizierungsverfahren und Identitätsmanagement kennst du bereits aus Modul B4. Hier konzentrieren wir uns darauf, wie du diese Konzepte in einer Webanwendung praktisch umsetzt und absicherst.
„Unsere Webanwendungen sind durch ein Login geschützt und wer sein Passwort nicht kennt, kommt nicht rein. Was brauchen wir noch?“
„Jetzt geht es darum, wie sicher wir Multi-Faktor-Authentifizierung (MFA) und andere Schutzmechanismen in einer Webanwendung implementieren und was dabei schiefgehen kann.“
💡 Authentifizierung in Webanwendungen bedeutet insbesondere: Nicht nur ob du eine Authentifizierung einsetzt, sondern auch wie du sie implementierst und absicherst, entscheidet über die Sicherheit.
MFA-Implementierung in Webanwendungen
Für Webanwendungen ist entscheidend, wie MFA (Multi Faktor Authentifizierung) implementiert wird. Als Entwickler oder Administrator musst du den richtigen zweiten Faktor für deine Anwendung wählen:
- FIDO2/WebAuthn: Das ist die sicherste Wahl. FIDO2 (Fast Identity Online) ist ein offener Standard, WebAuthn (Web Authentication) ist die Browser-API dafür. Der Schlüssel ist kryptografisch an die Domain gebunden, was diesen Faktor phishing-resistenter macht, weil er auf einer gefälschten Website schlicht nicht funktioniert. In der Praxis wird FIDO2 häufig über Hardware-Tokens wie einen YubiKey umgesetzt: Der Benutzer steckt den USB-Stick ein (oder hält ihn an das NFC-Lesegerät des Smartphones) und bestätigt per Knopfdruck. Die NovaHealth könnte beispielsweise allen Mitarbeitern mit Zugriff auf das Patientenportal einen YubiKey ausgeben. Damit wäre ein Phishing-Angriff auf den zweiten Faktor praktisch ausgeschlossen.
- TOTP: TOTP (Time-based One-Time Password) generiert zeitbasierte Einmalpasswörter, z.B. über Apps wie Google Authenticator oder Authy. Dies ist ein guter Kompromiss aus Sicherheit und Benutzerfreundlichkeit. Achte darauf, dass die TOTP-Secrets serverseitig sicher gespeichert und bei der Einrichtung nur einmal angezeigt werden.
- Push-Verfahren: Bei Anmeldung wird nach erfolgreicher Eingabe der Credentials eine Bestätigung über eine App angefordert. Diese kann über Number Matching oder zusätzlichem Kontext zusätzlich abgesichert werden.
- SMS: Sollte vermieden werden. SIM-Swapping (ein Angreifer übernimmt die Telefonnummer beim Mobilfunkanbieter) und Schwachstellen im SS7-Protokoll (dem Signalisierungsprotokoll der Mobilfunknetze) machen diesen Kanal angreifbar.
✅ Faustregel: Bevorzuge phishing-resistente MFA-Verfahren wie FIDO2/WebAuthn. TOTP und moderne Push-Verfahren bieten einen guten Schutz, sind aber grundsätzlich weiterhin durch Phishing angreifbar. SMS sollte wegen zusätzlicher Risiken wie SIM-Swapping und Angriffen auf die Mobilfunkinfrastruktur nur eingesetzt werden, wenn stärkere Verfahren nicht zur Verfügung stehen.
Je höher der Schutzbedarf, desto stärker und insbesondere phishing-resistenter sollte das eingesetzte Authentifizierungsverfahren sein.
Starke Passwort-Hash-Algorithmen
Auch das stärkste Passwort muss in einer Form gespeichert werden, die es der Webanwendung ermöglicht, es beim Login zu prüfen. Dieser Ort ist in der Regel eine Datenbank. Wird diese Datenbank kompromittiert (und Datenbankleaks passieren regelmäßig, auch bei großen Unternehmen wie z. B. LinkedIn, Adobe oder Dropbox), hängt alles davon ab, wie die Passwörter gespeichert wurden.
Im Klartext? Hoffentlich nicht, das wäre in jedem IT-Sicherheitsaudit ein kritisches Finding. Denn dann hat ein Angreifer sofort Zugriff auf alle Passwörter. Als einfacher Hash? Auch problematisch: Ohne Salt helfen vorberechnete Tabellen, schnelle Hashverfahren ermöglichen zudem massive Offline-Angriffe. Deshalb sind ein individueller Salt und ein sicheres, zeitgemäßes Passwort-Hashverfahren keine theoretische Frage, sondern die letzte Verteidigungslinie.
Passwörter dürfen niemals im Klartext gespeichert werden. Auch einfache Hashes (MD5, SHA-1) reichen nicht, da sie mittlerweile zu schnell berechenbar sind. Sichere Algorithmen sind aktuell:
- bcrypt: Bewährt, mit konfigurierbarem Kostenfaktor (Work Factor). Der Kostenfaktor bestimmt, wie viele Runden der Algorithmus intern dreht. Je höher, desto langsamer die Berechnung. Das ist gewollt: Für einen normalen Login sind ein paar hundert Millisekunden kein Problem, aber ein Angreifer, der Millionen oder sogar Milliarden Kombinationen durchprobiert, wird massiv ausgebremst.
- Argon2: Gewinner der Password Hashing Competition (2015), gilt als modernster Standard. Berücksichtigt neben CPU-Zeit auch Speicherverbrauch, was insbesondere GPU-basierte Brute-Force-Angriffe erschwert: GPUs haben in der Regel viele Kerne, aber wenig Speicher pro Kern.
- scrypt: Ähnlich wie Argon2, ebenfalls speicherhungrig. Wird u.a. in einigen Kryptowährungen eingesetzt.
Jedes Passwort sollte mit einem einzigartigen Salt (Zufallswert) gehasht werden. Der Salt wird vor dem Hashen an das Passwort angehängt und zusammen mit dem Hash gespeichert. Warum? Ohne Salt erzeugen identische Passwörter auch identische Hashes und ein Angreifer könnte anhand der Hashes erkennen, welche Benutzer dasselbe Passwort verwenden. Mit Salt ist jeder Hash einzigartig, selbst wenn das Passwort identisch ist.
💡 Um zu erkennen, um welchen Hash-Algorithmus es sich höchstwahrscheinlich handelt, können Tools wie hash-identifier genutzt werden. Es ist in Kali Linux verfügbar. Online kann zum Beispiel die folgende Website genutzt werden: https://hashes.com/en/tools/hash_identifier
Rate Limiting für Login
Brute-Force-Angriffe auf Login-Seiten sind alltäglich. Jeden Tag werden automatisiert Millionen von Benutzername-Passwort-Kombinationen gegen Webanwendungen getestet. Das passiert zum Beispiel oft mit Zugangsdaten aus früheren Datenlecks (sogenanntes Credential Stuffing). Ohne Rate Limiting kann ein Angreifer in wenigen Minuten tausende Kombinationen und bekannte Passwörter durchprobieren. Gute Gegenmaßnahmen sind vorallem:
- Exponentielles Backoff: Nach jedem Fehlversuch verdoppelt sich die Wartezeit
- Account Lockout: Nach N Fehlversuchen wird das Konto temporär gesperrt (Vorsicht: Das kann auch für DoS missbraucht werden, der Einsatz kommt also ganz auf die Anwendung an)
- CAPTCHA nach Fehlversuchen: Nach 3-5 Fehlversuchen wird ein CAPTCHA eingeblendet. Auch direkt bei jedem Login möglich.
- IP-basiertes Rate Limiting: Zu viele Anfragen von einer IP werden gedrosselt. Das kann zwar umgangen werden, ist aber in der Praxis für die meisten Angreifer eher umständlich und daher oftmals bereits ein wirksamer Schutz
⚠️ Achtung: Brute-Force-Schutz für den zweiten Faktor nicht vergessen! Ein häufig übersehenes Problem ist, dass ein TOTP-Code nur sechs Ziffern lang ist. Das sind gerade einmal 1.000.000 mögliche Kombinationen. Ohne Schutzmaßnahmen kann ein Angreifer, der bereits das Passwort kennt, den 2FA-Code innerhalb von Sekunden durchprobieren. Deshalb muss auch der Token-Verifizierungsendpunkt abgesichert werden:
- Strikte Versuchsbegrenzung: Maximal 3-5 Fehlversuche für die Token-Eingabe, danach wird die MFA-Verifizierung temporär gesperrt
- Zeitfenster begrenzen: Ein TOTP-Code ist typischerweise 30 Sekunden gültig. Das System sollte maximal den aktuellen und den vorherigen Code akzeptieren (um Uhrenabweichungen auszugleichen), aber nicht mehr
- Logging und Alerting: Fehlgeschlagene 2FA-Versuche sollten protokolliert werden und bei ungewöhnlich vielen Versuchen einen Alarm auslösen, denn das deutet unmittelbar auf einen gezielten Angriff hin
OAuth2 und OpenID Connect
OAuth2 und OpenID Connect kennst du aus Modul B4. Zur Erinnerung: OAuth2 regelt die Autorisierung (welche Ressourcen darf eine App nutzen?), OIDC ergänzt die Authentifizierung (wer ist der Benutzer?). In der Praxis nutzt du OIDC, wenn du z.B. „Mit Google anmelden“ oder „Mit Microsoft anmelden“ in deiner Webanwendung anbietest.
Für die NovaHealth bedeutet das konkret: Statt eine eigene Benutzerverwaltung mit Passwort-Reset, MFA-Enrollment und Account-Sperren zu bauen, könnten die Verantwortlichen die Authentifizierung an einen Identity Provider wie Microsoft Entra ID delegieren und sich letztendlich dadurch auf die Entwicklung und Administration der eigentlichen Anwendung konzentrieren. Es gibt Argumente für und gegen eine solche Delegierung.
Session Management
Nach einer erfolgreichen Authentifizierung muss die Webanwendung den Benutzer wiedererkennen, weshalb Sessions verwendet werden. Unsicheres Session Management ist eine der häufigsten Schwachstellen in Webanwendungen.
„Was kann denn an einer Session unsicher sein? Da ist ein Nutzer doch hoffentlich schon sicher eingeloggt.“
„Leider eine ganze Menge. Wenn die Session-ID vorhersagbar ist, kann ein Angreifer sie erraten. Wenn sie nach dem Login nicht erneuert wird, kann er eine vorbereitete Session unterschieben. Und wenn sie ewig gültig bleibt, hat ein Angreifer beliebig viel Zeit, sie zu stehlen.“
- Session-IDs: Müssen kryptografisch zufällig, ausreichend lang (mindestens 128 Bit Entropie) und nicht vorhersagbar sein. In der Praxis solltest du, wenn möglich, den Session-Mechanismus deines Frameworks verwenden. Wenn du versuchst, eine eigene Session-ID-Generierung zu implementieren, kann viel schiefgehen.
- Session-Fixation verhindern: Nach einem erfolgreichen Login muss die Anwendung eine neue Session-ID vergeben. Sonst kann ein Angreifer einem Opfer eine vorbereitete Session-ID unterschieben und nach dem Login des Opfers dessen Session übernehmen. Das ist in der Praxis meist nicht ohne andere Schwachstellen ausnutzbar, bleibt aber ein Angriffsvektor, der einfach geschlossen werden kann.
- Session-Timeout: Setze sowohl einen Inaktivitäts-Timeout (z. B. 15-30 Minuten ohne Aktivität) als auch einen absoluten Timeout (z. B. 8 Stunden, danach ist erneutes Anmelden erforderlich, auch unabhängig von der Aktivität).
- Secure Session Storage: Session-Daten gehören auf den Server (serverseitiger Session Store), nicht komplett ins Cookie. Im Cookie steht nur die Session-ID mit den Flags
Secure,HttpOnlyundSameSite(siehe nächstes Thema „Schutz vor gängigen Webangriffen“). Wenn sensible Daten ins Cookie müssen, sollte es sicher verschlüsselt und signiert werden. Auch bei Verschlüsselung gilt: Daten aus dem Cookie kommen vom Nutzer und gelten daher eher nicht als vertrauenswürdig.
✅ Merke: Session Management heißt: Zufällige IDs, neue ID nach Login, Timeouts setzen, Daten serverseitig speichern.
Vereinfacht gesagt: Authentifizierung in Webanwendungen ist mehr als nur ein Login-Formular. Du brauchst:
- den richtigen zweiten Faktor,
- sichere Passwortspeicherung,
- Schutz gegen Brute-Force auf allen Endpunkten und
- ein sauberes Session Management.
Jede einzelne Schwachstelle in dieser Kette kann die gesamte Authentifizierung aushebeln.
Du bist dran: Schauen wir, ob du die Konzepte rund um Authentifizierung und Session Management in Webanwendungen verstanden hast. Beantworte die folgende Quizfrage: