suit.rebell.at

Heute findet man kaum noch eine Webseite ohne Interaktionsmöglichkeiten für den Besucher - sei es ein Online-Shop, eine Forum oder einfach nur die Wartungsoberfläche des eigenen Content-Management-Systems. Egal was es ist, wir haben ein gemeinsames Problem: das System muss sich in irgend einer Weise merken, welcher Benutzername zu welchem Passwort gehört. Genauer gesagt muss dem System das Passwort bekannt sein.

Die einfachste und gebräuchlichste Möglichkeit ist es, das Passwort im Klartext gemeinsam mit dem Benutzernamen in einer Datenbank abzulegen. Aber auch wenn diese Methode sehr einfach ist, stellt sie doch eine erhebliche Sicherheitslücke dar.

Warum nicht im Klartext?

Prinzipiell kommt in einem sicheren System niemand an die Daten - aber welches System ist schon sicher? Viele lassen z.B. den Faktor "Mensch" außer acht. Irgendwer hat immer sehr leicht Zugriff auf die Daten und das ist meistens der Administrator selbst. Für Ihn wäre es ein leichtes, sämlichte Daten auszulesen. Natürlich sollte aber auch das Worst-Case-Szenario, also der Verlust der gespeicherten Benutzerdaten durch einen Angreifer, nicht kategorisch ausgeschlossen werden. In den letzten Jahren haben viele große Communitys eine erhebliche Anzahl an Benutzerdaten auf verschiedenste Arten "verloren" - WoltLab^[1],  Häfft^[2], Gawker^[3] und Sony^[4] stellen hier nur einen kleinen Auszug dar.

Um also in so einem Fall nicht auf die Nase zu fallen ist es unwahrscheinlich wichtig, die Passwörter zu verschlüsseln oder noch besser die Passwörter in Form eines Streuwerts (Hash) abzulegen.

Verschlüsselung vs. Streuwert

Auch wenn augenscheinlich eine Verschlüsselung sinnvoll erscheint, gibt es ein Problem bei dieser Methode: wohin mit dem Schlüssel? Sobald ein Angreifer Vollzugriff auf sämtliche Daten (verschlüsseltes Passwort, Algorithmus und Schlüssel) hat, ist die Sicherheit der Passwörter nicht mehr gewährleistet. Wie wir wissen, wäre es für einen Angreifer aus den eigenen Reihen ein Leichtes, an sämtliche benötigten Dinge zu kommen.

Die verbleibende sinnvolle Methode ist ein Hash, also eine mathematische Funktion die aus einem gegegebenen Text eine Art Prüfsumme erzeugt. Dies hat den Vorteil, dass es trotz Kenntnis des Hashes und der Hashfunktion unmöglich ist, den ursprünglichen Klartext zu ermitteln, da jeder Hash eine Vielzahl potentieller Klartexte hat bzw. sich viele Klartexte dieselbe Prüfsumme teilen. Wer also ein Passwort grundlegend schützen möchte, schickt dieses vorab durch eine Hashfunktion, z.B. MD5 (128 Bit) oder SHA-256 (256 Bit). Bei einem Anmeldeversuch wird zuerst das vom Benutzer eingegebene Passwort durch dieselbe Hashfunktion geschickt und dann mit dem in der Datenbank abgelegten Hash verglichen.

Angriffe auf die Hashfunktion oder Hashes

In der Theorie ist ein Passwort also sicher, wenn es als Hash vorliegt. Das Problem dabei ist allerdings wieder der Faktor Mensch. Durchschnittsmenschen ohne Sicherheitsbewusstsein verwenden überall dasselbe Passwort, zudem ist dieses Passwort meistens sehr einfach gewählt: in den Spitzenreitern sind immer wieder Passwörter wie asdf, 12345 oder password vertreten^[5].

