Ohhh über das Thema habe ich schon viel diskutiert und hatte da schon einmal ein längeren PDF-Artikel zu geschrieben, der leider mit Microsoft-Docs verschwunden ist.
Gerade Passwörter für Webseiten sind da immer ein sehr interessantes Thema. Denn an Hand der Implementierung der Passwortmechanismen von Internetseiten kann man schon viel über das Sicherheitsbewusstsein der Betreiber erfahren. Leider bleiben einige im verborgenen. Hatte vor einer Weile mir mal ein paar CM-Systeme für Gamimg-Clans angeschaut und war regelrecht erschrocken. WebSpell z.B. nutzte einen eigene Passwortroutine. Wenn man an die Datenbank kommt und die Hashes kriegt, dann prost Mahlzeit
Je länger ein Passwort ist, um so höher ist der Aufwand, dies zu knacken. Aber selbst ein langes Passwort kann durch den richtigen Algorithmus schnell erraten werden, wenn man zu einfach an die Sache heran geht.
... Leider hält sich immer noch der Irrglaube, dass Passwörter wie "g&z/1.-S" irre sicher wären. Nein, sind sie nicht. Das genannte PW hätte 127^8 Möglichkeiten, also rund 6,7 x 10^16.
Das Passwort "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" hat 26^30 Möglichkeiten, also 2,8 x 10^42 und ist damit um 26 Größenordnungen (!!) sicherer.
Von der grundsätzlichen Kombinationsvielfalt stimmt das natürlich. Allerdings müssen, damit sich ein Angreifer dem bewusst ist, erst einmal Hinweise auf das Passwort existieren. Ansonsten fängt er wie alle anderen auch bei 0 an. Und da ist entscheidend, wie das Passwortsystem eines Dienstes genau implementiert ist. Wenn ein Dienst z.B. Passwörter zwischen 8 und 16 Zeichen zulässt, schränkt sich bereits der Umfang möglicher Passwörter erheblich ein. Wenn der Dienst aber die Möglichkeit gibt, Passwörter zwischen 6 und 32/48/64 Zeichen zu erlauben, dann ist die Kombinationsmöglichkeit um Welten höher.
Beim Bruteforcen durch Errechnung von Passwörtern fangen Angreifer im Regelfall ganz unten und ganz oben an. Zum einen um so die bequemen Nutzer zu kriegen, die versuchen so schnell wie Möglich das Minimum an Anforderung zu erfüllen. Zum anderen bekommen sie am anderen Ende die zwar theoretisch sicherheitsbewussten, aber uninformierten Nutzer, die versuchen, das Maximum zu nutzen. Je größer also die Range zwischen Minimum und Maximum ist, um so sicherer ist auch das Passwort. Wörterbuchattacken können im übrigen mit Phrasebuildern kombiniert werden, wodurch das Cracking-Tool sogar ganze Sätze bildet und diese probiert.
Genauso sind Limitierungen durch erzwingen bestimmter Zeichen kritisch zu sehen. Wenn ein Dienst grundsätzlich die Nutzung eines Großbuchstaben, mindestens n Ziffern und mindestens ein Sonderzeichen vorschreibt, dann können Cracking-Tools alle generierten Passwörter verwerfen, die nicht diesen Regeln entsprechen, wodurch die Kombinationsvielfalt erheblich eingeschränkt wird und zudem reduziert es die Menge an Requets an den Server deutlich. Um Passwörter zu erzeugen und mit Hilfe eines regulären Ausdrucks auf das Muster zu prüfen, benötigt selbst ein lahmes Subnotebook nicht annähernd so viel Zeit, als das sie messbar wäre (< 1ms - getestet mit C ohne Debugger). Die Requets an den Server selbst hingegen brauchen deutlich länger.
Loginformulare sollten nach Möglichkeit über eine CSRF-Protection verfügen, die das Cracking-Tool dazu zwingt, bei jeden Versuch das Formular erst zu holen, um einen gültigen Token zu bekommen. Das Clan-CMS Clansphere hat zum Beispiel das CSRF-Token erzeugt und innerhalb der Session in einem Array hinterlegt. Bei jedem weiteren Aufruf kam ein Token dazu. Das ist natürlich alles andere als sicher. Die Software muss bei jedem neuen Token den alten überschreiben. So kann das Tool nur exklusiv ein Token verwenden und muss bei jedem Versuch das Formular aufrufen, Token extrahieren und dann den Versuch starten.
Der Login-Prozess selbst muss einen Moment dauern. Der Server sollte nach Möglichkeit erst in mindestens 800 - 1200 ms antworten und in dieser Zeit auch mit dem hashen des Passwortes beschäftigt sein. Egal ob Blowfisch oder Argon. Der Kostenfaktor lässt sich konfigurieren. Ich lasse den in meinen Projekten nie auf Standard. Sollte man also an die Hashes über eine Datenbank-Lücke kommen, ist durch den höheren Kostenfaktor die Nutzung einer Lookup-Table vollkommen sinnfrei. Denn solche Lookup-Tables sind wahrscheinlich mit genau diesem Kostenfaktor noch nicht present oder es dauert noch Jahre/Jahrzehnte, bis deren Datenbestand wirklich nützlich ist.
Die Formulardaten dürfen erst nach 2 - 4 Sekunden angenommen werden, ansonsten wird der Request abgewiesen. Das Formular zur Registrierung kann dem Nutzer zwar Hinweise darauf geben, wie ein sicheres Passwort aufgebaut sein könnte. Aber es muss auch ein Hinweis darauf existieren, das diese Regeln nicht erzwungen werden. Wenn ein Nutzer das Passwort "HalloBello" nehmen will, so muss es ihm möglich sein, und er muss auch wissen, das er es nehmen kann. Denn nur wenn sicher ist, das der Nutzer weiß, das er es benutzen kannn, weiß auch der Angreifer, das Nutzer solche Passwörter nehmen werden und muss sich wieder mit dem kompletten möglichen Kombinationsumfang herumschlagen.
Und zu guter letzt natürlich noch den Client nach X Fehlversuchen für X Minuten aussperren. Ich nutze da immer die 5/15 Regel. 5 Fehlversuche sind 15 Minuten IP-Sperre.
Zur Passwortwahl: Man sollte natürlich nicht überall das selbe nehmen. Man sollte aber auch nach Möglichkeit versuchen, nicht zwingend auf ganze Wörter zu setzen. Man könnte natürlich die Wörter mit 1337-Speek versalzen, sollte dies aber nicht konsequent einsetzen sondern einige Buchstaben noch Original lassen. z.B. "F0rd#Mu5t4ng" statt "F0|2d#|V|u574|V6" (weiß jetzt nicht, ob das jetzt alle übersetzt waren
). Setzt man es konsequent im kompletten Umfang ein, kann ein einfacher Konverter-Algo bereits einem das Genick brechen. Auch eine interessante Praxis ist, sich ein oder zwei Sätze zu nehmen und die Anfangsbuchstaben zu verwenden:
Ich kaufe mir gerne Games, die im Sale nicht mehr wie 17,32 € kosten!
Als Passwort:
Aber abschließend muss man wirklich sagen, das es bis auf die Regel, nicht überall das gleiche zu benutzen, keine wirklich feste Regel gibt. Sind die Dienste, wo man sich anmeldet, richtig implementiert und auch im Backend abgesichert, das niemand von außerhalb an die Datenbank kommt, dann kann man nahezu jedes Passwort nehmen, solange es keine stupiden Zeichenfolgen wie 12345678, abcdefg, qwertz oder sonst ein Quark ist. Denn mit den richtigen Passwortmechanismen lohnen sich Angriffe einfach nicht und dann kommt auch das Passwort nie ans Licht. Egal wie einfach es am Ende auch sein mag.
