Brute-Force-Protection

Wos is Brute-Force

Brute-Force-Angriffe auf Webanwendungen sand grod bei größeren Webseitn mit vüle Nutzern a ernsthaftes Problem. Dabei versucht a Angreifer entweder mit zufälligen Nutzername-und-Passwort-Kombinationen an Nutzeraccount zu kompromittiern oda mit ana sogenannten Wordlist, in der si mehrere typische Nutzernamen und mehrere typische Passwörter wia admin und 1234 befindn. Diese Listen wern in schneller Abfolge ausprobiert, und anhand da Rückgabe vom Server wird erkannt, ob da Login erfolgreich woar oda ned. Dabei muass ma - theoretisch - davon ausgehn, dass mit Brute Force hypothetisch jedes Passwort gknackt wern kann. Die Frog is allerdings, in wöcher Zeit des Passwort erratn wern kann. Wenn a Angriff 20 Min dauert, is des für an Angreifer vertretbar, bei 500 Joar schaut des scho ondas aus. Drum is a effektive Möglichkeit, Brute-Force-Angriffe zu valhindern, die Zeitspanne für an erfolgreichen Durchlauf so long wia möglich zu gestoitn. Grundsätzlich is es daher imma ratsam, dem einloggenden Nutzer ned mitzuteiln, ob da Nutzernama existiert. Dadurch erhöht si die Dauer von am erfolgreichen Angriff exorbitant, denn da Angreifer muass neben dem Passwort a no an validen Nutzernamen ratn. Des is weniger bei Netzwerkplattformen sinnvoll, bei denen jeder Nutzer a die Nutzernamen vo de ondern Nutzer sehn kann. A Angreifer tät si dann einfach an validen Account erstöin und die Nutzernamen vo de ondern Nutzer dadurch kriagn (a möglicher Schutzmechanismus steht unten). Weiterhin is grundsätzlich a guater Ansatz, den Login ned über HTTP-Statuscodes zu verifiziern. A 403-Code is für an Angreifer einfach abzufangen, und er kriagt so schnö die Information drüber, ob da Login erfolgreich woar oda ned, und muass ned zusätzlich die Webseitn parsen, um den Loginstatus zu kriagn, wos für uns an zusätzlichen Zeitgwinn bedeutet.

Zeitspanne

Unter https://tmedweb.tulane.edu/content_open/bfcalc.php gibt's an spannenden Rechner, der euch ausrechnen kann, wia long a Brute-Force-Angriff dauert und wia vül Kombinationen möglich sand. A Passwort mit 5 Großbuchstabn, zwoa Kleinbuchstabn und zwoa Zohln gibt ma do folgendes Ergebnis: Your password is 9 characters long and has 803,181,017,600 combinations. It takes 15.58 hours or 0.65 days to crack your password on computer that trys 25,769,803,776 passwords per hour. This is based on a typical PC processor in 2007 and that the processor is under 10% load. 15,58 Stunden is relativ wenig und dürft an Angreifer, der des Programm auf seim Rechner laufn hot, wohl ned abschrecken. Des Ziel muass also sei, die Zeitspanne so zu valängern, dass a Brute-Forcen vom Passwort nimma angemessen ausschaut, gleichzeitig da Nutzer aber so wenig Einschränkungen erfährt wia möglich.

Wia schützn

Captcha

Captchas sand a übliche Vorgehensweise zum Schutz vor Brute-Force-Angriffen. Noch ana gewissen Anzoi nicht erfolgreicher Logins wird dem Nutzer a Captcha angezeigt, des er zusätzlich lösn muass, um an weiteren Loginversuch zu initiiern. Da Vorteil besteht drin, dass da Nutzer ned gsperrt wird und weiterhin die Möglichkeit hot, si einzuloggn, er muass allerdings a Captcha lösn, wos aus Barrierefreiheitsgründen problematisch is. Außerdem kann's vüle Nutzer abschreckn, a Captcha einzugebn, des unter Umständen ned imma leicht zu erkennen is (wos ja da Sinn von da Sach is).

Secret Username

A "Secret Username" (koa Ahnung, ob der Begriff offiziell existiert) bedeutet, dass da Nutzernama, der bei ana Netzwerkplattform sichtbar is, ned gleichzeitig da Nutzernama is, mit dem a Login initialisiert wird. Alternativ kunnt a Nutzer-ID oda (a bissl komfortabler) die Mailadresse erwartet wern. Des bedeutet, wenn i bei am sozialen Netzwerk mit dem Nutzernamen David und da Mailadresse "fancymail@d3vdav3.de" ongmöldn bin, sehn ondere Nutzer nur mein Nutzernama (David), da Login is aber nur mit meiner E-Mail-Adresse "fancymail@d3vdav3.de" möglich. So muass a Angreifer sowohl Nutzernama ois a Passwort ratn, wos die Zeitspanne für an erfolgreichen Angriff deutlich erhöht.

Accountsperre

