Eigentlich wollte ich mich zu diesem Thema ja nicht äußern, aber man liest immer noch hier und da in Artikeln, dass Passwörter möglichst kryptisch sein sollen. Dies ist jedoch nicht nötig und wird meinem Empfinden nach auch in immer mehr Artikeln anders dargestellt, jedoch eben noch längst nicht in allen.

Die geltenden Regeln zu sicheren Passwörtern kann man bei techfacts nachlesen.

Verfahren zum Knacken von Passwörtern

Zuersteinmal müssen wir uns klarmachen, welche Möglichkeiten es zum Knacken von Passwörtern gibt, um diese dann auf ihre Effizienz gegenüber unseren Passwörtern zu untersuchen.

  • Brute-Force: Dies bedeutet, dass jeder Buchstabe als Passwort versucht wird. Also z.B. a, dann b und so weiter, danach aa, ab. Dies kann man auch um Groß- und Kleinschreibung, Zahlen und Sonderzeichen erweitern. Je nachdem hat man verschieden große Zeichenmengen. Typischerweise können diese aus 26 Zeichen (Kleinschreibung), 36 Zeichen (Alphanumerisch), 52 Zeichen (Groß- und Kleinschreibung), 62 Zeichen (Groß-, Kleinschreibung und Zahlen) oder noch mehr Zeichen (inkl. Sonderzeichen) bestehen.

  • Wörterbuch: Beim Wörterbuch verwendet der Angreifer tatsächlich in einer Sprache existierende Wörter, um das Passwort zu knacken. Dabei bietet es sich an, die Sprache des Benutzers sowie Englisch zu testen. Bei Attacken auf Hash-Werte mittels rainbow-Tabellen (große Speicher mit einer Zuordnung Hash-Wert => Ausgangspasswort) entfällt diese Auswahl und es können alle vorhandenen Sprachen verwendet werden, wobei sich dies aufgrund der Größe der Tabellen auch auf die wichtigsten Sprachen beschränken wird. Bei Angriffen ohne rainbow-Tabellen kann man zusätzlich noch eine Sortierung nach den wichtigsten Wörtern vornehmen, um diese zuerst zu probieren (anstatt alphabetisch).

Genau genommen ist der Wörterbuch-Angriff allerdings auch nur eine Variante von Brute-Force mit eigenem Alphabet. Bei Brute-Force kommen die oben genannten Alphabete zum Einsatz (z.B. Kleinschreibung), bei Wörterbuch-Angriffen die Menge der wichtigsten oder aller Wörter einer oder mehrerer Sprachen.

Übliche heutige Passwörter

Nach dem heutigen Standard sollen vor allem kryptische Passwörter verwendet werden. Häufig wird dabei unsinnigerweise auch noch eine Längenbeschränkung festgesetzt (bei meiner Universität bspw. 8 Zeichen, in denen man aber Buchstaben, Zahlen und zwei Sonderzeichen einbauen soll, und sich das dann auch noch merken). Um die Sicherheit dieser Passwörter zu ermitteln, müssen wir ein Alphabet annehmen und durchrechnen, wie viele Versuche man im schlechtesten Fall benötigt, bis man das Passwort gefunden hat. Insbesondere bei rainbow-Tabellen ist die sich ergebende Zahl ein guter Indikator, ob das Passwort in solch einer Tabelle vorkommen wird oder nicht.

Gehen wir vom obigen Fall des achtstelligen Passworts mit Groß-, Kleinschreibung, Zahlen und Sonderzeichen aus und rechnen einmal die Brute-Force-Sicherheit beim angenommenen kleinstmöglichen Alphabet (d.h. nur die Zeichengruppen, die tatsächlich verwendet wurden).

Gehen wir einmal von möglichen 80 Zeichen aus, da die Zahl der Sonderzeichen nicht genau angebbar ist, dann ergibt sich bei acht Stellen eine Sicherheit von \(80^8 \approx 1,68 \cdot 10^{15}\). Ein Wörterbuch-Angriff muss in diesem Fall nicht ausgerechnet werden, da dieser unmöglich ist, da sich mit den gegebenen Regeln kein existierendes Wort erstellen lässt. Diese daraus resultierende hohe Sicherheit erkauft man sich allerdings mit einer schlechten Merkbarkeit des Passworts.

Bei fast allen Plattformen finden sich auch weniger restriktive Vorgaben zum Passwort, häufig gar keine. Deshalb neigen manche Internetbenutzer dazu, ein tatsächlich existierendes Wort zu verwenden. Dies führt zu einer Sicherheit von etwa 100.000 nötigen Versuchen (im worst-case aus Sicht des Angreifers). Eine Sprache besitzt zwar bis zu 500.000 Wörtern (Deutsch und Englisch), jedoch streichen wir hier viele, da der Benutzer üblicherweise nicht das schwierigste Wort der jeweiligen Sprache wählen wird, sondern ihm bekannte. Eine bessere Methode werden wir weiter unten kennenlernen.