Da Listen mit häufige verwendten Passwörter allgemein bekannt sind, ist es einfach aus diesen Klartexten mit der Hashfunktion einen Tabelle mit möglichen Hashes zu berechnen. Ebenso ist es einfach, eine Tabelle mit einem bestimmten Zeichenvorrat zu erstellen - so sind z.B. die Streuwerte aller 8-stelligen Klartexte mit dem Zeichenvorrat a-zA-Z0-9 innerhalb kürzester Zeit berechnet. Für eine vollständige Liste benötigt ein Versuchsaufbau im Dezember 2012^[6] für SHA-1-Streuwerte etwa 60 Minuten, für MD5-Streuwerte gar nur 20 Minuten. Der Angreifer muss dann lediglich den Hash mit seiner Tabelle vergleichen. Bei einem Treffer ist es sehr wahrscheinlich, dass der vorberechnete Hash auch dem tatsächlichen Klartextpasswort entspicht - auch wenn Kollisionen nicht auszuschließen sind.

Aber auch längere Passwörter mit kleinem Zeichenvorrat sind schnell zu knacken. Aufgrund der Datenmenge wird dies allerdings unter Verwendung einer Rainbow-Table anstatt einer flachen Tabelle erledigt.

Eine Lösung ist hier lediglich ein Passwort mir möglichst hoher Entropie - sprich, es soll lang sein und über einen großen Zeichenvorrat verfügen. Ein Benutzer wird so ein Passwort aber vermutlich nicht aus freien Stücken wählen, es ist also unsere Aufgabe, da etwas nachzuhelfen.

Angreifern die Suppe versalzen

Die bereits angesprochenen vorgenerierten Wörterbuchtabellen oder rainbow tables gibt es im Internet vielerorts - sie haben aber alle eines gemeinsam: egal wie sie erstellt wurden - der Speicherplatz ist beschränkt, die Liste möglicher Klartexte in diesen Tabellen ist überschaubar und meist auf wenige Milliarden Datensätze beschränkt.

Um also die Entropie eines schwachen Passworts zu erhöhen, muss entweder der Zeichenvorrat vergrößert werden oder eben das Passwort verlängert werden, da wir als Betreiber das Passwort natürlich nicht wirklich manipulieren können, hilft nur ein Trick der sich Salt (engl. für 'Salz') nennt. Hierbei wird der Klartext mit einer beliebigen Zeichenkette verknüpft und dann erst an die Hashfunktion übergeben. Wie dies geschieht, ist dabei im Grunde nebensächlich. Die einfachste Möglichkeit ist, so trivial es klingt, Klartext und Salt mit einem Verkettungsoperator zu verbinden.

Aus dem schwachen Passwort 'asdf' wird in Kombination mit dem Salt ')2x$' die Zeichenfolge 'asdf)2x$'. Eine vorberechnete Tabelle für 8-stellige Passwörter und dem bereits angenommenen Zeichenvorrat von a-zA-Z0-9 ist hier bereits völlig wertlos. Der Angreifer muss also nun also erst eine neue Tabelle generieren indem er die Regeln des Salt-Algorithmus befolgt - und das kostet Zeit.

Nachdem bereits vorgenerierte Tabellen aufgrund der heute zur Verfügung stehenden Speicherkapazitäten bereits sehr umfangreich sind, wird man mit einer 4-Byte-Zeichenfolge keinen Angreifer mehr beindrucken können. Der Salt-Teil eines 'Salted Hash' kann und soll also ruhig etwas großzügiger gewählt werden. Je nach verwendeter Hashfunktion ist eine 16- bis 64-Byte lange zufällige Zeichenkette mit einem entsprechend großen Zeichenvorrat anzuraten.

