Passwort-Rateangriffe sind eine der simpelsten Angriffstechniken im Internet. Kennen Angreifer einen Accountnamen oder die verknüpfte E-Mail-Adresse, wird eine Liste möglicher Passwortkandidaten zur Hand genommen und, in der Regel automatisiert, jeder Passwortkandidat für den Account ausprobiert – so lange bis das korrekte Passwort erraten wurde oder die Liste erschöpft ist.
Zum Schutz gegen derartige Angriffe existieren verschiedene, allesamt in ihrer Grundidee ähnliche Maßnahmen. Im Bezug auf Effektivität und unbeabsichtigte Nebenwirkungen unterscheiden sich diese jedoch stark. Kleine Unterschiede in der Umsetzung können große Auswirkungen haben.
Dieser Artikel stellt verschiedene mögliche Konzepte vor und zeigt deren jeweilige Vor- und Nachteile auf, um bei der Entscheidung zu helfen, welche Schutzmaßnahme für die eigene Anwendung angemessen ist. Auf verwandte Angriffstechniken wie "Credential Stuffing", wobei zuvor kompromittierte Zugangsdaten von diversen Accounts ausprobiert werden, oder "Password Spraying", wobei wenige Passwörter bei sehr vielen Accounts getestet werden, wird hier nicht näher eingegangen. Dennoch bieten einige der vorgestellten Schutzmaßnahmen, wie beispielsweise eine Zwei-Faktor-Authentisierung, auch gegen derartige Angriffe einen effektiven Schutz. Zudem ist zu beachten, dass einige der vorgestellten Konzepte nur im Kontext von browserbasierten Webanwendungen anwendbar sind und sich nicht ohne Weiteres auf andere Einsatzzwecke übertragen lassen.
Eine häufig eingesetzte Schutzmaßnahme ist das dauerhafte Sperren von Benutzeraccounts nach mehreren falschen Passworteingaben. Dabei ist eine Anmeldung nach beispielsweise fünf fehlerhaften Passworteingaben auch mit dem korrekten Passwort nicht mehr möglich.
Diese Schutzmaßnahme bietet einen effektiven Schutz gegen Passwort-Rateangriffe und limitiert die Anzahl ratbarer Passwortkandiaten auf die eingestellte Sperrschwelle bis zu dem Zeitpunkt, an dem der Account wieder entsperrt wird.
Ein gravierender Nachteil dieser Methode ist jedoch, dass Angreifer mit Kenntnis eines Accountnamens diesen Account gezielt aussperren können. Dies muss nicht nur einzelne Accounts betreffen, sondern kann im schlimmsten Fall für alle Accounts in der Anwendung gelten.
Zudem muss ein Mechanismus zum Entsperren der Benutzerkonten vorhanden sein. Dies kann von Hand durch Administratoren oder den Support geschehen oder auch indem an eine mit dem Account verknüpfte E-Mail-Adresse ein Link zum Entsperren des Accounts oder direkt zur Anmeldung in der Anwendung gesendet wird. Abhängig von der gewählten Lösung kann der anfallende Aufwand bei aktiven Angriffen stark variieren.
Bei der Implementierung des Sperrmechanismus sollte außerdem darauf geachtet werden, dass sich das Verhalten der Anwendung nicht ändert, wenn bei der Anmeldung ein Account angegeben wird, der nicht existiert. Falls nur dann eine Meldung über die Sperrung des Accounts angezeigt wird, wenn es den Account gibt, kann dieses Verhalten dazu genutzt werden, eine Liste gültiger Benutzer zu erstellen. Dazu würde ein Angreifer für jeden plausiblen Account beispielsweise fünfmal ein falsches Passwort absenden und anhand der Fehlermeldung bestimmen, ob der Account vorhanden ist oder nicht. Als Lösung kann entweder immer nach Erreichen der Sperrschwelle eine Meldung gezeigt werden oder nie. Wichtig ist hierbei lediglich, dass sich das Verhalten nicht unterscheidet.
Eine ebenfalls sehr populäre Maßnahme gegen Passwort-Rateangriffe ist das zeitbasierte Sperren von Accounts nach einer gewissen Anzahl falscher Passworteingaben. Diese Maßnahme verlangsamt Passwort-Rateangriffe signifikant, verhindert sie in der Regel aber weniger effektiv als eine dauerhafte Sperre des Accounts. Wird ein Account beispielsweise nach 5 Fehlversuchen für 15 Minuten gesperrt, können immer noch 20 Passwortkandidaten pro Stunde getestet werden. Ein Vorteil, der oftmals für den Einsatz von temporären Sperren im Gegensatz zu dauerhaften Sperren angeführt wird, ist, dass Accounts nicht gezielt dauerhaft aus der Anwendung ausgesperrt werden können. Dies ist jedoch nur teilweise richtig, da ein Angreifer nach Ablauf der Sperrdauer das mutwillige Sperren des Accounts einfach wiederholen kann. Durch Automatisieren dieses Vorgangs kann effektiv eine dauerhafte Sperre erzielt werden. Dennoch ist der anfallende Aufwand bei einem aktiven Angriff geringer als bei einer dauerhaften Sperre. Wird beispielsweise die IP-Adresse blockiert, von der der Angriff ausgeht, ist die Anwendung nach Ablauf der Sperrdauer wieder normal benutzbar und ein aktives Entsperren von Accounts ist nicht nötig.
Analog zum dauerhaften Sperren sollte dafür Sorge getragen werden, dass der Sperrmechanismus nicht zur Enumeration gültiger Accounts verwendet werden kann.
Eigentlich erscheint es sinnvoll, im Falle von zu vielen Fehlversuchen einfach die IP-Adresse des entsprechenden Benutzers zu sperren – insbesondere da im Optimalfall lediglich der Angreifer gesperrt wird und sich das Opfer nach wie vor anmelden kann. Das galt vielleicht bis vor einigen Jahren. In der heutigen Zeit ist das Internet jedoch weit komplexer aufgebaut und ein regulärer Endbenutzer hat aufgrund von Network Address Translation (NAT) im Allgemeinen überhaupt keine eigene, öffentlich routbare IP-Adresse. Die IP-Adresse, die hier gesperrt würde, wäre viel eher eine ausgehende IP-Adresse des Internetproviders oder des Firmenproxy. Hinter der IP-Adresse würde sich also nicht nur ein einzelner Benutzer verstecken, sondern tatsächlich eine unbekannte Anzahl. Im schlimmsten Fall könnte ein komplettes Unternehmen oder ein großer Teil der Anwender gesperrt werden – weil ein Benutzer sein Passwort vergessen hat.
Zur Abwehr von gezielten, aktiven Angriffen kann das Blockieren von IP-Adressen eine valide Maßnahme sein, als alltägliche Schutzmaßnahme für Benutzeraccounts hingegen weniger – zumindest solange IPv6 noch nicht flächendeckend eingesetzt wird. Sollte zukünftig jeder Netzwerkteilnehmer über eine eigene IP-Adresse verfügen, könnte das gezielte Blockieren durchaus sinnvoll sein.
Gegen motivierte Angreifer, die, beispielsweise durch ein Bot-Netz, über eine Vielzahl von IP-Adressen verfügen, bietet diese Maßnahme allerdings keinen ausreichenden Schutz.
Zudem sollte bedacht werden, dass selbst Angreifer ohne eigenes Bot-Netz durch Listen öffentlich verfügbarer Proxyserver mehrere IP-Adressen zur Verfügung haben, über die sie Angriffe auch im Falle einer gesperrten IP-Adresse fortsetzen können.
CAPTCHAs sollen dafür sorgen, dass nur ein Mensch Funktionen nutzen kann, die durch das CAPTCHA geschützt sind, und keine automatischen Tools. Prinzipiell sind CAPTCHAs also auch zum Schutz gegen automatisierte Passwort-Rateangriffe geeignet. Um den Benutzungskomfort der zu schützenden Anwendung nicht allzu sehr zu beeinträchtigen, kann beispielsweise erst nach mehrmaliger fehlerhafter Passworteingabe das Lösen eines CAPTCHAs erforderlich sein. Bei der Entscheidung, ob CAPTCHAs eine angemessene Lösung für die eigene Anwendung sind, sollte allerdings berücksichtigt werden, dass Onlinedienste existieren, die das Lösen von CAPTCHAs als Dienstleistung anbieten. Glaubt man den Informationen auf den Webseiten der Anbieter, werden durchschnittlich sieben bis zehn Sekunden zur Lösung eines CAPTCHAs benötigt. Im schlimmsten Fall könnten damit über 500 Passwortkandidaten pro Stunde getestet werden. Natürlich könnten Angreifer die CAPTCHAs auch selbst händisch lösen, um ähnliche Geschwindigkeiten zu erreichen.
Anbieter, die CAPTCHAs automatisiert anstatt durch menschliche Arbeit lösen, können noch deutlich höhere Lösungsgeschwindigkeiten erzielen, allerdings nicht mit hundertprozentiger Erfolgsquote. Sofern dabei jedoch festgestellt werden kann, wenn ein CAPTCHA nicht korrekt gelöst wurde, kann einfach das nächste CAPTCHA probiert werden, wodurch lediglich die Lösungsgeschwindigkeit leicht abnehmen würde.
Für den Einsatz von CAPTCHAs im Gegensatz zu verschiedenen Arten von Sperren spricht, dass Benutzer nicht durch gezielte Passwort-Falscheingabe aus der Anwendung ausgesperrt werden können.
Vergleicht man die bisher angeführten Schutzmaßnahmen, wünscht man sich eventuell eine Schutzmaßnahme, die den effektiven Schutz von dauerhaften Accountsperren bieten kann, allerdings ohne das Risiko von gezielten Sperren durch Angreifer. Mit Device Cookies kann genau das erreicht werden.
Das Konzept ist verhältnismäßig simpel: Nach einer erfolgreichen Anmeldung wird im Browser des Benutzers ein Cookie gespeichert, welches automatisch bei jeder weiteren Anmeldung mitgesendet wird. Wird nun ein Passwort-Rateangriff auf den Account des Benutzers durchgeführt, wird der Account gesperrt. Eine Anmeldung, die das Device Cookie beinhaltet – und das korrekte Passwort –, wird allerdings weiterhin akzeptiert. Dadurch können legitime Anwender nicht gezielt ausgesperrt werden, zumindest solange sie sich nicht von einem neuen Browser anmelden, und trotzdem werden Passwort-Rateangriffe effektiv verhindert.
Die Art der Sperre kann auch temporär gewählt werden, je nachdem, ob ein effektiver Schutz oder ein geringer Aufwand bei aktiven Angriffen priorisiert wird.
Viele Webseiten bieten Benutzern bereits die Möglichkeit, ihren Account mittels Zwei-Faktor-Authentisierung zu schützen, manche erzwingen den Einsatz sogar. Verwendet werden häufig numerische Einmalcodes, die via SMS oder Zwei-Faktor-App bereitgestellt werden.
Auch beim Einsatz einer Zwei-Faktor-Authentisierung sollten Vorkehrungen zum Schutz gegen Passwort-Rateangriffe getroffen werden. Falls diese fehlen und das Passwort eines Benutzers erraten wird – oder aus anderen Angriffen bekannt ist –, können leicht Rateangriffe auf den zweiten Faktor durchgeführt werden. Insbesondere bei gängigen sechsstelligen Codes können alle möglichen Codes in absehbarer Zeit ausprobiert werden.
Ähnliche Schutzmaßnahmen wie bei Loginfunktionen ohne Zwei-Faktor-Authentisierung können eingesetzt werden, wobei bestimmte Implementierungen besonders vorteilhaft erscheinen.
Beispielsweise ist es möglich, die relevanten Logininformationen – nämlich Benutzername, Passwort und Zwei-Faktor-Code – gleichzeitig abzufragen. Wird bei einer fehlerhaften Anmeldung nicht zurückgemeldet, welcher Anmeldefaktor falsch ist, werden Passwort-Rateangriffe stark erschwert.
Da anhand der Rückmeldung nicht klar ist, ob der Zwei-Faktor-Code oder das Passwort falsch ist, müssen pro Passwortkandidat alle möglichen Zwei-Faktor-Codes getestet werden, um mit Sicherheit feststellen zu können, ob das Passwort korrekt ist oder nicht. Dadurch erhöht sich die Anzahl der benötigten Anfragen enorm.
Ändert sich der Zwei-Faktor-Code regelmäßig, zum Beispiel alle 30 Sekunden, müssen Angreifer innerhalb dieses Zeitraums alle möglichen Zwei-Faktor-Codes ausprobieren. Ansonsten ist unklar, ob der korrekte Zwei-Faktor-Code überhaupt mit dem Passwortkandidaten ausprobiert wurde.
Alle möglichen Zwei-Faktor-Codes innerhalb dieser Zeit auszuprobieren, ist selbst mit geschwindigkeitsoptimierten Tools schwer möglich – insbesondere wenn Netzwerklatenzen und Serverantwortzeiten ins Spiel kommen. Zudem ist unter Umständen auch überhaupt nicht bekannt, zu welchem Zeitpunkt ein neuer Code erstellt wird und wann der neue Zeitraum beginnt.
Insgesamt sind Passwort-Rateangriffe auf eine derartige Implementierung zeit- und anfrageintensiv – und das bei geringer Erfolgswahrscheinlichkeit. Ein offensichtlicher Nachteil ist allerdings die verschlechterte Benutzerfreundlichkeit der Anmeldefunktion, da bei erfolgloser Anmeldung kein Hinweis darauf gegeben werden darf, welche der drei Logininformationen falsch ist. Benutzer können unter Umständen also nicht einfach feststellen, ob sie das korrekte Passwort verwendet haben, aber der Zwei-Faktor-Code abgelaufen ist/falsch getippt wurde, oder ob das Passwort an sich falsch war.
Eine zweistufige Zwei-Faktor-Authentisierung ist hingegen eine benutzerfreundliche und gängige Alternative. Im ersten Schritt werden lediglich Benutzername und Passwort abgefragt und im zweiten Schritt dann der zweite Faktor. Eine Möglichkeit, diese Implementierung gegen Passwort-Rateangriffe zu schützen, besteht darin, Accounts nach mehrmaliger Falscheingabe des zweiten Faktors dauerhaft zu sperren.
Auf den ersten Blick mag diese Möglichkeit einer dauerhaften Sperre des Accounts bei mehrfacher Falscheingabe des Passworts ähnlich erscheinen. Ein entscheidender Unterschied ist aber, dass ein Angreifer nur dann überhaupt die Möglichkeit hat, Rateversuche auf den Zwei-Faktor-Code durchzuführen, wenn das Passwort des Benutzers bereits bekannt ist. Also exakt die Situation, in der das Sperren eines Accounts tatsächlich erforderlich ist.
Die Sperrschwelle, nach deren Erreichung der Account gesperrt wird, kann bei dieser Implementierung auch etwas höher gewählt werden. 20 Fehlversuche sind zum Beispiel deutlich mehr, als ein normaler Nutzer eingeben würde – bei dennoch geringer Wahrscheinlichkeit, dass der Code erraten wird.
Von Nachteil ist hierbei jedoch, dass Angreifer ungehindert Rateangriffe auf das Passwort des Benutzers durchführen können, da der erste Anmeldeschritt ungeschützt ist. Zwar kann, auch wenn das Passwort des Benutzers erraten wird, nur mit geringer Wahrscheinlichkeit Zugriff auf den Account erlangt werden. Dennoch ist Passwortwiederverwendung ein weit verbreitetes Problem, durch das andere Zugänge des Benutzers gefährdet sein können.
Zu beachten ist bei beiden Maßnahmen, dass sie nur dann zuverlässig funktionieren, wenn alle Benutzer eine Zwei-Faktor-Authentisierung verwenden. Falls dies nur für einen Teil der Benutzer zutrifft, müssen gegebenenfalls andere Schutzmaßnahmen für Accounts ohne Zwei-Faktor-Authentisierung eingesetzt werden.
Die Auswahl einer geeigneten Schutzmaßnahme sollte in Abhängigkeit des Schutzbedarfs der Accounts und unter Abwägung der jeweiligen Vor- und Nachteile der verschiedenen Maßnahmen erfolgen. Dabei können auch mehrere Maßnahmen kombiniert werden. Beispielsweise können verschiedene Formen von Accountsperren zusammen mit CAPTCHAs eingesetzt werden, was sowohl Passwort-Rateangriffe als auch gezielte Accountsperren aufwändiger macht. Auch eine Zwei-Faktor-Authentisierung ist generell empfehlenswert. Bei der konkreten Umsetzung der Maßnahmen sollte auch bedacht werden, dass Passwort-Rateangriffe nicht immer hochfrequent sein müssen. Angreifer, die unbemerkt bleiben wollen, testen teilweise nur wenige Passwortkandidaten pro Tag. Bei der Entscheidung, ob ein Account gesperrt wird oder sonstige Gegenmaßnahmen eingeleitet werden, sollten unter Umständen also auch fehlerhafte Anmeldeversuche über einen längeren Zeitraum betrachtet werden.
Generell sind bei dieser Thematik Implementierungsdetails entscheidend, weshalb deren Umsetzung sorgfältig geplant und durchdacht werden sollte.
Perspektivisch erscheint der Einsatz gänzlich passwortfreier Anmeldemethoden wie beispielsweise WebAuthn empfehlenswert, da dadurch einige der konzeptionellen Probleme passwortbasierter Authentifizierungsmethoden gar nicht erst auftreten können.
Maßnahme | Dauerhafte Accountsperre | Temporäre Accountsperre | IP-Adresssperre | CAPTCHAs |
Vorteile | effektiver Schutz | ausreichender Schutz kein Entsperrmechanismus nötig | sperrt im Optimalfall den Angreifer | kein Entsperrmechanismus nötig |
Nachteile | gezieltes Sperren von Bernutzerkonten möglich | gezieltes Sperren von Benutzerkonten möglich | unbeabsichtigtes Sperren vieler Benutzer möglich ineffektiv gegen Bot-Netze | Bei blockierten Accounts sind Anmeldungen von einem neuen Browser nicht möglich. |
Maßnahme | Einstufige Zwei-Faktor-Authentisierung | Zweistufige Zwei-Faktor-Authentisierung |
Vorteile | effektiver Schutz | effektiver Schutz |
Nachteile | verschlechterte Benutzerfreundlichkeit nur möglich, wenn alle Benutzer 2FA verwenden | erlaubt Rateangriffe auf das Passwort schützt nur Benutzer, die 2FA verwenden |
14.01.2025
- 15.01.2025
Hack1/Hack2: Hacking Workshop
16.01.2025
- 17.01.2025
Hack1/Hack2: Hacking Workshop
27.01.2025
- 28.01.2025
Hack4: Angriffe gegen VoIP-Infrastrukturen
03.02.2025
Secu5: Planung und Durchführung von Penetrationstests
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de | IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Ihr direkter Kontakt zu SySS +49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN +49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer
Direkter Kontakt
+49 (0)7071 - 40 78 56-0 oder anfrage@syss.de
IN DRINGENDEN FÄLLEN AUSSERHALB DER GESCHÄFTSZEITEN
+49 (0)7071 - 40 78 56-99
Als Rahmenvertragskunde wählen Sie bitte die bereitgestellte Rufbereitschaftsnummer