Passwörter unknackbar speichern

Mit der richtigen Technik speichern Administratoren auch weniger sichere Passwörter so, dass sich ein Angreifer selbst mit modernster Knack-Ausrüstung daran die Zähne ausbeißt.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 13 Min.
Von
  • Daniel Bachfeld
Inhaltsverzeichnis

Meldungen über Servereinbrüche bei Online-Shops, Spieleanbietern und anderen Dienstleistern liest man mittlerweile fast täglich. Oft gelangen die Einbrecher auch an die Login-Daten der Kunden, inklusive der Passwörter. Weil viele Anwender ein und dasselbe Passwort mehrfach benutzen, können Kriminelle es zum unbefugten Zugriff auf weitere Dienste missbrauchen. Um das Ausspähen der Passwörter zu verhindern, sichern die Betreiber von Webseiten die Nutzer-Passwörter meist kryptografisch, etwa mit Einweg-Hash-Verfahren. Dabei wird aus dem Passwort eine Zeichenkette abgeleitet, die keinerlei Rückschlüsse auf das eigentliche Passwort zulassen. Der einzige Weg später herauszufinden, ob ein Passwort zu einem Hash passt, ist, das Passwort erneut zu hashen und die Ergebnisse zu vergleichen. So arbeiten die Authentifizierungssysteme in Betriebssystemen und Webanwendungen – und auch Passwort-Cracker müssen diesen Weg gehen. Lange Zeit galt das Hash-Verfahren MD5 für diese Zwecke als ausreichend widerstandsfähig, weil die Laufzeit zum Durchprobieren aller Kombinationen Angreifern die Rekonstruktion eines Passwort aus dem Hash schwerer machte. Das Durchprobieren (Brute Force) aller Passwortkombinationen mit Crackern wie John the Ripper bei einem guten Passwort dauerte auf handelsüblicher Hardware Monate wenn nicht gar Jahre. Die Zeiten haben sich geändert.

Crack-Rack: Zusammengeschaltete Tesla-Einschübe auf Grundlage von Nvidias Grafikprozessoren rekonstruieren schwache Passwörter in wenigen Sekunden.

Des einen Freud, des anderen Leid: Cloud, CUDA und Mehrkernrechner beschleunigen das Verarbeiten von Daten enorm und machen selbst komplexe Simulationen für Endanwender möglich. Unglücklicherweise nutzen auch Cracker die Rechenleistung, um aus verschlüsselten Passwörtern in Windeseile den Klartext zu rekonstruieren und sich damit an einem System als Administrator anzumelden. Dabei kommt den Passwort-Knackern zugute, dass ein ausgespähter Hash meist immer noch mit den für eine schnelle Verarbeitung optimierten Algorithmus MD5 erzeugt wurde. So lassen sich etwa mit kommerziellen Passwort-Knackern der Herstellers Elcomsoft sowie freien Tools wie Hashcat und BarsWF mehrere Millionen Hashes pro Sekunde durchprobieren, um zu sehen, ob einer davon zum Passwort passt. Damit ist ein achtstelliges Passwort in vier Tagen geknackt. Doch es geht noch schneller. Da Festplattenspeicher immer billiger wird, setzen Angreifer zum Finden des Passworts zudem oft auf riesige Tabellen (Rainbow Tables) mit Milliarden vorberechneter Hashes ein. Damit ist ein Passwort unter Umständen in wenigen Minuten ermittelt. Auch die für Wörterbuch-Attacken benötigten Listen werden immer größer und führen Crack-Programme bei besonders schwachen Passwörter in Stunden zum Erfolg.

Glücklicherweise gibt es auch Fortschritte in der Hash-Technik, die das schnelle Knacken eines Kennwortes erschweren und das Vorberechnen von Tabellen aus Sicht eines Angreifers unwirtschaftlich machen -- selbst wenn das zu knackende Passwort eigentlich eher schwach ist. Ab einer bestimmten Kennwortlänge lassen sich Rainbow-Tables in keinem sinnvollen Zeitrahmen mehr berechnen und speichern. Daher versieht man vom Nutzer eingegebene Passwörter mit einer zusätzlichen, zufälligen Zeichenkette, auch Salt genannt. Die so entstandene neue Zeichenkette wird durch einen Hash-Algorithmus gejagt und der resultierende Hash beispielsweise in der Datei /etc/shadow abgelegt. Damit ein System spätere Passworteingaben mit dem Hash vergleichen kann, muss das Salt jedoch bekannt sein. Deshalb wird es im Klartext dem gespeicherten Hash vorangestellt. Die Speicherung des Salts im Klartext klingt zwar auf den ersten Blick widersprüchlich, es muss aber gar nicht geheim sondern nur zufällig sein. Es soll ja nur die Anzahl der Kombinationen für jedes einzelne mögliche Passwort aufblähen und so den Aufwand für das Anlegen der Rainbow-Tables immens vergrößern.