A Sperre gehört zu de harten Möglichkeiten, an Account vor Brute-Force-Angriffen zu schützn. Dabei wird da Account noch ana gewissen Anzoi vo fehlerhaften Loginversuchen für a gewisse Zeit gsperrt. A Angreifer, der noch 5 Versuchen 30 Sekunden wartn muass, braucht a signifikant längere Zeitspanne, um a Passwort zu ratn, und wird si a leichteres Ziel suachn. Da Nachteil dabei is jedoch, dass dadurch a relativ einfache DOS-Attacke gstartet wern kann. A Angreifer, der den Nutzernamen kennt, kann einfach im Obstand von 30 Sekunden mehrere falsche Loginversuche starten und somit dem legitimen Nutzer an Login valwehren. Außerdem wird si da legitime Nutzer ärgern, soit er wirklich sei Passwort vagessn hom, wenn er erst 30 Sekunden wartn muass, bis a neicher Versuch stattfinden kann.

E-Mail-Verifizierung

A relativ leichte und effiziente Möglichkeit is die Freischoitung weiterer Loginversuche per Mail. Dabei kriagt da Nutzer noch ana gewissen Anzoi vo falschen Loginversuchen a Mail mit am Link, der angklickt wern muass, um den Account wieda freizuschoitn. Dadurch is relativ schnö a neicher Versuch möglich, da Nutzer muass ned wartn und kriagt zusätzlich bei am Brute-Force-Versuch die Info, dass mehrere Logins fehlgschlogn sand, und kann dann gegebenenfalls sei Passwort in a stärkeres ändern.

Mausbewegung

Funktional, aber relativ ineffektiv is des Abfangen von Mausbewegungen. Da Nutzer muass, um auf da Seitn zu navigiern, seine Maus bewegn, sei es, um zum Eingabefeld zu kemman oda den Login-Button zu klickn. A Nutzer, der koane Mausbewegung ausführt, kann unter Umständen a Bot sei und könnt dann zur Eingabe von am Captcha gezwungen wern. Da Nachteil is wieda die Barrierefreiheit: A Navigation auf da Seitn is z. B. über die TAB-Taste möglich, wos koane Mausbewegung triggert und den Nutzer fälschlicherweise ois Bot identifiziert. Drum wär's a sinnvoll, Tastatureingaben zu prüfn. Allerdings wird z. B. via Chromium ebenfalls des Keypress-Event getriggert und da Schutz lauft ins Leere. Außerdem wird a professioneller Angreifer ned übers Formular gehn, sondern Anfragen direkt an des Loginskript via Post-Request schickn. Somit lauft dieser Schutz wieda ins Leere.

Zwoafaktor

A zusätzliches, effektives Vorgehn is die Nutzung von am One-Time-/Timebased-Token auf Grundlage vo da Zwei-Faktor-Authentifizierung. Da Nutzer kriagt do an zum Beispiel 8-stelligen Schlüssel, der si noch ana gewissen Zeit ändert und neu generiert wird. De Generierung vo de Schlüssel erfolgt sowohl client- ois a serverseitig mit dem söbn Seed, sodass da Server den eingebenen Schlüssel zruckrechnen und validiern kann. Da Vorteil liegt do drin, dass si da Schlüssel noch z. B. 30 Sekunden ändert und somit an Brute-Force-Angriff erschwert.

Login-Geschwindigkeit

A des Messn von da Logingeschwindigkeit is a Lösung zur Vermeidung von Brute-Force-Angriffen. Dabei wird serverseitig die Zeitspanne gmessn, die a Nutzer braucht, um an weiteren Loginvorgang zu starten. Angnommen, da legitime Nutzer tippt vor am erneuten Login a ondres Passwort ein, dauert des mindestens a Sekunde, bis a erneuter Loginversuch stattfinden kann. A Client, der mehrere Loginversuche pro Sekunde startet, kann nur programmatisch gsteuert wern und somit ois Bot ongsehn wern. Drum wär's sinnvoll, bei mehreren Login-Versuchen innerhoib vo ana kurzen Zeitspanne zur zusätzlichen Validierung a Captcha einzuschoitn, den Nutzer zu informiern oda den Account für a gewisse Zeit zu sperrn.

Verzögerung im Login-Prozess

A letzte Möglichkeit is die Verzögerung im Loginprozess. Da Nutzer gibt zwoar seine Nutzerdaten o, da Server wartet aber a poar Sekunden, bevor da Login ausgführt wird. Dem Nutzer kann dabei a Ladebalken angezeigt wern, sodass es für eam ausschaut, ois würd da Server die Anfrage no valorbeitn. Dadurch valzögert si jeder einzelne Login um a poar Sekunden, wos an erfolgreichen Brute-Force-Angriff erschwert.

Ergebnis

A absoluter Schutz gegn Brute-Force-Angriffe is ned möglich. Er kann jedoch erkannt und gegebenenfalls so valzögert wern, dass die Zeitspanne bis zum Erfolg so groß is, dass es unökonomisch is, den Angriff tatsächlich laufn zu lossn. Am besten lassn si dazu mehrere do gnannte Methoden kombiniern, wobei imma a Abwägung zwischn Nutzerfreundlichkeit und Sicherheit troffn wern muass.