Mit Brute-Force-Angriffen lassen sich schwache Passwörter brechen (und mit etwas Pech auch stärkere). Da man schwache Passwörter nicht mit Sicherheit verhindern kann, muss man Brute-Force-Angriffe verhindern oder zumindest erschweren.

5. Brute-Force-Angriffe verhindern

Sämtliche zur Authentifizierung gehörenden Funktionen müssen vor automatisierten Angriffen geschützt werden. Außer der Login-Funktion selbst betrifft das z.B. auch die Funktionen zur Änderung des Passworts und zum Zurücksetzen eines vergessenen Passworts. Dazu sind mehrere Maßnahmen notwendig:

Die Verwendung nicht vorhersagbarer Benutzernamen und die Verhinderung des Sammelns gültiger Benutzernamen erschwert einen Brute-Force-Angriff, da der Angreifer einen oder besser mehrere Benutzernamen kennen muss, um einen Erfolg versprechenden Brute-Force-Angriff durchzuführen. Zwar könnte man sowohl Benutzername als auch Passwort raten bzw. mögliche Werte dafür durchprobieren, aber die Erfolgswahrscheinlichkeit ist dabei deutlich geringer, zumal es keine Möglichkeit gibt (bzw. geben darf), zwischen einem aufgrund eines falschen Passworts und einem wegen eines nicht existierenden Benutzernamens fehlgeschlagenen Authentifizierungsversuch zu unterscheiden.

Auf fehlgeschlagene Authentifizierungsversuche muss angemessen reagiert werden. Bei sicherheitskritischen Anwendungen wie z.B. dem Onlinebanking ist es angebracht, das betreffende Benutzerkonto schon nach einer geringen Anzahl fehlgeschlagener Authentifizierungsversuche, z.b. 3 Stück, zu sperren und erst nach einer erfolgreichen Authentifizierung "out of band" wieder frei zu geben. Das könnte z.B. ein Telefonat mit dem Support und die Beantwortung einiger Sicherheitsfragen oder das persönliche Aufsuchen einer Filiale sein. Dieser sichere Ansatz hat allerdings einen unangenehmen Nebeneffekt: Ein Angreifer kann dadurch absichtlich, ein unaufmerksamer Benutzer bei Verwendung einer falschen Benutzerkennung unabsichtlich einen Denial-of-Service für einen Benutzer verursachen. Außerdem erzeugt die notwendige Möglichkeit zur Out-of-Band-Authentifizierung nicht zu vernachlässigende Kosten. Bei weniger sicherheitskritischen Anwendungen ist daher eine abgestufte Reaktion angebracht, z.B. eine Sperrung für eine kurze Zeitspanne von z.B. 30 Minuten nach dem dritten fehlgeschlagen Authentifizierungsversuch oder eine langsam steigende Wartezeit nach jedem Fehlschlag. Damit wird ein automatisierter Angriff effektiv ausgebremst, während die Gefahr eines Denial-of-Service sinkt und die Kosten für den notwendigen Support gering bleiben. Weitere mögliche Strategien wurden bereits in About Security #215 aufgeführt.