Spezielle Online-Dienste versprechen WPA-Schlüssel anhand eines Wörterbuch mit 136 Millionen Einträgen in 20 Minuten zu knacken.

Brute-Force-Angriffe auf ein einziges Passwort bremst ein Salt jedoch nur geringfügig aus. Herkömmliche Hash-Algorithmen etwa zum digitalen Signieren oder dem Erstellen von Dateifingerprints sind auf Geschwindigkeit getrimmt. Bei der Passwort-Prüfung ist dies jedoch kontraproduktiv, denn man will ja die Arbeit des Passwort-Knackers ausbremsen. Brute-Force-Angriffe lassen sich durch das gewollte Verlangsamen des benutzten Hash-Algorithmus beziehungsweise durch viele Wiederholungen des Hash-Vorgangs unattraktiv machen. Für den Anwender ist die Geschwindigkeit dagegen kaum von Belang: Ob die Prüfung eines eingegebenen Passwortes auf einem System beim Login nun 1 Mikrosekunde oder 1 Millisekunde dauert, merkt er nicht. Einen Passwortknacker würde es aber um den Faktor 1000 ausbremsen – statt 100 Millionen Passwörter pro Sekunde kann er nur noch 100.000 pro Sekunde durchprobieren. Ein Brute-Force-Angriff auf das Kennwort "P4ssW0r7" würde so 48 Jahre statt 18 Tage dauern.

Ursprünglich stammt die Technik der künstlichen Verlangsamung aus der Ableitung eines Kryptoschlüssels aus einem Passwort. Weil Nutzerpasswörter oft zu kurz sind und zu wenig Entropie aufweisen, muss man beispielsweise für eine Verschlüsselung mit AES und 256 Bit den Schlüssel kryptografisch sicher verlängern. Kryptologen bezeichnen diesen Vorgang als Key Stretching. Dafür wird das Passwort mehrere Runden durch einen Hash-Algorithmus geschickt. Das Verfahren ist als Password-Based Key Derivation Function 2 (PBKDF2) standardisiert und findet etwa bei WLANs mit WPA-PSK-Schlüssel Anwendung. Auch Smartphones nutzen PBKDF um Backup-Dateien vor dem Export mit einem Passwort zu verschlüsseln. Auch hier bremst es Knackversuche erfolgreich aus.

Eine einfache Rundenfunktion zum mehrfachen Hashen des Passworts kann beispielsweise so aussehen:

key = hash(password)
for 1 to runden do
  key = hash(key)

Der entstandene Hash-Wert wird einfach immer wieder als Parameter an die Hash-Funktion übergeben. Bei komplexeren Rundenfunktionen geht beispielsweise das Passwort zusätzlich immer wieder in den zu hashenden Wert ein. Den Aufwand muss ein Betriebssystem oder eine Anwendung nur einmal pro Passwort pro Anwender treiben. Das Knackprogramm muss dies jedoch für jede Zeichenkombination durchexerzieren -- und jede Runde kostet zusätzliche Rechenzeit, was insgesamt den Vorgang pro Passwort enorm verlangsamt.

In der Praxis nutzen zwar viele Betriebssysteme bereits Salts und Key Stretching, um die Passwörter der Anwender sicher zu speichern. Gerade bei populären Web-Anwendungen steht es um die Passwort-Sicherheit jedoch schlecht, obwohl dort das Risiko am größten ist, dass Angreifer Passwörter von Nutzern oder Kunden auslesen. Da werden Passwörter mitunter sogar noch im Klartext abgelegt; und wenn sie doch gehasht wurden, dann nur mit MD5. Selbst verbreitete Content-Management-Systeme wie Typo3 nutzen standardmäßig MD5 ohne Salt oder Runden zum Hashen der Nutzerpasswörter.