Ob verwendete Zeichenkette 4- oder 64-Byte lang ist, hat in der Praxis zum Schutz vieler Passwörter relativ wenig Auswirkungen, da der Angreifer im Handumdrehen eine neue Tabelle anhand seines Wörterbuchs generieren kann. Aufgrund dieser Tatsache ist es wichtig, dass jedes einzelne Passwort mit seinem eigenen Salt versehen wird. Diese Zeichenkette wird im Klartext gemeinsam mit dem Passwort gespeichert. Dies zwingt einen Angreifer dazu, für jeden Datensatz eine neue Tabelle zu errechnen - selbst wenn mehrere Benutzer dasselbe Klartextpasswort nutzen ist durch die Kombination mit ihrem persönlichen Salt ein unterschiedlicher Hash zu erwarten. Wenn man für das generieren einer umfassenden Tabelle etwa einen Tag veranschlagt, wird das Vorhaben bei mehreren tausend Benutzerdatensätzen schnell unrentabel.

Mehr Sicherheit bei hartnäckigen Angreifern

Ein Angreifer mit entsprechendem Know-How verfügt idR. zwar selbst nicht über die nötigen Rechenkapazitäten um Hash-Tabellen zu berechnen, kann diese Aufgaben aber an andere verteilen. Immer wieder sind Berichte über Cracker mit Botnetzen in beachtlicher Größenordnung in den Medien zu lesen - 100.000 Rechner aufwärts sind hier keine Seltenheit. Wer also 1.000 Rechner in seinem Schwarm zur Verfügung hat, wird auch von 1.000 unterschiedlichen Salt-Werten nicht sonderlich beeindruckt sein. Aus diesem Grund ist es manchmal nötig, den Prozess für einen potentiellen Angreifer weiter zu verkomplizieren.

Mehrfaches hashen und salten

Eine gute Methode ist das mehrfache Hashen und Salzen. Anstatt eine Zeichekette einmal mit einem Salt zu kombinieren, tut man dies mehrfach. Auf der eigenen Seite kostet dies so gut wie keine Rechenzeit, auf Seiten des Angreifers reden wir aber von Wochen, Monaten oder Jahren.

Um den Speicherbedarf nicht unnötig zu erhöhen, kann man denselben Salt (bzw. Teile davon) auch mehrfach verwenden. Zwei oder drei Iteration verkomplizieren die Sache für den Angreifer schon nachhaltig. Dennoch sind auch hier bei einem Verlust der Datenbank sämtliche nötigen Faktoren bekannt, es ist also nur eine Frage der Zeit.

Hinzufügen einer Unbekannten

Sollte durch eine Sicherheitslücke nur die Datenbank mit den Benutzerdaten abhanden kommen, kann es durchaus von Vorteil sein, das Passwort zusätzlich durch eine unbekannte Komponente zu schützen. Die einfachste Möglichkeit ist ein zusätzlicher, statischer Salt-Teil - ohne diesen zu kennen ist nahezu unmöglich, an das Klartextpasswort zu gelangen.

Stärkere Hashfunktionen

Entgegen häufiger anderslautender Behauptungen hilft eine stärkere Hashfunktion (im Kontext eines größeren Wertbereichs) nicht notwendigerweise gegen die genannten Angriffswege. Einige Hashfunktionen sind zwar anfällig für Preimage-Angriffe - das bedeutet, dass der Angreifer zu einem gegebenen Hash einen möglichen Klartext errechnen kann - diese sind aber ungleich langsamer durchzuführen als herkömmliche Brute-Force-Angriffe. Aus diesem Grund bietet es bei diesem Szenario auch keinen nennenswerten Vorteil MD5 durch SHA-1 zu ersetzen da beide Streuwerte einen signifikant größeren Wertbereich abdecken als eine Liste von 8-stelligen Standardpasswörtern

Viel wichtiger ist es, eine Streuwertfunktion zu wählen, die möglichst langsam berechnet werden kann.

Standards und fertige Lösungen

MD5 Message-Digest Algorithm

Die unbestritten häufigste Form des Passwortschutzes ist ein einfacher MD5-Durchlauf - viele verbreite Systeme (darunter TYPO3, Wordpress oder phpBB) nutzen diese Methode um die Passwörter von Front- und Backendbenutzern zu schützen.