Wird ein Konto temporär gesperrt, müssen mehrere Punkte berücksichtigt werden (siehe auch About Security #216):

• Um die Ermittlung gültiger Benutzernamen zu verhindern, darf keine Meldung ausgegeben werden, dass ein bestimmter Benutzername temporär gesperrt wurde. Stattdessen sollte nach einer Reihe fehlgeschlagener Authentifizierungsversuche, egal ob mit gültigen oder ungültigen Benutzernamen, eine allgemeine Information ausgegeben werden, dass Benutzerkonten nach mehreren fehlgeschlagenen Anmeldeversuchen zeitweise gesperrt werden und der Benutzer es bitte später noch einmal versuchen soll.
• Es sollte niemals verraten werden, wann bzw. wieso die Sperre ausgelöst wurde. Dem Benutzer entsteht kein Schaden, wenn er nur erfährt, dass er es später noch einmal versuchen soll. Ein Angreifer aber kann aufgrund der Information, nach wie vielen Fehlversuchen das Benutzerkonto für wie lange gesperrt wird seinen Angriff anpassen und so optimieren, dass er in möglichst kurzer Zeit möglichst viele Angriffe durchführen kann.
• Wurde ein Benutzerkonto gesperrt, sollte jeder Authentifizierungsversuch sofort, ohne vorherige Prüfung des Passworts, zurückgewiesen werden. Ansonsten besteht die Gefahr, dass das Ergebnis der Prüfung unabsichtlich z.B. in der Fehlermeldung oder durch die Reaktionsgeschwindigkeit verraten wird, so dass ein Angreifer seinen Brute-Force-Angriff trotz der Sperre mit voller Geschwindigkeit durchführen kann.

Alle auf die einzelnen Benutzerkonten abzielenden Schutzmaßnahmen schützen nur vor Angriffen, bei denen einzelne Benutzerkonten mit vielen Passwörtern ausprobiert werden. Bei einem Brute-Force-Angriff, bei dem eine Liste mit einer große Anzahl ermittelter oder erratener Benutzernamen der Reihe nach mit einem einzelnen Passwort durchprobiert wird, kommen diese Schutzmaßnahmen nicht zum Zuge (siehe About Security #217). Wird ein Benutzerkonto z.B. nach 6 fehlgeschlagenen Authentifizierungsversuchen gesperrt, kann der Angreifer ungestört 5 verschiedene Passwörter für alle Benutzerkonten ausprobieren, ohne dass die Sperre aktiviert wird. Da mit ziemlich großer Wahrscheinlichkeit ein paar Benutzer ein schwaches Passwort verwenden, ist die Erfolgswahrscheinlichkeit für einen solchen Angriff gar nicht mal so schlecht. Und sie steigt noch, wenn die Webanwendung sehr viele Benutzer hat und der Angreifer eine lange Liste ihm bekannter Benutzernamen durchprobieren kann.

Wie man so einem Angriff begegnet, erfahren Sie in der nächsten Folge, in der es außerdem um die Absicherung der Funktionen zum Ändern und Zurücksetzen des Passworts geht.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #214: Schwachstellen-Suche: Authentifizierung - Grundlagen
• About Security #215: Schwachstellen-Suche: Authentifizierung - Brute Force
• About Security #216: Schwachstellen-Suche: Authentifizierung - Namen finden
• About Security #217: Schwachstellen-Suche: Authentifizierung - Ein Angriff
• About Security #218: Schwachstellen-Suche: Authentifizierung - Die Übertragung
• About Security #219: Schwachstellen-Suche: Authentifizierung - Verschlüsselung
• About Security #220: Schwachstellen-Suche: Authentifizierung - Unsichere Kryptographie
• About Security #221: Schwachstellen-Suche: Authentifizierung - Passwort ändern
• About Security #222: Schwachstellen-Suche: Authentifizierung - Passwort-Reset
• About Security #223: Schwachstellen-Suche: Authentifizierung - Passwort-Reset (2)
• About Security #224: Schwachstellen-Suche: Authentifizierung - "Remember me"
• About Security #225: Schwachstellen-Suche: Authentifizierung - "User Impersonation"
• About Security #226: Schwachstellen-Suche: Authentifizierung - "Halbe Passwörter"
• About Security #227: Schwachstellen-Suche: Authentifizierung - "Doppelte Benutzer"
• About Security #228: Schwachstellen-Suche: Authentifizierung - Vorhersagbares
• About Security #229: Schwachstellen-Suche: Authentifizierung - Daten übertragen
• About Security #230: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler
• About Security #231: Schwachstellen-Suche: Authentifizierung - Implementierungsfehler (2)
• About Security #232: Schwachstellen-Suche: Sichere Authentifizierung
• About Security #233: Schwachstellen-Suche: Sichere Authentifizierung (2)
• About Security #234: Schwachstellen-Suche: Sichere Authentifizierung (3)
• About Security #235: Schwachstellen-Suche: Sichere Authentifizierung (4)