Auch der Zusatz von einigen Zeichen zum Wort schafft nur wenig Abhilfe, da dies nur eine Multiplikation, jedoch keine Potenzierung der Versuche zur Folge hat. Hängt man an sein Wort eine 3-stellige Ziffer an (z.B. baumstamm436), so erhöht man die Sicherheit von 100.000 lediglich um den Faktor \(10^3\), also \(100.000 \cdot 10^3 = 10^8\), da diese Methode von Crackern häufig implementiert wird. Man darf hier also nicht davon ausgehen, dass durch das Anhängen von wenigen Zeichen an ein Wort das Wörterbuch-Alphabet nicht mehr verwendet werden kann. Ab einer bestimmten Länge wäre die Sicherheit natürlich dann wieder ausreichend hoch.

Mehrere Wörter

Man kann nun, wie dies im Internet inzwischen meinem Empfinden nach öfters vorgeschlagen wird, mehrere Wörter zu einem Passwort verbinden. Dadurch potenziert sich die Sicherheit gleich wie bei dem kryptischen Passwort mit der Anzahl der Wörter (allerdings mit der größe des Wörterbuch-Alphabets als Basis). Dies heißt, dass die Sicherheit bei zwei Wörtern bereits auf \(100.000 \cdot 100.000 = 10^{10}\) steigt. Damit ist ein Passwort aus zwei Wörtern bereits sicherer als eine Kombination aus einem Wort und einigen Zahlen. Man muss dann natürlich aufpassen, dass das Passwort nicht so kurz wird, dass es mit Brute-Force schneller zu finden ist als mit einem Wörterbuch.

Die Länge, die unser Passwort dafür mindestens erreichen muss, können wir mit dem Logarithmus mit der Basis 52 (da unser Wort Groß- und Kleinbuchstaben besitzt) berechnen:

\[log_{52}(10.000.000.000) \approx 5.827\]

Ab einer Länge von sechs Zeichen sind die beiden Wörter mit Brute-Force also schwerer zu knacken als mit Dictionary. Dies kann als immer gegeben betrachtet werden, da die Wörter sowieso nicht zu kurz sein sollten, um die Annahme von einer Alphabetgröße von 100.000 zu rechtfertigen. Würden wir die Wörter ichbin wählen, dürften wir eher eine Alphabetgröße von nur 100 annehmen, da diese Wörter zu den wichtigsten 100 Wörtern der deutschen Sprache gehören.

Vom Passwort zurück zur Passphrase

Dies könnten wir nun noch steigern, indem wir noch mehr Wörter kombinieren. Allerdings muss man sich die Frage stellen, warum wir überhaupt von einem Passwort (password) sprechen und nicht wie dies bei GnuPG üblich ist von einer passphrase, wenn man so will also einem Passsatz. Dieser ist für uns Menschen leicht zu merken und macht einen Angriff wesentlich schwerer.

Wählen wir einen beliebigen Satz:

Wo hab ich meinen Schlüssel?

Dieser Satz beinhaltet fünf Wörter und ein zusätzliches Sonderzeichen am Satzende (Faktor 4, da Punkt, Ausrufezeichen, Fragezeichen oder nichts) sowie die Wahl zwischen Leerzeichen oder keinen Leerzeichen zwischen Wörtern (Faktor 2). Dabei gehen wir davon aus, dass Programme bereits auf solche Passwörter optimiert seien, was sie keinesfalls sind. In Realität darf man diese jetzige Berechnung also gar nicht berücksichtigen. Dies würde selbst beim Wörterbuch-Alphabet zu einer Sicherheit von \(100.000^5 \cdot 4 \cdot 2 = 8,00 \cdot 10^{25}\).

Nun darf man jedoch nicht davon ausgehen, dass Programme darauf optimiert sind. Vielmehr ist für das Knacken von solchen Passwörtern Brute-Force nötig. Dies führt allerdings zu einer unvorstellbaren Menge an Versuchen, da der Satz zu lang ist. Zudem implementieren vermutlich nur die wenigstens Programme auch Leerzeichen in ihrem Alphabet, da dies kaum verwendet wird (von manchen Programmen aber auch nicht unterstützt). Der obige Passsatz hat 28 Zeichen bei einem minimalen sinnvollen Alphabet von 70 Zeichen (wir haben die 80 Zeichen für alle Zeichengruppen abzüglich der 10 für Zahlen verwendet). Dies ergibt eine Passwortsicherheit von \(70^{28} \approx 4,60 \cdot 10^{51}\).

Die einfach merkbaren Sätze erweisen sich damit als wesentlich sicherer als alle übrigen Varianten.

Caveat

Zu beachten ist bei solch langen Passwörtern ggfs. noch die Entropie des Hashing-Algorithmus, der jedoch von Programm zu Programm schwanken kann und den man als Benutzer nicht kennt. Wann Kollisionen mit wesentlich kürzeren Ausgangsbegriffen zu erwarten sind, kommt außerdem darauf an, wie genau der Hashing-Algorithmus implementiert ist.

I do not maintain a comments section. If you have any questions or comments regarding my posts, please do not hesitate to send me an e-mail to blog@stefan-koch.name.