Der Vorteil dadurch ist unbestritten die Kompatiblität zueinander - ob man nun zwei Systeme betreibt, die ihre Daten synchronisieren oder ob man von einem auf ein anderes System umsteigt ist hierbei egal.

Der Nachteil liegt aber auf der Hand: durch die Einfachheit dieser Methode gibt es dutzende Online-Dienste, mit denen man zu einem beliebigen MD5-Hash einen möglichen Klartext finden kann. Selbst  eine Suchmaschine kann hierbei als Passwort-Cracker verwandt werden^[7].

bcrypt

Es ist das Ziel vieler Algorithmen wie z.B. MD5 ist es eine Zeichenkette beliebiger Länge möglichst schnell in einen Streuwert zu überführen - ganz egal ob es sich dabei um ein DVD-Image handelt oder um ein 8-stelliges Passwort. bcrypt hingegen wurden mit dem Ziel entwickelt auch besonders kurze Zeichenketten möglichst zeitaufwändig in einen Streuwert zu überführen. Im Vergleich zu MD5 ist bcrypt etwa 2,5 Millionen Mal langsamer^[6], dies senkt die Effizienz von Brute-Force-Angriffen nachhaltig.

phpass

Mit phpass steht ein PHP-Framework zum Schützen von Passwörtern zur Verfügung, welches sich recht einfach in ein bestehendes System einbauen lässt und so ein hohes Maß an Sicherheit bereitstellt aber gleichzeitig die Kompatiblität zu anderen Systemen nicht völlig außen vor lässt. Unter anderem stehen Module/Erweiterungen für TYPO3, Drupal oder Wordpress zur Verfügung. Die Daten lassen sich hierbei z.B. als MD5- oder bcrypt-Hash ablegen, zusätzlich werden Fallback-Routinen angeboten um auche gemischte Datenbestände verwalten zu können.

Portable PHP password hashing framework

Hinweise zum Schluß

Die genannten Methoden sind zum Schutz von größeren Datenbeständen gedacht und stellen wie beschrieben nur eine Verkomplizierung für den Angreifer darf. Keineswegs ersetzen Sie aber ein entsprechendes Sicherheitskonzept für den Datenbestand bzw. eine entsprechende Sorgfalt im Umgang mit den Daten.

Ein einzelnes, schlecht gewähltes Passwort lässt sich auch durch die beschriebenen Techniken nicht entsprechend schützen. Ebenso lässt sich von außen idR. nicht beurteilen, wie gut der Diensteanbieter die Nutzerdaten sichert bzw. ob er dies überhaupt tut. Aus diesem Grund ist es empfehlenswert möglichst überall ein anderes Passwort zu verwenden.

Externe Verweise

Referenzen

• Marcel Werk: Einbruch in die Foren-Datenbank; WoltLab (5. Februar 2008)
• Datenskandal bei haefft.de: Privatleben von tausenden Kindern offen im Netz; Chaos Computer Club (4. Dezember 2009)
• Daniel Bachfeld: Nutzerdaten nach Einbruch in Gawker-Server veröffentlicht; heise online (13. Dezember 2010)
• Hacker stehlen Sony Millionen Kundendaten; stern.de (27. April 2011)
• The Top 50 Gawker Media Passwords; What's My Pass? (14.  Dezember 2010)
• Olaf Göllner: Rekorde im Passwort-Knacken durch Riesen-GPU-Cluster; heise online (5. Dezember 2012)
• Steven J. Murdoch: Google as a password cracker; Light Blue Touchpaper (16. November 2007)

Weiterführende Informationen

• Christoph Wille: Passwörter mit SHA1 absichern; ASP Heute (30. März 2001)
• Daniel Bachfeld: Cracker-Bremse; heise online (03. März 2011)