Im ersten Teil unserer Blogserie zum Thema Passwortsicherheit haben wir besprochen, wie Angreifer:innen Passwörter angreifen – sei es durch automatisiertes Raten (Brute-Force), Credential Stuffing oder den Zugriff auf geleakte Datenbanken. Zur Erinnerung: Alle Angriffe basieren letztlich auf Varianten des Durchprobierens. Besonders wichtig ist die Unterscheidung zwischen „Online-“ und „Offline“-Angriffen. Bei „Online“-Angriffen erfolgt der Angriff über das normale Login-Formular, bei „Offline“-Angriffen erhält der Angreifer (z. B. über ein Leak) Zugriff auf die Nutzerdatenbank, kann diese kopieren und anschließend lokal versuchen, Passwörter zu extrahieren.
In diesem zweiten Teil beleuchten wir nun, welche Schutzmaßnahmen Betreiber:innen von Online-Diensten ergreifen können – und sollten –, um solche Angriffe abzuwehren.
Wir empfehlen auch Nutzer:innen, diesen Artikel zu lesen, um einen umfassenden Überblick über das Thema zu erhalten.
Schutz vor Online-Angriffen: erkennen, begrenzen, ausbremsen
Online-Angriffe lassen sich technisch kaum vollständig verhindern, da man hierzu nur Zugriff auf das Login-Formular benötigt.
Man kann aber Maßnahmen etablieren, die diese so stark ausbremsen, dass sie nicht mehr praktikabel sind. Ein bewährter Ansatz: Login-Versuche limitieren. Kein echter Mensch wird sein Passwort 50 Mal innerhalb weniger Sekunden falsch eingeben – ein solches Verhalten ist ein klares Indiz für automatisierte Angriffe.
Es ist also sinnvoll, das Login-Formular auf solche Angriffsmuster hin zu überwachen. Mit dem reinen Überwachen ist es aber noch nicht getan: Sie müssen bei der Erkennung eines Angriffs auch etwas dagegen tun.
So könnten Sie das angegriffene Konto etwa nach zehn Fehlversuchen automatisch für eine Minute sperren, sodass selbst bei richtiger Passworteingabe kein Login mehr möglich ist. Eine derartige Sperrregelung bremst den Brute-Force-Angriff empfindlich aus, denn nun muss alle zehn Versuche eine Pause eingelegt werden, bevor der Angriff fortgesetzt werden kann.
Doch Vorsicht: Solche Sperrmechanismen können auch zum Denial-of-Service gegen legitime Nutzer:innen missbraucht werden, indem Angreifer die Sperre bewusst provozieren. Von zu langen Sperrzeiten ist also abzuraten. Die Balance zwischen Sicherheit und Nutzbarkeit ist hier entscheidend.
Weitere essentielle Schutzmaßnahmen betreffen die grundlegende Gestaltung Ihrer Authentisierungs- und Authentifizierungsprozesse:
- Verwenden Sie stets sichere Kanäle (z. B. HTTPS, abgesichert durch TLS), um Passwörter bei der Übertragung vor dem Auslesen durch Dritte zu schützen.
- Definieren Sie Passwortrichtlinien, die die Verwendung von sicheren Passwörtern erzwingen (mehr dazu weiter unten im Beitrag).
- Bieten Sie Multi-Faktor-Authentifizierung (MFA) mindestens als Option an – und machen Sie sie bei besonders sensiblen Anwendungen (z. B. im Finanz- oder Gesundheitssektor) zur Pflicht (mehr dazu in einem unserer nächsten Blog-Artikel).
Ergänzend empfehlen wir einen Blick in die folgenden OWASP Cheat Sheets:
Und was können Betreiber:innen gegen Offline-Angriffe tun?
Zuerst sollten Sie sicherstellen, dass es keine Schwachstellen gibt, über die Angreifer:innen Zugang auf ihre Nutzer:innen-Datenbank erlangen können. Doch selbst bei einem Leak müssen die gespeicherten Passwörter so abgesichert sein, dass sie nicht auslesbar sind.
Die Grundregel lautet deshalb: Speichern Sie die Passwörter Ihrer Nutzer:innen niemals im Klartext, ansonsten haben Angreifer:innen leichtes Spiel.
Wie speichert man Passwörter sicher?
Stattdessen gilt es, die Passwörter so abzulegen, dass Sie einerseits die eingegebenen Passwörter überprüfen können, andererseits aber niemand aus der Speicherung die Passwörter rekonstruieren kann. Das Mittel der Wahl sind hier kryptographische Hashfunktionen.
Diese Funktionen können beliebig große Daten auf kleine Bitstrings (z. B. 256 Bits) herunterrechnen, die „Hashwerte“ genannt werden. Hashfunktionen bringen folgende nützliche Eigenschaften zur Speicherung von Passwörtern mit sich:
- Sie sind deterministisch, d. h. wenn man das gleiche Passwort in die Hashfunktion eingibt, erhält man immer den gleichen Hashwert als Ergebnis.
- Es ist nicht effizient möglich, zwei verschiedene Passwörter zu finden, die den gleichen Hashwert erzeugen (Kollisionsresistenz).
- Hashfunktionen sind eine Unterart von sogenannten „Einweg-Funktionen“, die zwar leicht zu berechnen, aber nur sehr schwierig zurückzurechnen sind. Es ist also nicht effizient möglich, aus einem Hashwert die ursprüngliche Eingabe zu berechnen (hier also das Passwort).
Anstatt des Passworts würden Sie also dessen Hash in der Datenbank ablegen. Möchte sich jemand einloggen, nehmen Sie das Passwort entgegen, hashen es und vergleichen es mit dem abgelegten Hash. Ist dieser identisch, so wissen Sie aufgrund der Kollisionsresistenz, dass das richtige Passwort eingegeben wurde. Gleichzeitig kann niemand aus dem Hashwert das Passwort effizient zurückrechnen. Aber reicht Hashing allein schon aus?
Nun, die Einweg-Eigenschaft ist technisch nur dann gegeben, wenn die Eingaben (hier aktuell die Passwörter) auch möglichst lang und zufällig sind. Menschen wählen für gewöhnlich keine 1.000 Zeichen langen Passwörter und sind auch keine guten Zufallsgeneratoren. Wir müssen dafür sorgen, dass die Eingabewerte (hier aktuell nur die Passwörter) lang und möglichst zufällig werden. Sonst ist das Zurückrechnen einfach, egal wie gut die Hashfunktion ist. Das können wir erreichen, indem wir nicht nur das Passwort hashen, sondern bei der Registrierung einen langen String zufällig wählen und „mithashen“. Dieser wird „Salt“ genannt. Anstatt nur das Passwort zu hashen, wird der Salt an das Passwort angehängt und der daraus entstehende Gesamtwert gehasht. Der Salt macht das Passwort also zusätzlich länger und „zufälliger“. Der Salt wird dann (im Klartext) in der Datenbank abgelegt. Das sorgt beispielsweise dafür, dass bei zwei Nutzer:innen, die zufällig das gleiche Passwort verwenden, dennoch unterschiedliche Hashes in der Datenbank stehen. Diese Speicherart verhindert auch andere fortgeschrittene Angriffstechniken.
Allerdings schützt auch dies nicht vor der Wahl schlechter Passwörter. Können die Nutzer:innen simple Passwörter wie „passwort1234“ verwenden, kann man als Angreifer:in auch schnell herausfinden, ob sich im Hash „passwort1234“ versteckt, indem man einfach den Hash davon und von dem gespeicherten Salt berechnet. Wir müssen die Nutzer:innen also in gewisser Weise vor sich selbst schützen. Das können wir tun, indem wir gute Passwörter erzwingen (mehr dazu gleich).
Darüber hinaus sind noch andere technische Faktoren entscheidend, beispielsweise die Wahl der Hashfunktion für diesen Zweck oder die Verwendung eines zusätzlichen geheimen Werts, eines sogenannten „Peppers“ (ähnlich wie ein Salt, allerdings deutlich länger; für alle Passwörter wird derselbe Pepper verwendet und dieser wird außerhalb der Datenbank in einem sicheren Speicherbereich abgelegt).
Weitere Empfehlungen zu sicherer Passwort-Speicherung finden sich im OWASP Password Storage Prevention Cheat Sheet.
Gute Passwortrichtlinien sind das A und O
Ein häufiger Fehler: Betreiber:innen setzen Passwortrichtlinien um, die Nutzer:innen eher behindern als schützen – z. B. durch eine künstliche Begrenzung der Passwortlänge.
Unsere Empfehlungen:
- Fokus auf Mindestlänge,
- keine Begrenzung der maximalen Passwortlänge (Warum sollten Nutzer:innen kein 40-stelliges Passwort nutzen dürfen?),
- Informationen zur Nutzung von Passwortmanagern zur Verfügung stellen,
- Anbieten einer Funktion zur automatischen Generierung eines sicheren Passworts.
Gute Beispiele für eine gelungene Passwortrichtlinie liefert zum Beispiel der BSI Grundschutz, Baustein ORP.4.M22.
Fazit: Sicherheit beginnt beim Betreiber
Viele Passwort-Angriffe lassen sich verhindern oder zumindest deutlich erschweren, wenn Betreiber:innen grundlegende Schutzmaßnahmen umsetzen:
- Login-Versuche limitieren,
- Passwörter korrekt hashen, salten und (idealerweise) peppern,
- Multi-Faktor-Authentifizierung anbieten,
- eine sichere Passwortrichtlinie definieren.
Wie geht die Blogserie weiter?
Im nächsten Teil unserer Blogserie wechseln wir die Perspektive: Was können Nutzer:innen tun, um ihre Konten zu schützen – auch wenn der Dienst-Anbieter vielleicht nicht alles richtig macht?
Dabei beantworten wir unter anderem die folgenden Fragen:
- Was macht ein gutes Passwort aus?
- Warum ist Passwort-Wiederverwendung so gefährlich?
Mehr dazu in Kürze hier.
Prof. Björn Kaidel