John the Ripper knackt Office-Dokumente und nutzt GPU
Die Entwickler des Passwortknackers haben die FormatunterstĂĽtzung deutlich aufgebohrt und offizielle UnterstĂĽtzung fĂĽr CUDA und OpenCL hinzugefĂĽgt.
- Ronald Eikenberg
Mit Version 1.7.9-jumbo-6 des berühmt berüchtigten Passwort-Crackers John the Ripper haben die Entwickler die Formatunterstützung deutlich aufgebohrt: Das Tool knackt nun unter anderem passwortgeschützte Office-Dokumente (Office 2007/2010 und OpenDocument), die Master-Passwörter von Firefox und Thunderbird, WPA-PSK-Schlüssel sowie Mac OS X Keychains. Zudem benutzt John auf Wunsch nun auch die Recheneinheiten von Grafikkarten (GPUs) über CUDA und OpenCL. Den Namenszusatz Jumbo kann man dabei durchaus wörtlich nehmen: Gegenüber Version 5, die vor einem halben Jahr erschien, wurden 40.000 Zeilen Code hinzugefügt.
Der Entwickler Solar Designer erklärte gegenüber heise Security, dass bei der Entwicklung der GPU-Unterstützung moderne Verfahren wie WPA-PSK und Unix-Passwort-Hashes im Vordergrund standen, die man nur langsam berechnen kann. Für einige Verfahren wie das Standard-Hash-Verfahren von Ubuntu (sha512crypt) und das aufwändige bcrypt gab es danach bislang gar keine Knacker mit GPU-Unterstützung, "weil andere nur ungern Tool veröffentlichen, das 'unspektakuläre' Geschwindigkeitswerte liefert", so der Entwickler.
"Unspektakulär" bedeutet im Fall von sha512crypt, dass die GPU einer GeForce-Grafikkarte des Typs GTX 570 rund 11.000 Hashes pro Sekunde erzeugen kann – was wohl bemerkt schon mehr als fünf Mal schneller als auf einem Rechner mit acht CPU-Kernen ist. Zum Vergleich: Bei SHA1-Hashes liegt der Wert mit GPU-Unterstützung normalerweise im mehrstelligen Millionenbereich. Bei bcrypt hat die Grafikkarte gegenüber einem Achtkernsystem nur haarscharf die Nase vorn; in beiden Fällen sind es höchstens rund 5000 Hashes. Dass bcrypt durch die Nutzung von GPUs kaum leichter anzugreifen ist, liegt am Design des Algorithmus, der sehr intensiv Speicher nutzt. Laut Solar Designer ging es den Entwicklern "hauptsächlich darum, herauszufinden, wie langsam die bcrypt-Implementierung tatsächlich sein würde." (rei)