Mehr Sicherheit verspricht die Typo3-Extension "saltedpasswords". Sie bietet zusätzlich die Sicherung mit bcrypt oder dem Sicherheits-Framework phpass an; dazu gleich mehr. Die Erweiterung will allerdings erst aktiviert und konfiguriert werden, was jedoch die Installation weiterer Extensions und Eingriffe am System nach sich zieht – da wundert es wenig, dass viele Betreiber es bei der Grundinstallation belassen.

Wordpress und phpBB setzen auf das Framework phpass des Entwicklers Solar Designer – der im Übrigen auch den Passwort-Cracker John the Ripper entwickelt. Phpass setzt standardmäßig auf bcrypt. bcrypt beruht auf dem Blowfish-Algorithmus, bei dem es sich streng genommen gar nicht um einen Hash-, sondern um einen Verschlüsselungsalgorithmus handelt. Bcrypt nutzt einen aufwändigen Schlüsselinitialisierungsalgorithmus und verschlüsselt das resultierende Chiffrat immer wieder abwechselnd mit dem Salt und dem Passwort. Die Zahl der Runden ist eine Potenz von 2, der benutzte Exponent wird der erzeugten Zeichenkette vorangestellt. Diese hat üblicherweise folgendes Format:

$2a$08$Ra4upKLreqDA18E/OtFSIu/ED6iTmorUKyNJF6aVwbpO9AIBS/j7u

Die am Anfang zwischen die Dollarzeichen eingeklemmte Zeichenkette 2a steht für den bcrypt-Algorithmus, die darauffolgende Zahl 08 signalisiert den Exponten zur Potenz 2 – 2 hoch 8 ergibt die Anzahl der Runden: 256. Die sich anschließende Zeichenfolge ist das 16-stellige Salt und das verschlüsselte Passwort.

Der kostenlose Cracker Hashcat unterstützt zahlreiche Hash-Algorithmen und die bei Anwendungen benutzten Varianten.

Fehlt die Implementierung des Blowfish-Algorithmus auf dem System, fällt das phpass-Framework automatisch auf Extended-DES und im Notfall auf MD5 mit Salt und Iterationen zurück. Um den Rückfall auf schwache Algorithmen zu verhindern, empfiehlt der Entwickler, mindestens PHP 5.3.2 einzusetzen. Ab dieser Version sind Blowfish, SHA-256 und SHA-512 nämlich schon fest in PHP integriert, sodass man nicht mehr auf Betriebsystem-APIs oder zusätzliche Bibliotheken angewiesen ist. Alternativ erweitert das PHP-Sicherheitsframework Suhosin den PHP-Interpreter um Blowfish.

Allerdings nutzen WordPress und phpBB die unsicherste von drei möglichen Konfigurationen. Wordpress setzte in unserem Test auf einem Ubuntu-System auf die MD5-Variante, wobei das CMS den Rückfall absichtlich erzwingt, um die Kompatibilität zwischen verschiedenen Webanwendungen zu erhalten. WordPress soll so die Nutzerdatenbank von phpBB nutzen können und andersrum. Die Drupal-Entwickler hingegen haben das Framework für ihre Zwecke angepasst und hashen seit Drupal 7 mit SHA-512. Für ältere Drupal-Versionen steht das Modul "Secure Password Hashes" zur nachträglichen Sicherung bereit.

Standardmäßig ist es auch etwa um das CMS Joomla nicht zum Besten bestellt. Es ist zwar in der Lage, über die PHP-Funktion crypt() SHA-512 mit Salt und vielen Runden zu nutzen (getCryptedPassword), ab Werk kommt jedoch nur ein Salt und MD5 mit einer Runde zum Einsatz. Grundsätzlich lässt sich die eigene Installation eines CMS ohne größere Problem manuell anpassen und auf eine sicherere Variante umstellen. Man muss nur im Auge haben, dass unter Umständen Zusatzmodule inkompatibel zu den Änderungen sein können.

Wie die eigene Installation eines Content-Management-Systems Passwörter speichert, lässt sich durch eine Quellcode-Analyse feststellen oder durch einen Blick in die Datenbank. Am einfachsten ist letzteres, wozu man sich einfach mit dem Datenbankserver verbindet, beispielsweise so: mysql -u <user> -p. Der Parameter user ist der eingetragene Datenbanknutzer, in dessen Kontext sich das CMS anmeldet. Der Befehl show databases; listet alle verfügbaren Datenbanken auf. Um beispielsweise die Datenbank typo3 auszuwählen, gibt man use typo3; ein (Semikolon am Ende nicht vergessen). Anschließend lässt man sich alle angelegten Tabellen der Datenbank mit show tables; anzeigen.

Unter Typo3 sind insbesondere die Tabellen be_users und fe_users von Interesse. Mit select * from be_users; bekommt man alle Inhalte der Tabelle angezeigt. Steht dort bei den Nutzerpasswörter nur eine Zeichenkette wie 1ee9e0daf4a2b81fe4064aa5ae31aae4, so handelt es sich um einen einfachen MD5-String ohne Salt.

In aktuellen Drupal-Installationen sieht ein in der Datenbank abgelegter Passwort-Hash (Tabelle users) beispielsweise so aus: $S$CbkCbEtqypgcggWPee9c6wpgwUYqKjMb0pUR9YTgdwdYkxztRmWj. Die am Anfang stehenden Dollarzeichen umrahmem die Angabe für den Hash-Typ, daran schließt sich das Salt und der eigentliche Hash an. Der Typ 2a würde bcrypt signalisieren. Bei Wordpress (Tabelle wp_users) findet man Einträge wie $P$Bz0ZwGCmWuvcurZbj4CaptBFir8gQv1 – der Hash-Typ P steht für sogenannte portierbare Hashes – also die MD5-Lösung.

Der unter PHP gemessene Verlangsamungsfaktor der verschiedenen Algorithmen.

Phpass lässt sich auf sehr einfache Weise in eigene PHP-Anwendungen integrieren. Es besteht aus einer einzigen PHP-Datei mit einer Klasse und diversen Methoden. Zwar kann man mit einer modernen PHP-Version auch alle Hash-Algorithmen direkt aufrufen, einer der Vorteile von phpass ist aber, dass man sich nicht selbst um das Erzeugen eines zufälligen Salts und das Zusammenbauen der Zeichenkette kümmern muss. Die zurückgelieferte Hash-Zeichenkette kann man direkt in der Datenbank abspeichern.

Phpass erzeugt das Salt auf Unix-Systemen durch Auslesen von /dev/urandom und unter Windows mit der PHP-Funktione microtime(). Für das Erzeugen eines sicheren Passwort-Hashes genügen zwei Zeilen:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Der Parameter FALSE im Konstruktor signalisiert phpass, den sichersten Algorithmus zuerst zu wählen -- auf modernen Systemen normalerweise bcrypt. Durch Übergabe von TRUE erzwingt man den Einsatz der unsicheren, dafür aber kompatibleren MD5-Implementierung; so macht es beispielsweise WordPress. Der Konstruktor erzeugt zudem das Salt. Der Parameter**8 signalisiert bei bcrypt den Exponenten für die Zahl der gewünschten Iterationen, womit man bei bcrypt auf 256 Runden kommt. Der maximale Exponent ist 31.

Die Methode HashPassword erzeugt dann aus dem Passwort und dem Salt den Hash. Die Prüfung eines eingegebenen Passworts ist ähnlich simpel:

$check = $t_hasher->CheckPassword($password, $hash);

Die Variable $check enthält das Ergebnis des Vergleichs, also 1 für wahr.

Administratoren sollten sich nicht auf die Standardeinstellungen ihrer Systeme verlassen, sondern die sichersten Methoden einsetzen -- und dies seinen Anwender mitteilen. Als Nutzer eines Forums oder eines Online-Shops hat man jedoch keinen Einfluss darauf, ob der Anbieter eine sichere Methode benutzt. Schlimmer noch: Man kann nicht mal abschätzen, womit er die Passwörter überhaupt verschlüsselt. Für den Anwender liegt der beste Schutz deshalb in der Wahl verschiedener Passwörter. Das Autoren-Kennwort für das Typo3-CMS sollte nicht das gleiche wie für das PayPal-Konto sein. Grundsätzlich gilt: Länge ist Trumpf – sofern das Wort in keinem Wörterbuch steht. Dabei dürfen die Passwörter für nicht ganz so wichtige Konto ruhig etwas kürzer sein als die für Bezahldienstleister. (dab) (dab)